myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Marinschek" <>
Subject Re: Playing round with 1.5 features
Date Tue, 28 Mar 2006 18:46:57 GMT
It's all a long question with a short answer: if there are users who
want it, why not add it?

The XDoclet JSF plugin, as an example, has annotations for navigation
rules, so obviously there is a need for it.

Why not make them available, and let the users decide what they want
to use? (it's all optional, don't forget that ;)

I still believe it should be the users (and of course the dev's who do
it) decision. And if there's someone who implements it, we should
gracefully accept it.



On 3/28/06, Sylvain Vieujot <> wrote:
>  I don't think we should rule out the use of annotations for navigation
> rules.
>  Even if navigation rules are tied to the presentation layer, so are bean
> names.
>  I also see good user cases for navigation rules defined as annotations.
>  Here is just an example :
>  In my projects there is a "management part" that always goes under the same
> protected URL, and that I reuse in several war files.
>  For this, I include a jar file that contains the code, and I also include
> the corresponding jsp pages.
>  I could use a corresponding xml fragment that I add in each of my
> projects's faces-config, but the I would then have to maintain it in each
> project.
>  In such cases, using annotations, and having a plugin that automatically
> appends them in the faces-config file is a better solution.
>  Also, using annotations make it possible to have a JSF project with no
> faces-config.xml file.
>  So forcing such project to have an xml file just for the navigation rules
> would make little sense.
>  I think the user should be able to decide by himself where to use
> annotations.
>  Preventing him to use annotations for navigation rules only because we
> could argue it's not good programmation seems a little too inquisitorial --
> and in some cases just wrong.
>  Just one last work comparing the plugin approach to the Shale-Tiger one :
>  One problem with annotations is that usually it's harder to debug.
>  For example I use annotations with hibernate, and it makes debugging a
> little harder as it's not always that clear what configuration gets
> generated.
>  With the plugin, you can both have the plugin control the configuration for
> you at compile time, and see the generated faces-config.xml.
>  One good example of that is if you have two beans with a similar name.
> Without the plugin, in a large faces-config xml file it could be hard to
> spot, and with Shale-Tiger, you would get the error at deployment time.
>  Finally, in the prototype plugin we did, you can either have everything in
> annotations (and no faces-config.xml), or have a faces-config.xml faces with
> a market that tells the plugin where to add the annotations related
> configuration.
>  Sorry for this long email, and I hope we can soon agree on this "sandbox
> 1.5" so that we can share that code/plugin with you all.
>  Sylvain.
>  On Mon, 2006-03-27 at 10:52 -0800, Craig McClanahan wrote:
>  On 3/27/06, Gary VanMatre <> 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


Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

View raw message