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