On 4/3/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > On 4/2/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > 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 we agree that the from and to view ids are not appropriate in the > annotations, I don't see much of a need to annotate anything related to the > outcome. It is just a string that (in my opinion) should describe "this is > what happened", not "this is where you should go next."
It would actually be rather useful from a tooling standpoint to be able to detect a list of possible outcomes from a method intended for an action - and very handy to narrow down the methods that are really intended as action methods, especially since in JSF 1.2 anything that takes no args and returns any type is legit. > > 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. > > > Regarding managed properties, that was my original thought as well -- you > can always just pre-initialize the instance variable value to whatever > default you are trying to set. Then, I remembered two things: > > * You can also use a value binding expression instead of a literal value, > just like you can in a faces-config.xml file. Indeed, and creating ValueExpressions on the fly is a pain and hideously ugly. Also, I wouldn't be shocked if JSF started supporting re-setting properties in the future (stealing a page from Seam's "bijection", for example), in which case the constructor is not sufficient. > * Using the annotation (or a managed property declaration) causes the > property setter to get called, in which you might have coded side effects > that you want to trigger (such as a property change event getting fired). Though if you actually want the setter to be called, you could just call it from the constructor. -- Adam
