You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Andrew Robinson <an...@gmail.com> on 2007/08/27 22:31:25 UTC
[Trinidad] ppr: partialTriggers doesn't work if there are validation messages?
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
Re: [Trinidad] ppr: partialTriggers doesn't work if there are validation messages?
Posted by Andrew Robinson <an...@gmail.com>.
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 server. 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.
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
On 8/28/07, Adam Winer <aw...@gmail.com> 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 <an...@gmail.com> wrote:
> > But the action should not be immediate, only the effect of the re-rendering
> >
> > On 8/28/07, Adam Winer <aw...@gmail.com> wrote:
> > > On 8/28/07, Andrew Robinson <an...@gmail.com> 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 <si...@gmail.com> 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 <an...@gmail.com> 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
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: [Trinidad] ppr: partialTriggers doesn't work if there are validation messages?
Posted by Adam Winer <aw...@gmail.com>.
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 <an...@gmail.com> wrote:
> But the action should not be immediate, only the effect of the re-rendering
>
> On 8/28/07, Adam Winer <aw...@gmail.com> wrote:
> > On 8/28/07, Andrew Robinson <an...@gmail.com> 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 <si...@gmail.com> 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 <an...@gmail.com> 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
> > > > >
> > > >
> > > >
> > >
> >
>
Re: [Trinidad] ppr: partialTriggers doesn't work if there are validation messages?
Posted by Andrew Robinson <an...@gmail.com>.
But the action should not be immediate, only the effect of the re-rendering
On 8/28/07, Adam Winer <aw...@gmail.com> wrote:
> On 8/28/07, Andrew Robinson <an...@gmail.com> 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 <si...@gmail.com> 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 <an...@gmail.com> 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
> > > >
> > >
> > >
> >
>
Re: [Trinidad] ppr: partialTriggers doesn't work if there are validation messages?
Posted by Adam Winer <aw...@gmail.com>.
On 8/28/07, Andrew Robinson <an...@gmail.com> 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 <si...@gmail.com> 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 <an...@gmail.com> 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
> > >
> >
> >
>
Re: [Trinidad] ppr: partialTriggers doesn't work if there are validation messages?
Posted by Andrew Robinson <an...@gmail.com>.
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.
On 8/28/07, Simon Lessard <si...@gmail.com> 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 <an...@gmail.com> 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
> >
>
>
Re: [Trinidad] ppr: partialTriggers doesn't work if there are validation messages?
Posted by Simon Lessard <si...@gmail.com>.
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 <an...@gmail.com> 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
>