Ed Burns wrote:
>> I agree, let's add events as needed, but this thing really is an
>> ActionSource2.
An ActionSource2 is an interface used to help fire events. It typically
is implemented by a component and has something visual for the user to
trigger the "action" which leads to firing the event. In this case
there is nothing visual, it's only used to fire an event (an
ActionEvent). That's the same thing f:event does. So I'm unclear by
what you mean when you say "this thing really is an ActionSource2."
What does using ActionSource2 allow that implementing this via <f:event>
does not allow?
I do realize an ActionSource has a default listener that invokes a
method and uses its return value for navigation. We can do the same
with the return value for an event to get the same behavior.
-Ken
On 06/17/2011 08:58 AM, Ed Burns wrote:
> SECTION: Catchup content
>
>>>>>> On Fri, 10 Jun 2011 11:22:04 -0700, Ken Paulsen<kenapaulsen_at_gmail.com> said:
> KP> However, I wonder if some of the details are a result of implementation
> KP> limitations (missing events). I think this may be solved in a more
> KP> standard-JSF-way by adding the missing events and perhaps enhancing the
> KP> navigation capabilities. Then<h:event> can be used to accomplish the
> KP> same -- no need for a new tag/concept.
>
> IO> while adding the missing events is probably something we should do
> IO> too. A<f:event> will never be as easy to use as a<f:viewAction
> IO> action="#{....}"/> which will add the benefit, that a
> IO> templateauthor/developer will not have to work with the
> IO> navigationhandling directly, (s)he will just need to return an
> IO> outcome as usual to change the view.
>
> I agree, let's add events as needed, but this thing really is an
> ActionSource2.
>
>>>>>> On Fri, 10 Jun 2011 20:44:14 +0200, Imre Osswald<ioss_at_mx.jevelopers.com> said:
> IO> As<f:viewAction> is close to<h:commandButton/Link> (It's an ActionSource2 anyway), I think:
>
> IO> - We should use the 'rendered' and 'disabled' attributes instead of
> IO> an 'if'. While I can see the beauty of the 'if', especially as
> IO> nothing "gets rendered", I think most developers are used to use
> IO> 'rendered' to "disable" a component.
>
> The 20110616 snapshot has "if" but you know, I'm coming around to
> "rendered" for this. I could be persuaded either way.
>
> IO> - viewAction should have an 'actionListener'-attribute too. (And it
> IO> should also allow for "child-listener-components" - I haven't
> IO> checked the source-code so far, if these would work out of the box)
>
> Yes, I agree it should, and the 20110616 snapshot does allow it.
>
>>>>>> On Fri, 10 Jun 2011 16:02:13 -0700, Alexander Smirnov<alsmirnnov_at_gmail.com> said:
> AS> +100 to keep component semantics the same as for commandLink/Button.
> AS> The only attribute that seems specific to that component is
> AS> "onPostback", because metadata action processed for both postback and
> AS> get requests.
>
> AS> Also, I suggest to append "phase" attribute for all command
> AS> components, not only to ViewActions. For example, command processed
> AS> after validation phase suitable to verify user input without model
> AS> update.
>
> People have a hard enough time with the lifecycle as it is already. I
> am open to persuasion, but my first reaction is no.
>
> SECTION: New questions
>
> Now, what I've specified in the 20110616 snapshot needs more work. Most
> importantly is the business of what happens in
> UIViewAction.broadcast(). The JBoss implementation has some tricky
> business involving getting a reference to the Lifecycle instance and
> manually calling execute(). I don't like this.
>
> Is it possible we could specify that the server should send a 302
> redirect with the necessary query parameters that will cause the same
> effect?
>
> This is really where I need that sample app.
>
> Ed
>