jsr344-experts@javaserverfaces-spec-public.java.net

[jsr344-experts] Re: [758-ViewActions] Point of departure

From: Ed Burns <edward.burns_at_oracle.com>
Date: Fri, 17 Jun 2011 09:47:07 -0700

>>>>> On Fri, 17 Jun 2011 09:25:35 -0700, Ken Paulsen <kenapaulsen_at_gmail.com> said:

KP> Ed Burns wrote:
>>> I agree, let's add events as needed, but this thing really is an
>>> ActionSource2.


KP> An ActionSource2 is an interface used to help fire events. It typically
KP> is implemented by a component and has something visual for the user to
KP> trigger the "action" which leads to firing the event. In this case
KP> there is nothing visual, it's only used to fire an event (an
KP> ActionEvent). That's the same thing f:event does. So I'm unclear by
KP> what you mean when you say "this thing really is an ActionSource2."
KP> What does using ActionSource2 allow that implementing this via <f:event>
KP> does not allow?

KP> I do realize an ActionSource has a default listener that invokes a
KP> method and uses its return value for navigation. We can do the same
KP> with the return value for an event to get the same behavior.

I like to think of f:viewAction as a button that fires automatically.
It's the ActionSource2 analog to f:viewParam, which is a ValueHolder. I
think your argument is an instance of the old XML fan out argument: Is
it better to have a smaller number of elements with more varying
behavior on each element, or is it better to have a larger number of
elements with each one being more specifically tailored to its usecase.

Here, I think the latter case wins the day.

Ed

-- 
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage:               | http://ridingthecrest.com/
| 35 Business Days til JSF 2.2 Public Review
| 123 Business Days til JSF 2.2 Proposed Final Draft