Dennis Byrne schrieb:
>> XML configuration files do quite well their job and were designed to avoid
>> coupling parametrization stuff in code. Now it seems we return to the point
>> were we started. It seems more a response to .NET than real desirable
>> functionality, as we already had it with external configuration files.
>
> I have to agree w/ this 100%, XML still rocks. After doing my latest project w/ EJB3 annotations, I don't see much added value.
>
> But the truth is, annotations are very sexy right now. This project isn't lacking in users, but I think this would generate a lot more interest in MyFaces.
>
Actually this is getting off topic. But I see annotations
as a huge improvement over central configuration in certain situations.
As someone mentioned it is first of all a good place to have
configurations if it has to change with your code on the fly.
Secondly it cuts down severely on artefacts because annotations work on
introspection, which most xml based configurations dont.
So you end up with two annotations per class, within the code instead of
a 20-30 line extra xml artefact.
Perfect example is for instance the @WebMethode or the @Transactional
annotation
There are scenarios where a central configuration in xml makes perfect
sense. For application singletons for instance, or db connection
configuration.
But this is totally off topic for now.
Off topic or not :-), you can get a sense of what it would feel like to use JSF-specific annotations today, using Shale's Tiger Extensions[1]. They let you use annotations to define managed beans, register components/converters/renderers/validators, as well as get Shale's view controller functionality without having to implement the ViewController interface. Requires JSF 1.1 and JavaSE 5.
The SQL Browser example app uses these, so you can see what it looks like in action. (NOTE - the app is currently bundled with MyFaces 1.1.1 that has a bug, recently fixed, that prevents the actual data in the table from being displayed -- will switch to 1.1.2 once that's released.)
For application developers, not having to declare managed beans in XML can quickly spoil you.
On a more general note, I believe annotations make sense when your code is designed on the assumption that the configuration variable is set a certain way. In JSF, for example, which scope the managed bean goes in can make a difference in what you do (thread safety issues, session scope beans should be Serializable, etc.). Having the setting in the class lessens the likelihood that someone will unknowingly change the configuration setting, without understanding that it might need code changes too.
I don't believe annotations should be used for everything. Again, in the JSF case, I think navigation rules don't belong there -- actions should return an outcome that says "this is what happened" rather than "this is where you should go next", and the overall flow should be managed separately (because it can change, without needing to change the code).
[1] http://struts.apache.org/struts-shale/features-tiger-extensions.html
