>From: "Andrew Robinson" <[EMAIL PROTECTED]> > > 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. >
My take on it is that Trinidad uses the JSF lifecycle to achieve PPR. In the JSF Lifecycle, the UIViewRoot processes queued events for each phase by calling the broadcast on the source component for all phases except render response. The components queue events in the decode (apply request values) and can specify the phase they should be invoked in. I believe the default phaseId for the FacesEvent is ANY. In all of these cases, events are processed prior to checking if the response is completed or render response has be set to true. Take a look at the following methods in the UIViewRoot [1]. processDecodes - apply request values processValidators - process validators processUpdates - update model processApplication - invoke application [1] http://svn.apache.org/viewvc/myfaces/core/branches/1_1_5/api/src/main/java/javax/faces/component/UIViewRoot.java?view=markup > 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 > Gary > On 8/28/07, Adam Winer 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 wrote: > > > But the action should not be immediate, only the effect of the > > > re-rendering > > > > > > On 8/28/07, Adam Winer wrote: > > > > On 8/28/07, Andrew Robinson 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 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 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: > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
