Re: Playing round with 1.5 features

[Martin Marinschek <ma...@gmail.com>]

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 <cr...@apache.org> wrote:
> On 3/27/06, Gary VanMatre <gv...@comcast.net> 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

Re: Playing round with 1.5 features

[Martin Marinschek <ma...@gmail.com>]

Hi Craig,

> 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."
>

You're right - the outcome describes "what happened". But it is used
in the navigation rule to determine "where you should go next".

So if you change the code (by returning something that is different
from the navigation rule outcome) the behaviour of the app will
change, right? I definitely see a point to keep both the navigation
rule and the action method with its outcome close together.

regards,

Martin

Re: Playing round with 1.5 features

[Adam Winer <aw...@gmail.com>]

On 4/3/06, Craig McClanahan <cr...@apache.org> wrote:
>
> On 4/2/06, Martin Marinschek <ma...@gmail.com> 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

Re: Playing round with 1.5 features

[Craig McClanahan <cr...@apache.org>]

On 4/2/06, Martin Marinschek <ma...@gmail.com> wrote:
>
> 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