On 8/28/07, Adam Winer <[EMAIL PROTECTED]> wrote: > 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.
... and so there's no confusion, I mean that those *server-side* messages should get just displayed on the client. As long as we have inline client-side validation in general, our Javascript is easily smart enough to deal with inserting error messages on the client, so we'd just need to update our rendering code to include a Javascript payload of all the per-component FacesMessages. -- Adam > > -- 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
