Hello Arjan Tijms,
i am not binding to real services but rather have abstracted some generic tasks into abstract classes.
For instance I have multiple beans like "AdminLoginBean" and "UserLoginBean" for respective classes "Admin" and "User" which both hold an generic object "LoginLogic" which is represented by a composite component.
This LoginLogic class has methods such as "String login(email, password, outcome)". So i am using your proposed workaround by passing the specific outcome to the composite and then to the bean method.
In my application i am seldom using the outcome of the bean method for navigation. Either GET or AJAX requests to same view.
regards
Marco Janc
> Date: Thu, 23 Oct 2014 23:40:53 +0200
> From: arjan.tijms_at_gmail.com
> To: users_at_javaserverfaces-spec-public.java.net
> Subject: [jsr372-experts mirror] Re: Separate implicit bean navigation from action method via additional outcome attribute
>
> 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