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
> > > > >
> > > >
> > > >
> > >
> >
>

Reply via email to