users@javaserverfaces-spec-public.java.net

[jsr372-experts mirror] Re: Separate implicit bean navigation from action method via additional outcome attribute

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Thu, 23 Oct 2014 23:40:53 +0200

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