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
--
| 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