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://
<
http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
<
http://ww.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
>