Hi Craig, If I take your philosophy and apply it to the managed-bean annotation, it makes only sense for the "scope"-annotation. The "name" annotation should (and will be changed) without changing the code itself.
Same for navigation rules. The "from-viewid" as well as the "to-viewid" will be independent of the code, whereas the outcome very much interacts with the code. I suppose it is not quite the clear distinction you try to point out in your mail above. If you try another line of argument, you could say that navigation rules could be used in multiple action-methods, in different classes. Absolutely true. But managed beans can be used (as managed properties) in multiple other managed beans as well. And it makes no sense to configure a managed-property in the faces-config.xml, if the managed bean has been created by annotation. What I want to point out is that depending on how you see a navigation rule (as very related to the special action-method you program right now or as a general navigation rule, valid for many action methods) the usability of annotations change, but I wouldn't outright decline them. In fact, I would personally like to use annotations for some very special navigation rules, and for general navigation rules, I'd take Werner's approach of writing a semi-automatic "navigation-handler". With this, I'd be pretty happy to get rid of the faces-config.xml if I don't like it. regards, Martin On 3/27/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 3/27/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > > > > > > > > But, I don't agree that navigation rules should be implemented with > annotations. > > > I agree with Gary on this. > > My general philosophy is that annotations make sense when they represent > configuration information that affects how you actually code something. In > JSF, the classic example is managed beans. What scope you put them in has > an impact on the code you write (request scope beans do not have to care > about thread safety, but session/application scope beans do, and you will > likely want to ensure that session scope beans are Serializable). Having > the scope setting separated from the source code risks accidental or > innocent mismatches if someone changes the scope setting without thinking > through the implications on the code. > > In EJB, you see similar sorts of issues around the transaction model that is > used. > > Regarding navigation rules, I personally believe that action methods should > report "what happened" (i.e. logical outcomes), not "go here next". Given > that philosophy, you should be able to change the navigation rules without > modifying the code. Ergo, navigation rules should not be implemented in > annotations (and they are not in Shale :-). > > > > > > > Gary > > Craig > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
