2011/6/17 Ken Paulsen <kenapaulsen_at_gmail.com>:
>
> 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.
>
In theory if f:viewAction is ActionSource2 this code should be valid:
<f:viewAction ...>
<f:actionListener ... />
</f:viewAction ...>
But checking the interface, there are two methods:
public boolean isImmediate();
public void setImmediate(boolean immediate);
that does not have sense for f:viewAction, since this is activated as
soon as the metadata is built (restore view phase). Even if use
ActionEvent and ActionListener interfaces has sense, it is not an
ActionSource2 fully compliant from a strict point of view.
Leonardo Uribe
> -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
>>
>