If I understand it correctly, your concern here is basically that we're not displaying validation errors correctly after an event is submitted?
(We do, or at least should, re-display tr:messages during PPR, but not the messages next to the individual components. If your page doesn't have a tr:messages on it, I'd recommend adding one.) If that's the issue, then we should tackle that, which is a clear functionality gap that doesn't require architectural changes, and shouldn't require any end developer code - those messages should just get displayed on the client. -- Adam On 8/28/07, Andrew Robinson <[EMAIL PROTECTED]> wrote: > Yes, I fully understand the JSF lifecycle, but that doesn't address my > problem. The problem is that the partialTriggers functionality of the > UIXCommand components depends on the broadcasting of the ActionEvent. This > event's phase cannot be changed without drastically affecting the > application. > > The question is this: > > How can an web application developer re-render a component as a result of a > validation or conversion error during a partial submission of a UIXCommand > component without writing a custom component or custom renderer? > > -Andrew > > > On 8/28/07, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > > > > > > > >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 se rver. 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 > me thod < BR>> > > > > 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 > > &g t; > ; > > > > 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}" > > > > > > > & gt; &g t; 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 diffe rent 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > >
