seen from Kazakhstan
seen from Malaysia
seen from Switzerland
seen from Poland
seen from Malaysia
seen from United States
seen from Germany
seen from Malaysia
seen from United States
seen from Germany
seen from Saudi Arabia
seen from Germany
seen from Germany
seen from China
seen from Libya
seen from United Kingdom
seen from Italy
seen from Belgium
seen from Libya
seen from Singapore
My Journey with #tapestry5 and #JavaEE
Conclusion
As I looked at the big picture, it turned out to be easier to convert the whole app from T5.3 to JSF and PrimeFaces instead of T5.4, and that's what I did. This turned out a great decision. Everything is compatible, future JavaEE versions are easily adoptable, all integrations do not require heroic efforts to implement or maintain and even JavaScript and Ajax with JQuery even started to be fun to develop.
My Journey with #tapestry5 and #JavaEE
Part 17 - Conversion to Tapestry 5.4
After about 2 and a half years of using Tapestry 5.3, T5.4 was starting to take shape. It has a brand new JavaScript framework based on JQuery, Bootstrap and requireJS. I figured that it was a good direction to be headed, so I started a pilot project of converting my code into 5.4. Good news was that there were not much Java code changes required, well, it was good and bad because all the same issues in Tapestry-IOC were still present in 5.4. At least it was Java 8 compatible. In order to take advantage on the new JS framework, all infrastructure and patches that I made to make T5.3 usable had to be completely rewritten in T5.4, which was not a simple task. After spending about a month researching and updating all components to T5.4 (again undocumented) JS infrastructure, I finally got things to work, kind of. Partly because of Bootstrap layout engine in T5.4, all the pages looked wrong. I tried to figure something out to generically fix the layout, but it turned out what I had to do is manually fix up all the pages. BeanEditor and company had particular layout issues, and every on of those looked wrong with no way to fix it. Suggestions I was getting from Tapestry community was to stop using BeanEditor.
My Journey with #tapestry5 and #JavaEE
Part 16 - Java 8 compatibility
When Java 8 came out, it seemed to me the most stable release ever. I had no issues upgrading any of my software to Java 8, and the new features such as Lambdas and Streams were a wonderful additions.
Unfortunately, it took over a year and a half to release a stable version of Tapestry that supported Java 8. Why? Nobody just cared! T5.4 alphas / betas supported Java 8, but not production versions. All that had to be done is to upgrade the bundled ASM package, but nobody bothered to do it in over a year.
It’s obvious by this that nobody is really doing any active development out there with Tapestry anymore, and thus there was no outcry about Java 8 compatibility. Where does this leave Tapestry? I don’t know, but this would leave a big pit in my stomach if I was depending on Tapestry.
My Journey with #tapestry5 and #JavaEE
Part 15 - Ajax table issues and other Ajax missing features
As I was working with Ajax, especially tables / grids, it became obvious that Tapestry’s implementation is not very modern. This isn’t really addressed in T5.4 as features remain the same. Ajax table looks dated, just has one silly-looking pager on top, and if you want to customize it, good luck.
Tapestry claims many features, and there are indeed many, they are just mostly based on very old JavaScript that hadn’t been upgraded in years.
There is nobody that has the time to sit down and update the components, as it is a big job, and community contributions would be flatly rejected for “code-dumping” or “compatibility” reasons, I guess.
My Journey with #tapestry5 and #JavaEE
Part 15 - Ajax table issues and other Ajax missing features
As I was working with Ajax, especially tables / grids, it became obvious that Tapestry’s implementation is not very modern. This isn’t really addressed in T5.4 as features remain the same. Ajax table looks dated, just has one silly-looking pager on top, and if you want to customize it, good luck.
Tapestry claims many features, and there are indeed many, they are just mostly based on very old JavaScript that hadn’t been upgraded in years.
There is nobody that has the time to sit down and update the components, as it is a big job, and community contributions would be flatly rejected for “code-dumping” or “compatibility” reasons, I guess.
My Journey with #tapestry5 and #JavaEE
Part 14 - yuicompressor dependency issues
This is a plea to all projects, including Tapestry 5: If you are going to be including any dependencies in your own .jar, use “jar-jar links” or something similar to rename internal dependencies so they don’t clash with the original work.
Tapestry likes to compress JavaScript, which is good. Unfortunately, it uses yuicompressor library that’s bundled with an old version of Rhino, which conflicts with everything else we are trying to use. I had to resort to packaging my own yuicompressor with jar-jar links to be able to run any of the code.
Tapestry is not the only offender to this. GWT is a big one, among many other open-source projects.
Please, don’t do this, publish a list of your dependencies via ivy/maven instead.
Thank you
My Journey with #tapestry5 and #JavaEE
Part 13 - Tapestry-security
How to secure web applications has always been a non-trivial task. Tapestry has a module, called Tapestry-Security that simplifies things and integrates Apache Shiro with Tapestry.
As I was starting to use Tapestry-Security in-depth, however, the ugly parts of Tapestry-IOC integration came reared its ugly head again.
Apache Shiro is usually configured with shiro.ini file, which is a simple text file that presents a Java-beans-based standard configuration, is easily understood, and is used by many people. All the examples within Shiro are presented using this configuration file. Unfortunately, Tapestry-Security discards this configuration method in favor of Tapestry-IOC-based method, which is poorly documented and very hard to understand. As more security requirements were added, it became a battle to figure out just what combination of annotations, code, and where to put it all. None of these efforts paid off, and like anything with Tapestry-IOC, crazy errors were a result of seemingly simple modifications, and were impossible to figure out. Since Shiro/Tapestry-IOC/Tapestry-Security combination is rarely-used one, there was no one to help with the setup, and the more rigorous security requirements had to be abandoned in this context.
After the switch to JSF, however, Shiro, with it’s standard configuration, worked as expected, and I was able to build all of the security requirements in the application very quickly.
My Journey with #tapestry5 and #JavaEE
Part 12 - Tapestry5 design - One Class per Page vs. JSF possibilities
Now that JSF is my primary environment, I started noticing that Tapestry's design choices are not necessarily the best ones and are unnecessarily limiting. Let's take an example that in Tapestry, one page has access to one, and only one backing class. In case of JSF, you can access as many beans as necessary. The JSF way seems to be more flexible and saves code, as Java classes can be reused across pages
