Craig, the Shale Tiger extensions are a good startin point, I read the docs, and liked what I saw. (I also highly recommend Seam which drives annotations to the extreme)
Anyway, having had to hack components again for an extende period of time I still hate the huge mess the whole component API is in (no offence to the Sun guys they did their best given that they had to enforce 1.3+ JDKs) What I would like to see would be a single controller and view object with all the taglib binding exposed via annotations instead of having to drag around an extra tag class, an extra tld and an extra faces-config entry. Components for instance are the perfect place to get rid of the xml defintions totally (which then can be overridden with application level xml definitions if someone wants to use his own renderer) With a good use of annotations we could cut down from two xml definitions and 3 classes, to two classes and 1-2 annotations in the controller and view. Which means a total cut down of the code of at least 30% average and a total cutdown of artefacts from 5 to 2. Craig McClanahan schrieb: > On 3/28/06, *Werner Punz* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > wrote: > > 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). > > Craig > > [1] http://struts.apache.org/struts-shale/features-tiger-extensions.html >
