jsr344-experts@javaserverfaces-spec-public.java.net

[jsr344-experts] UIViewRoot API review

From: Andy Schwartz <andy.schwartz_at_oracle.com>
Date: Wed, 13 Mar 2013 14:39:46 -0400

Comments on the following new UIViewRoot API:

Index: javax/faces/component/UIViewRoot.java
===================================================================
--- javax/faces/component/UIViewRoot.java (revision 8845)
+++ javax/faces/component/UIViewRoot.java (revision 11719)

+ * <p class="changed_added_2_2">Visit the clientIds and, if the
component is
+ * an instance of {_at_link EditableValueHolder},
+ * call its {_at_link EditableValueHolder#resetValue} method.
+ * Use {_at_link #visitTree} to do the visiting.</p>
+ *
+ * @since 2.2
+
+ * @param context the {_at_link FacesContext} for the request we are
processing.
+ * @param clientIds The client ids to be visited, on which the
described action will be taken.
+ */
+
+ public void resetValues(FacesContext context, Collection<String>
clientIds)

Is the idea that the client id of every EditableValueHolder to reset
must be explicitly specified in the clientIds collection? If so, this
seems bad.

The clientIds collection should specify ancestor components, under which
all EditableValueHolders should be reset.

So, for example, given a form like:

  <h:form id="bestFormEver">

    <!-- 100 EditableValueHolder components here -->

  </h:form>

A call to:

  root.resetValue(context, Collections.singleton("bestFormEver"));

Should reset all of the values of the EditableValueHolders under the form.

Similarly, this:

  <f:ajax render="@form" resetValues="true">

Should reset all of the EditableValueHolders under the form.

Or, at least, I think that is the desired behavior. Seems like it would
be annoying and error prone to force page authors to explicitly list
each EditableValueHolder to reset individually in the execute/render lists.

Do folks agree?

Andy