Yes, I am just looking to be able to re-render items to reflect server-side messages. This could be actual message and label components, or other components (like for example, setting the style class of an input text that has a message). So it really should not be only message components, but all components should have the ability to re-render if there are messages.
I am not using client side validation (I have it turned off) and am planning on using the Hibernate validation framework with the Seam validate and validateAll tags. I am doing this so that I can centralize the validation of a model class to one location (so if 5 views all reference the same class, I only need to write the validation code once). Thank you, Andrew On 8/29/07, Adam Winer <[EMAIL PROTECTED]> wrote: > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
