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
>