myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Marinschek" <martin.marinsc...@gmail.com>
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.

regards,

Martin

On 3/28/06, Sylvain Vieujot <svieujot@apache.org> 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 <gvanmatre@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

Mime
View raw message