+1
I'm working on this literally right now now for a client. It's a little
more nuanced than the OmniFaces solution, because sometimes you want to
reset the values for an Ajax request, and sometimes you don't. Regardless,
there needs to be a solution that's integrated with <f:ajax> behavior,
similar to what OmniFaces is doing or the <pe:resetInput> component from
PrimeFaces-Extensions (all of these are referenced in the issue tracker).
___
Kito D. Mann | @kito99 | Author, JSF in Action
Virtua, Inc. |
http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
@jsfcentral
+1 203-404-4848 x246
* Listen to the latest headlines in the JSF and Java EE newscast:
http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast
* Sign up for the JSFCentral Newsletter:
http://oi.vresp.com/?fid=ac048d0e17
On Mon, Jul 16, 2012 at 4:45 PM, Çağatay Çivici <cagatay.civici_at_gmail.com>wrote:
> Hi all,
>
> Almost every day, I see a reference to this issue in PrimeFaces forum and
> stackoverflow.
>
> Today's topics;
>
>
> http://stackoverflow.com/questions/11510758/jsf2-beanvalidation-reset-values-after-failure
>
> http://forum.primefaces.org/viewtopic.php?f=3&t=23381
>
> Almost every JSF extension library has a solution for this so better to
> address it in core for sure.
>
> Regards,
>
> On 06.Tem.2012, at 22:06, Kito Mann wrote:
>
> > Hello everyone,
> >
> > I just ran into this issue with a client. What's the status? Is
> http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1060 the issue of
> reference?
> > ___
> >
> > Kito D. Mann | twitter: kito99 | Author, JSF in Action
> > Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
> consulting
> > http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
> twitter: jsfcentral
> > +1 203-404-4848 x246
> >
> > * Join me at JAXConf with JSF Summit July 9-12 in San Francisco (JSF,
> Android, Cloud, Big Data, Java EE, and more): http://jaxconf.com/2012
> > * Listen to the latest headlines in the JSF and Java EE newscast:
> http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast
> >
> >
> >
> >
> > On Thu, Mar 15, 2012 at 2:34 PM, Leonardo Uribe <lu4242_at_gmail.com>
> wrote:
> > Hi Çağatay
> >
> > I think this is another use case where the evidence suggest we need a
> > way to calculate quickly a "search expression" for a real component
> > instance, like in:
> >
> > [jsr344-experts] Referencing composite component attributes in child
> > components outside of a tree traversal
> >
> > The first option is if we have a way to register a list of the
> > components that can be reset and then use that list to do a tree
> > traversal and reset the values, when the need arise.
> >
> > A tree traversal with a "search expression" that include in a string
> > all the ids of the parent components can be faster than a visitTree
> > call, because the expressions give information about the tree
> > structure.
> >
> > Other option is register a "listener". In MyFaces, some time ago I
> > changed the way how "binding" attribute works, to reset them when a
> > navigation occur. The idea is "binding" attribute is used, in
> > ComponentTagHandlerDelegate it is added a component listener to
> > PreDisposeViewEvent (a myfaces internal event) and when the navigation
> > changes a page, a visitTree with SKIP_ITERATION is done to clear the
> > view. Test done shows the additional visitTree call does not affect
> > the performance in a significant way, because other phases like render
> > response, restore view and process validation / invoke application
> > take a lot more time.
> >
> > Note the previous option is not optimal, because the whole tree will
> > be scanned. The most efficient one involves the "search expression"
> >
> > My proposal for this one could be:
> >
> > - Mark all components that can be resetted with an interface or with a
> > method (isResetable()?).
> > - Use a global listener attached to PostAddToViewEvent that checks if
> > the component implements that interface and if that so, save the
> > "search expression" to find that component. A search expression is
> > just the sequence of component ids including all its ancestors. For
> > example: j_id0:myForm:j_id_5:name without include rowIndex and other
> > information associated to the container. This value should be stored
> > in UIViewRoot attribute map or in a place with view scope. A listener
> > to PreRemoveFromViewEvent can be used to remove a search expression
> > from the list.
> > - When a reset is required, a tree traversal using the search
> > expression list is done that can quickly discard nodes and publish a
> > component event (ResetInputEvent).
> > - The component is responsible to handle this event overriding
> > UIComponent.processEvent(ComponentSystemEvent event), or subscribing a
> > listener (in this case override processEvent sounds better because
> > this could change according to the component).
> >
> > I think this is easy to do and doable on the spec, but the key point
> > is provide allow a more efficient way to traverse the component tree.
> > The proposal could include a new tag, but I don't have clear how to do
> > that. The important here is specify the algorithm to reset a
> > component.
> >
> > If it is necessary I can create a prototype.
> >
> > Suggestions are welcome.
> >
> > regards,
> >
> > Leonardo Uribe
> >
> > 2012/3/15 Çağatay Çivici <cagatay.civici_at_gmail.com>:
> > > "Bumping this."
> > >
> > > Leonardo, have you had the chance to think about the proposal?
> > >
> > > Today, another user encountered this well known case;
> > >
> > > http://forum.primefaces.org/viewtopic.php?f=3&t=19266&p=60198#p60198
> > >
> > > My original email;
> > >
> > > Hi all,
> > >
> > >
> > > I'd like to discuss something I've been thinking about lately. How to
> clear
> > >
> > > forms easily when validation fails?
> > >
> > >
> > > Consider this simple case;
> > >
> > >
> > > <h:form>
> > >
> > >
> > > <h:messages />
> > >
> > >
> > > <h:inputText value="#{pprBean.firstname}"
> required="true"/>
> > >
> > > <h:inputText value="#{pprBean.surname}"
> required="true"/>
> > >
> > >
> > > <h:commandButton value="Save">
> > >
> > > <f:ajax render="@form" execute="@form"/>
> > >
> > > </h:commandButton>
> > >
> > >
> > > <h:commandButton value="Reset"
> > >
> > > actionListener="#{pprBean.reset}">
> > >
> > > <f:ajax render="@form" execute="@this"/>
> > >
> > > </h:commandButton>
> > >
> > >
> > > <h:outputText value="#{pprBean.firstname}" id="display"
> />
> > >
> > >
> > > </h:form>
> > >
> > >
> > > Bean;
> > >
> > >
> > > private String firstname, surname;
> > >
> > >
> > > public void reset() {
> > >
> > > firstname = null;
> > >
> > > surname = null;
> > >
> > > }
> > >
> > >
> > > So when you run this, if one of the field is empty and the other is
> not,
> > >
> > > validations fails and message is displayed. Problem happens when reset
> > >
> > > button is clicked to reset the form values. At processValidations phase
> > >
> > > UIInput saves the converted value at state
> > >
> > > and since validation failed, update model is not executed so local
> value is
> > >
> > > never cleared. Clicking reset, clears the bean's values but inputText
> will
> > >
> > > not use the bound value and use the one kept in state as well ending
> up a
> > >
> > > confusing behavior. I've seen this in many forums.
> > >
> > >
> > > I know wiki's like this;
> > >
> > >
> > > http://wiki.apache.org/myfaces/ClearInputComponents
> > >
> > >
> > > But I mean shouldn't this work as expected? Proposed solutions seem
> way too
> > >
> > > hard just to clear form values. (component binding and calling
> resetValue(),
> > >
> > > new view, javascript etc.)
> > >
> > >
> > > If at processValidations phase, local value is not stored in state, I
> think
> > >
> > > that will make the code above work, but I'm not sure if there will be
> any
> > >
> > > side effects. Does anyone know why converted local value is kept at
> state by
> > >
> > > calling setValue(). Both mojarra and myfaces keeps the value at state
> and I
> > >
> > > cannot find anything regarding this in spec, please point me if I'm
> wrong.
> > >
> > >
> > > Regards,
> > >
> > > On 08.Ağu.2011, at 22:57, Leonardo Uribe wrote:
> > >
> > > Hi
> > >
> > > Doing some documentation improvements I notice this wiki page:
> > >
> > > http://wiki.apache.org/myfaces/ClearInputComponents
> > >
> > > It is a very old page, but I think it describes in some way what's
> > > missing. Other useful page is here:
> > >
> > >
> https://cwiki.apache.org/confluence/display/MYFACES/How+the+immediate+attribute+works
> > >
> > > I'll try to submit a proposal about it this week.
> > >
> > > regards,
> > >
> > > Leonardo Uribe
> > >
> > > 2011/8/8 <edward.burns_at_oracle.com>:
> > >
> > > Where does this thread stand?
> > >
> > >
> > > Alexander asserted that our existing immediate="true" feature was
> > >
> > > sufficient but Andy indicated there was another case for which an
> > >
> > > additional feature might be necessary?
> > >
> > >
> > > Because this issue was not in JSF_2_2_WORKING_SET, I'll need a detailed
> > >
> > > proposal in order to entertain including it at all. So far, I haven't
> > >
> > > seen enough detail.
> > >
> > >
> > > If there is no reply in a week, I'd like to close this issue out.
> > >
> > >
> > > Thanks,
> > >
> > >
> > > Ed
> > >
> > >
> > >
> > > Çağatay Çivici
> > > Principal Consultant
> > > PrimeFaces Lead | JSF EG Member
> > >
> > > Prime Teknoloji
> > > Bilkent Cyberpark, A-303d
> > > 06800 Ankara/Turkey
> > > Tel: +90 312 265 05 07
> > > http://www.prime.com.tr
> > >
> >
>
> Çağatay Çivici
> Principal Consultant
> PrimeFaces Lead
>
>