Fair enough. However, my event handling proposal
(
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-968), could
have done this:
<f:event type="viewAction">
log("page foo accessed");
</f:event>
However, by making it an ActionSource2 which invokes an event (instead
of directly invoking the event), there may be some extra work to
integrate these 2 features.
Yes, this was an argument for simplification (less is more). But if
being more explicit by having more tags is preferred... so be it.
Thanks!
-Ken
On 06/17/2011 09:47 AM, Ed Burns wrote:
>>>>>> 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
>