I decided to take a break from my duel with Tapestry and look into Wicket. It’s similar to Tapestry in that it’s a Java component-based web framework and I was really tired of smashing my head into the wall with Tapestry, so I started playing around with it.
I’m only had a handful of hours into it, so take it all with a grain a salt. The same with my Tapestry thoughts as well.
The code is more concrete in Wicket. I can write regular Java code that uses interfaces and inheritance to let IntelliJ IDEA know that the code is actually being used somewhere. Compared this to Tapestry which leaves my IDE with a plethora of grayed methods and variables.
By convention is fine in the beginning of a project, but it can become a nightmare as you work to maintain that code and forget whether that “unused” method is really used or not. I’ll take a extending a class over magic methods any time.
However, as I’ve gotten older, I’ve become lazier. The second thing I noticed once I got a project running is how little Wicket provides out-of-the-box. IoC? Install your own. ORM? Find it yourself. Wicket simply manages the “web” portion of being a web framework.
And that’s not necessarily a bad thing. It’s not shameful to do one thing well. But it does mean, I have to do more work at the beginning to make a useful web application. I spent last night getting Guice, warp-persist, and Hibernate to play nice. (There’s probably a useful blog post from that experience). Getting frameworks to work together is not the most productive thing I can do with my time.
I don’t mean to turn this into a Tapestry vs Wicket article, but I can’t help but compare them. Tapestry, out of the box so to speak, does offer IoC and Hibernate components. And Tapestry does a decent job without becoming a bloated, huge monster.
If I just went by Tapestry and Wicket, I would think open source fails at documentation. Luckily, Hibernate and Spring prove that good documentation is possible. I think both Wicket and Tapestry just need to reorganize most of what they already have written. To find the useful Wicket documentation, you have to scroll past the blurbs about how cool Wicket is to use, how you should have been using it yesterday already, and how you can get it now. Move past all that and you can get find some useful info scattered in the wiki.
As my spare time allows, I’ll continue to play around with both Tapestry and Wicket. I don’t want to rush into any decision and be stuck with it for the next few years. Right now, neither is jumping out and screaming “productivity” to me.
I really want to like Tapestry 5. How can a Java web developer not want to like something that basically describes itself as not-Struts? However, there have been some frustrations as I’ve prototyped AtomicGamer 2.0.
Tapestry 5 actually has a good amount of documentation. The API documentation is commented. A tutorial is available. Several of the concepts have long and detailed pages of text.
I just can’t find anything.
There’s 5 separate pages on component functionality, but I can’t find out how to actually inject a component onto a page. I know I saw it somewhere, but it’s lost now. There’s InjectComponent and Component annotations, but I don’t know what the difference is between them and I’m sure the difference is significant.
I need more information about contexts, but it took forever to learn that they are a page rendering request feature and documented under page navigation. I apparently should have known this.
I think the problem is the layout of the documentation rather than the contents. I understand what I want to do, but I cannot map my concepts into Tapestry concepts. Hence, the documentation is painful to use at best.
I was a Java and C++ developer, but I’m currently employed as a PHP web developer. Being the only “Java guy” at work, I get some flak thrown at me, but I like to toss some back. For example, PHP is dynamically-typed and interpreted. You never can really be sure if that method is used or if those parameters are the correct type. At least, not until run-time.
Thanks to the popularity of Ruby on Rails, “by convention” is the new big thing and Tapestry 5 loves it. My IntelliJ IDEA is filled with grayed method names since IDEA has no way to know if those methods or even classes are really in use. Is my onActivate method going to be called? Are those the correct parameter types? Who knows! Who cares! It’s by convention!
Annotations can help remove the gray, but then I’m just left with an IDE that thinks everything is used whether or not reality matches.
I’ve been on the fence with Tapestry 5 ever since I learned they embedded the Prototype Javascript library into it instead of being Javascript-framework neutral. I know jQuery already, do I really need to learn another Javascript library to use your Java web framework?
In theory, the standard components in Tapestry should hide Prototype and any Javascript library from me. For example, I want to display my BeanDisplay component. If a user clicks an edit button, it makes an AJAX call and loads a BeanEditForm component.
The Zone component may be able to do this, but I can’t get it to work how I want. Maybe because I’m haven’t found the right documentation. I’m left with implement the Javascript myself, but now I need to learn Prototype or learn how to safely embed jQuery and Prototype into my Tapestry 5 application.
I forget — what, exactly, is Tapestry suppose to be helping me accomplish?
I’ll admit, I’m a Tapestry newbie. However, I’m not a web newbie. I’m not a software engineer newbie. I’m sure Tapestry can be masterfully productive for some people, but I’m just not feeling it yet. Mostly, it feels like I’m fighting the framework and documentation to get it to do what I need it to do, and still failing.
Wicket? Stripes? Back to Struts 2? I don’t know.
I’m trying to wrap my head around Tapestry’s contexts and event handling. The details are hidden in various sections of the documentation so it’s been a lot of trial and error. My goal is to be able to handle URL parameters in a way I can understand and process with some intelligence.
On a link, you can pass in a context:
<t:pagelink page=”games/Edit” context=”game”>${game.name}</t:pagelink>
In this instance, I’m passing a Hibernate entity to the game edit page. The URL will be http://www.atomicgamer.com/game/edit/5 where 5 is the entity id. On the edit page, we have several ways to handle get this value.
Note: Since we passed the Hibernate entity and not just the id, Tapestry is smart enough to fetch the entity from the session. That’s why the following examples use variables of Game, not Long.
We can use the @PageActivationContext annotation and game will be automatically populated.
@Property
@PageActivationContext
private Game game;
If we defined a method onActivate(Game game), the parameter will be populated and we can assign it to an instance variable.
If we don’t want to use the onActivate convention, we can use the @OnEvent annotation on a method instead.
@OnEvent(“activate”)
public void annotationTriggered(Game game)…
While all of the above examples will get you access to the context, you will want to watch for the order of operations if you try to mix them.
I wanted to use PageActivationContext to automatically populate my instance variable. Then, I wanted to use the OnEvent method to check for a errors (the instance variable will be null if it doesn’t exist in the database).
However, the OnEvent method is fired before the PageActivateContext. The instance variable will be null regardless. I tried onActivate() (without any parameters) and while that is fired after the PageActivateContext, I felt that was getting too far into happenstance for me to feel happy about the solution.
The current order of operation appears to be:
I think I’ll just stick with one of these instead of trying to mix them in any fashion.
I’m still learning Tapestry 5 and this is just one of the many growing pains I’m suffering at the moment. It’s not that the framework can’t do what I want it to do. Rather, I’m not sure which way I want it done that makes sense down the road. I’m lacking clarity in the big picture of a Tapestry application.