2011/6/17 Leonardo Uribe <lu4242_at_gmail.com>:
> 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.
>
Checking more carefully I notice this comment on JAVASERVERFACES_SPEC_PUBLIC-758
"... Andy Schwartz clarifies:
1. View actions would be processed during invoke application phase.
PreRenderView events are delivered during the render response phase. ..."
so immediate has sense, since this works in a similar way as any other
command button/link.
In my personal opinion, make this component implement ActionSource2,
allowing f:actionListener and this tag work together looks better.
Leonardo
> 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
>>>
>>
>