On 10/29/06, Ernst Fastl <[EMAIL PROTECTED]> wrote:
I think that the developers of projects like that did not actually understand the reasoning behind the standard JSF approach to navigation.
The basic theory is that an action method should return a *logical outcome* -- a string that says "this is what happened", not a string that says "go to this page next". That decision should be left to the architect who is gluing things all together. In particular, you should *want* to have the ability to remodel your view identifiers namespace, *without* having to go modify every single action method that returns a view id instead of a logical outcome.
Consider the following use case to understand what's going on here. Lots of web sites have search text fields (like Google's search text field) that can be used to select the relevant database information. Let's assume, for the purposes of discussion, that such a text field exists to select a customer from your database of current customers. Next, let's look at this issue from the viewpoint of the developer who is writing the action method that responds to a user entering a value into the search field. If you are following good application design principles, this person will *not* know (or care) about what page should be displayed next. Instead, he or she will be focused on the fact that there are three logical outcomes that can result from a database search based on criteria specified in the search field:
* No matching results were found.
* Exactly one matching result was found.
* More than one matching result was found.
In a very simple minded application (or a RAD-developed prototype), you might be satisfied with only doing one thing in all three cases. In a user-friendly app, on the other hand, you might want to react like this:
* No results -- show the search criteria page again with
a message saying "I'm sorry, no matches were found --
please refine your search criteria".
* Exactly one result -- go directly to the next step in the
user conversation, having selected a particular master record.
* More than one result -- go to a page that lists the available
matches and lets the user select the desired one.
The key issue here ... THE DEVELOPER WRITING THE ACTION METHOD FOR THE SEARCH SHOULD NOT NEED TO KNOW WHAT HAPPENS NEXT. The important responsibility is to report "this is what happened" (one of the three logical outcomes). It's up to the rest of the application to react to this event. And, over the lifetime of the application, this reaction might change -- but you should *not* have to go back and do the original code over again.
Given this background, I believe that the proposed feature here is *not* a good idea. It is counter to the basic philosophy behind the navigation handler architecture that the JSF spec defines.
Hi!
At the moment when no navigation case for an outcome is found
the navigationHandler decides to stay at the same view. I think
an option for web.xml would be useful to tell the navigationHandler
if no navigation case for an outcome is found, but the outcome
matches a viewId to navigate to this view id.
This idea was mainly driven by a lot of jsf-projects where I saw for each
view id:
<navigation-rule>
<from-view-id>*</from-view-id>
<navigation-case>
<from-outcome>viewId</from-outcome>
<to-view-id>/viewId.xhtml</to-view-id>
<redirect/>
</navigation-case>
...
which seems kind of unnecessary to me
what do you think about that?
I think that the developers of projects like that did not actually understand the reasoning behind the standard JSF approach to navigation.
The basic theory is that an action method should return a *logical outcome* -- a string that says "this is what happened", not a string that says "go to this page next". That decision should be left to the architect who is gluing things all together. In particular, you should *want* to have the ability to remodel your view identifiers namespace, *without* having to go modify every single action method that returns a view id instead of a logical outcome.
Consider the following use case to understand what's going on here. Lots of web sites have search text fields (like Google's search text field) that can be used to select the relevant database information. Let's assume, for the purposes of discussion, that such a text field exists to select a customer from your database of current customers. Next, let's look at this issue from the viewpoint of the developer who is writing the action method that responds to a user entering a value into the search field. If you are following good application design principles, this person will *not* know (or care) about what page should be displayed next. Instead, he or she will be focused on the fact that there are three logical outcomes that can result from a database search based on criteria specified in the search field:
* No matching results were found.
* Exactly one matching result was found.
* More than one matching result was found.
In a very simple minded application (or a RAD-developed prototype), you might be satisfied with only doing one thing in all three cases. In a user-friendly app, on the other hand, you might want to react like this:
* No results -- show the search criteria page again with
a message saying "I'm sorry, no matches were found --
please refine your search criteria".
* Exactly one result -- go directly to the next step in the
user conversation, having selected a particular master record.
* More than one result -- go to a page that lists the available
matches and lets the user select the desired one.
The key issue here ... THE DEVELOPER WRITING THE ACTION METHOD FOR THE SEARCH SHOULD NOT NEED TO KNOW WHAT HAPPENS NEXT. The important responsibility is to report "this is what happened" (one of the three logical outcomes). It's up to the rest of the application to react to this event. And, over the lifetime of the application, this reaction might change -- but you should *not* have to go back and do the original code over again.
Given this background, I believe that the proposed feature here is *not* a good idea. It is counter to the basic philosophy behind the navigation handler architecture that the JSF spec defines.
regards
Ernst
Craig McClanahan
