Annotations are a new addition to Java5. Everyone has an opinion on whether or not they are a good thing. Some people love them, some hate them. Others ride the fence and say they are good for some things but not for others. That is kind of where I tread on the subject. Specifically when it comes to configuration files for my web projects.
Back in the day all you had to worry about was the web.xml, then struts came along and added struts-config. A bit later, tiles.xml and then applicationContext from the spring "beans" (I just decided to call the Spring developers beans). And then the bad boy drops in. Tapestry. Talk about config files. You have a template (html), an associated .page file (xml), an application config (xml), possibly a hivemind module config (xml). Add any other technology into the same mix and you've got xml config files running everywhere. Tracking down the latest bug means traversing through file after file, tracing what xml element was used where. Ugh!
There is no perfect solution for this. Today's applications need configuration files. Believe it or not they do ease long term development. It's the small single developer projects that suffer the most (that would be mostly me). So if I have the chance to lessen the xml config file load I'll take it. Tapestry 4 provides annotation support to replace (optional) page-specifications and/or component-specifications that normally exist in an XML file.
What I like best about this is losing the .page file all together. Before annotations or if you refuse to use them you will have the HTML template and an associated .page file and the associated java class. Using annotations you can move everything in the .page file into the java class. When there are problems or errors instead of flipping back and forth between your .page file and your java class to see what component you forgot to define or what event you forgot to include or spelled wrong in one file or the other, it's all right there in the single java class file. Someone might say you lose some flexibility with this. That you are now required to build your project everytime you make a slight configuration change. To this I would argue that if you are making changes to your .page file, chances are you are going to associate that change in the java class, and vice versa. So you are going to have to build again anyway.
Like I said at the beginning, I tend to feel the same way about annotations as I do about many technologies in general. They have their place. They're not an end all solution. But they do solve problems. Use them when you need them. If you are using Tapestry 4 and not using annotations I'd seriously reconsider. But that's me.
Saturday, January 14, 2006
The Benefit of Annotations in Tapestry 4
Subscribe to:
Post Comments (Atom)
2 comments:
I totally agree. Both about Tapestry 4 and about Annotations.
I was drawn to Tapestry because of the simplicity, even though I'm new to it - I started using it since beta-10, but I've seen other frameworks and I've seen old code of Tapestry.
Using annotations seriously reduce the need for configuration files. In fact, it is Tapestry's use of annotations that inspired me in writing my own framework that reduces the need for complicated XSD files.
They indeed shorten the development time, both for me in X2J and in Tapsetry, but I must say I never really checked what is the cost of their reflection... Interesting. I might look into that soon, when I start profiling X2J. :)
The nice thing is that Tapestry uses Hivemind to inject all the properties for the annotations. It's not that a whole other process has to handle it. That being said, I am sure there is a trade-off, but in this case negligable in favor of the payoff. There are probably more significant bottlenecks like http and database access that are far slower than the annotation mechanism. Especially since pages are cached.
Post a Comment