On 6/8/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: [snip]
I'm still not sold on the whole concept of annotations myself... it seems to encourage scattering things throughout the code base that otherwise would be centralized.
Always slow to get on the latest bandwagon, eh Frank :-) Ironically, the fact that Struts had, from the very beginning, a centralized configuration file was one of the critical success factors in its early growth. Not just because everything was in one place, but because it was very easy for tooling around Struts to use struts-config.xml as the persistence format ... no need to invent some data structure proprietary to a particular tool, and which couldn't be shared across tools when the user switches IDEs. That being said, XML configuration files are going out of fashion, at least among the developers who speak out a lot :-). Here's my two cents on when I like to use annotations, and when I don't. * Annotations are a good idea when the configuration concept is directly related to how you code your source. Examples include beans used in a webapp (it really matters whether you're going to store it in request scope or session scope or application scope), transactional settings on an EJB, and so on. Storing the actual annotation in the source code reduces the chances that some sysadmin installing your application might accidentally or inadvertently change the scope setting, without understanding that they just broke your code. * Annotations are not a good idea when the configuration concept should not be a concern of the person actually writing the code. In webapps, for example, I don't believe in configuring page navigation rules (Struts forwards, JSF navigation rules and cases, etc) directly into the action methods. The actions should describe what happened, not where to go next -- and this is something I personally don't care for, even at the code level, the way that WW2 does Results (or Spring MVC does ModelAndView) that combine the two concerns together. But that's a separate issue from whether the encoding should be with annotations or not :-). * Annotations should also not be used to configure decisions where it is appropriate to allow the user of your code an opportunity to override the annotated choice, unless you also provide some mechanism to override by exception. The Java EE specs that use annotations have tried to follow this principle, allowing you to change certain aspects of what was coded in annotations in the first place. Craig
