I also agree with Ed, Kito and Arjan. In the effort to make JSF easier to use, adding yet another way in which to perform navigation may cause some confusion. I think the current techniques are sufficient.
Josh Juneau
http://jj-blogger.blogspot.com
https://www.apress.com/index.php/author/author/view/id/1866
> On Oct 23, 2014, at 9:39 PM, Kito Mann <kito.mann_at_virtua.com> wrote:
>
> I agree with Ed's decision; the current implicit navigation does enough anyway:
>
> <h:commandButton value="submit" actionListener="#{service.method()}"
> action="'index"" />
>
> ___
>
> Kito D. Mann | @kito99 | Author, JSF in Action
> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
> http://www.JSFCentral.com | @jsfcentral
> +1 203-998-0403
>
> * Listen to the Enterprise Java Newscast: http://enterprisejavanews.com
> * JSFCentral Interviews Podcast: http://www.jsfcentral.com/resources/jsfcentralpodcasts/
> * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17
>
>> On Thu, Oct 23, 2014 at 5:40 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>> Hi,
>>
>> On Thu, Oct 23, 2014 at 12:16 AM, <marcojanc_at_hotmail.com> wrote:
>> > > https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1176
>>
>> > Why is the navigation outcome handled in the called method of the bean and not within the the view?
>> > Should the view not be as much separated from the logic as possible, especially if reusing code.
>>
>> There might be a small confusion here, let me try to explain how I see it:
>>
>> In MVC the view should indeed be separated from the (business) logic.
>> However, according to current best practices in JSF the bean that you
>> bind to from the component does *not* represent that logic. Instead,
>> this so-called backing bean is a piece of glue code that sits between
>> the view and the real model (business logic). This backing bean is
>> then typically injected with a service of some kind, and it translates
>> any return values or exceptions from that service into navigation
>> outcomes (if navigation rules are used) or lately increasingly just
>> outcomes directly.
>>
>> In the context of Java EE I gave an example of this approach here:
>> http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition#Code_sample
>> and specifically for JSF elaborated on it here:
>> http://stackoverflow.com/a/10114158
>>
>> So in many cases backing beans that process action commands are
>> tightly coupled to a specific view and are not at all meant to be
>> reusable.
>>
>> While I do see a little value in bringing some limited amount of
>> navigation rule like syntax to the view template, I'm afraid that this
>> proposal is based on the idea of directly binding true services to an
>> action (correct me if I'm wrong), which in most situations is not
>> really a best practice. Think about giving feedback to the user about
>> what happened and handling errors and exceptions.
>>
>> If you really wanted to do this, you may do something like the
>> following instead:
>>
>> <h:commandButton value="submit" actionListener="#{service.method()}"
>> action="#{outcome.do('/index.xhtml')]" />
>>
>> In the above, "outcome" would be an @Named utility bean with a single
>> String do(String outcome) method that just directly returns its
>> argument.
>>
>> Just my 2 cents
>>
>> Kind regards,
>> Arjan Tijms
>