On 3/28/06, Werner Punz <[EMAIL PROTECTED]> wrote: > 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)
A gentle reminder: JSF was not designed by "the Sun guys"; there's an expert group too. ;) > 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. With annotations, there certainly shouldn't be any need to define a component in faces-config. Nor should there be any need to write a JSP tag or add an entry to a TLD. Renderers are a bit trickier, 'cause I have run in to circumstances where I reuse the same renderer for multiple components/rendeer types, but the 99% case could be handled by annotations. > 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. Is the code reduction you're noting there from eliminating the JSP tag code? -- Adam > 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 > > > >
