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 <[EMAIL PROTECTED]> 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
