On Mon, Sep 10, 2012 at 5:04 PM, Edward Burns <edward.burns_at_oracle.com> wrote:
> CC> This is the first draft of the proposal to provide an easy way for
> CC> resetting editable value holders that save their value at viewstate
> CC> after validation failures. Proposal is created by me and Kito Mann.
>
> [...]
>
> CC> SECTION: Proposed Solution
>
> CC> ACTION: Please read this section and comment for feedback.
>
> CC> resetInput attribute in f:ajax
>
> CC> This part fixes the case for ajax requests, most of the time, page author
> CC> would like to reset what is being updated just like in Ajax Reset button in the sample code.
> CC> If f:ajax resets the components to update by going through PartialViewContext.getRenderIds()
> CC> component values will be reset and model values will be used to display. Sample;
>
> CC> <h:commandButton value="Ajax Reset">
> CC> <f:ajax render="@form" execute="@this" resetInput="true|false"/>
> CC> </h:commandButton>
>
> I'm fine with this approach, but can you please write up instructions
> for implementing it? Alternatively, you could sign the Oracle
> Contributor Agreement, I could give you commit access, and you could
> implement it yourself. If you'd rather write instructions, make them
> suitably clear that someone familiar with a JSF implementation can look
> at them and apply the changes they request. For example, something like
>
> In the code that handles ajax partial responses, at the point in time
> where the individial UIComponent is being processed, if the component
> is an EditableValueHolder and the value of the resetInput attribute is
> true, do this, otherwise do that...
>
> This level of detail makes it so much easier to resolve issues.
That's doable. We should first decide how we're going to implement the
other case, though, because this implementation depends on that one.
>
> CC> For backward compatibility, default value of the resetInput attribute should be false. I know we don't want to add another context-param
> CC> but consider javax.faces.RESET_INPUT (false by default) to globally override the resetInput attribute setting. Still page authors
> CC> can override the global setting per component.
>
> I'd like to leave this part out for now.
Why?
>
> CC> Even though this functionality is integrated with f:ajax, the approach for resetting EditableValueHolders might be similar to to the PrimeFaces Extension solution.
>
> CC> ResetInput Tag
>
> CC> This tag goes in core namespace named <f:resetInput /> to cover non-ajax requests. This is the solution
> CC> used in PrimeFaces and MyFaces Trinidad.
>
> CC> <h:commandButton value="Non-Ajax Reset" immediate="true">
> CC> <f:resetInput for="firstname surname or an ancestor of these components" />
> CC> </h:commandButton>
>
> Yes, we do need this for the non-ajax case.
>
> CC> Explain how the behavior of this tag is different than than <f:ajax>
> May
> CC> Programmatic API
>
> CC> Programmatic API is provided for flexibility in case page authors would like to decide when to reset. There are
> CC> two places where we can add this;
>
> CC> FacesContext.reset(String clientId)
> CC> FacesContext.reset(String clientIds as varargs)
> CC> UIViewRoot.reset(String clientId)
> CC> UIViewRoot.reset(String clientIds as varargs)
>
> That method name is too broad, also, is it possible to use
> PartialViewContext for this? I know PartialViewContext is primarily
> used in an Ajax request, but because we are in fact doing a partial
> traversal here, it doesn't make sense to re-invent partial traversal
> code just for reset.
We could use something like resetEditableValueHolders() (ugh). Is the
PartialViewContext available for regular requests?
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/