myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <>
Subject Re: Option for NavigationHandler to support viewIds as outcome
Date Mon, 30 Oct 2006 09:15:39 GMT
On 10/29/06, Ernst Fastl <> wrote:
> 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.

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

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.

> Ernst

Craig McClanahan

View raw message