On 4/2/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
Indeed. And nothing stops you from declaring a managed bean (using the same class) in the usual way if you need this.
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."
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.
* 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).
I could see a case for a completely different sort of navigation scheme, driven by its own navigation handler, that ran off its own annotations. And this wouldn't even have to conflict with the standard handler, if it delegated for cases that were not annotated. I just don't see it for the standard algorithm.
Craig
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.
Indeed. And nothing stops you from declaring a managed bean (using the same class) in the usual way if you need this.
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."
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.
* 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).
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".
I could see a case for a completely different sort of navigation scheme, driven by its own navigation handler, that ran off its own annotations. And this wouldn't even have to conflict with the standard handler, if it delegated for cases that were not annotated. I just don't see it for the standard algorithm.
With this, I'd be pretty happy to get rid of the faces-config.xml if I
don't like it.
regards,
Martin
Craig
