It is a simple case of showing the effects of the failed validation.
Take the following use case as an example:
User clicks on a register button to create a user account for a web site.
The user enters a username that is already in use and hits the
register/save button
A unique validator on the username field fails its validation and adds
a validation message to the faces context using the component. All
message components that are for this component as well as any messages
components that are not global have to be re-rendered to show the user
the validation error.
This is just one use case to illustrate the fact that at the very
least, message and messages components need to be re-rendered when
validation errors and conversion errors are thrown on the server. This
doesn't include any components that need to be re-rendered as a
result. For example, the panelLabelAndMessage component renders an
error icon in the label when there is an error message for the input
component. It is also common for people to style components different
(red border for example) when their validation fails.
The way Trinidad components are written, there is no way out of the
box to accomplish this. The commandLink and commandButton will only
run the partial trigger functionality if the action event is
broadcast. Therefore, there is a large gap in the PPR functionality to
allow code to trigger rendering when the renderResponse method is
called before the broadcasting of the event.
Now, doesn't it make sense for a message component to be triggered on
the fact that the command was executed (meaning the button was
clicked, form was submitted) but not necessarily that the JSF action
was run?
Even if you don't agree, you have to realize that the PPR currently
makes re-rendering impossible if renderResponse is called, shortening
the JSF lifecycle.
I realize that many people use client side validation with Trinidad
and therefore are less likely to have this issue, but there are
several reasons that client side validation is not a complete
solution.
With custom components and integration with the Tridindad APIs this
functionality is definitely possible, but it really should be provided
out of the box.
So to answer your question, there is absolutely no point in
re-rendering a message component if there isn't a validation error or
conversion error.
-Andrew
On 8/28/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> I don't understand that sentence... You're saying that you
> *do* want validation to fire, but want the components to
> re-render just the same? This seems odd... If validation
> fails, what state has changed such that you need updated
> content?
>
>
> -- Adam
>
>
> On 8/28/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
> > But the action should not be immediate, only the effect of the re-rendering
> >
> > On 8/28/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> > > On 8/28/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
> > > > I got it to work with a custom component. I created a component that
> > > > doesn't render, that simply houses children. In the queueEvent method
> > > > of that component, if the type of the event is ActionEvent, I then use
> > > > it to add components as partial targets.
> > > >
> > > > It just would be nice to have this supported by Trinidad out of the
> > > > box. A4J creates AjaxEvents that have their phase ID set to ANY, so
> > > > they fire almost immediately, and thus work regardless of what phases
> > > > are run.
> > > >
> > > > I'm just wondering if there would be any harm to moving the code from
> > > > the broadcast method to the queue method.
> > >
> > > Yes, there would be! It'd break the semantics of partialTriggers.
> > >
> > > If you want your action event to fire in the "ANY" phase, just set
> > > immediate="true".
> > >
> > > -- Adam
> > >
> > > >
> > > > On 8/28/07, Simon Lessard <[EMAIL PROTECTED]> wrote:
> > > > > Hello Andrew,
> > > > >
> > > > > To my knowledge, this is the desired behavior since PPR requests does
> > > > > not
> > > > > use a different lifecycle than a normal requests. However, since I
> > > > > had to
> > > > > deal with that with every single ADF Faces/Trinidad projects I was
> > > > > on, I
> > > > > made a new lifecycle that alter the behavior with PPR request by
> > > > > skipping
> > > > > required check validations and running validation and update model
> > > > > phases
> > > > > only on the PPR source then I restore the model value after the
> > > > > render to
> > > > > make sure the model does not stay polluted. Finally, I have to save
> > > > > all
> > > > > values that were pushed from PPR that way so that in further PPR
> > > > > requests
> > > > > (in case there's more than one PPR active element in the page), I
> > > > > push the
> > > > > value back to the model from the previous PPR requests. This last
> > > > > part is
> > > > > the source of most of the complexity but is required when populating a
> > > > > selectOneMenu's list of values from the value of two other fields for
> > > > > example.
> > > > >
> > > > >
> > > > > Regards,
> > > > >
> > > > > ~ Simon
> > > > >
> > > > >
> > > > > On 8/27/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
> > > > > > I have a login form with a login command link. The form is a
> > > > > > panelFormLayout with panelLabelAndMessage components with inputText
> > > > > > components (username and password).
> > > > > >
> > > > > > I have:
> > > > > > <tr:panelFormLayout partialTriggers="login">
> > > > > > ...
> > > > > > <f:facet name="footer">
> > > > > > <tr:group>
> > > > > > <tr:commandLink
> > > > > > id="login"
> > > > > > partialSubmit="true"
> > > > > > action="#{identity.login}"
> > > > > > text="#{messages.page_login_login}" />
> > > > > > ...
> > > > > >
> > > > > > Now the panel is not updated because the code to trigger the PPR is
> > > > > > in
> > > > > > the broadcast method of the UIXCommand (parent of the command link).
> > > > > > The validation error causes the ActionEvent to not be broadcast, and
> > > > > > thus the PPR is not properly triggered.
> > > > > >
> > > > > > Should this be considered a bug?
> > > > > >
> > > > > > Should the "adfContext.partialUpdateNotify(component);" call be made
> > > > > > from the queueEvent method rather than the broadcast method?
> > > > > >
> > > > > > Or is there a different way to do this that I am missing?
> > > > > >
> > > > > > Another nice feature would be to automatically have the
> > > > > > panelLabelAndMessage and panelFormLayout components automatically
> > > > > > get
> > > > > > re-rendered if there is a validation or conversion error in one of
> > > > > > their nested children components.
> > > > > >
> > > > > > Thanks,
> > > > > > Andrew
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
