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