On Thu, Sep 13, 2012 at 9:22 AM, Edward Burns <edward.burns_at_oracle.com>wrote:
> >>>>> On Mon, 10 Sep 2012 17:59:20 -0400, Kito Mann <kito.mann_at_virtua.com>
> said:
>
> KM> 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.
> EB>
> EB> [...]
> EB>
> CC> SECTION: Proposed Solution
> EB>
> CC> ACTION: Please read this section and comment for feedback.
> EB>
> CC> resetInput attribute in f:ajax
> EB>
>
> CC> This part fixes the case for ajax requests, most of the time, page
> CC> author would like to reset what is being updated just like in Ajax
> CC> Reset button in the sample code. If f:ajax resets the components to
> CC> update by going through PartialViewContext.getRenderIds() component
> CC> values will be reset and model values will be used to
> CC> display. Sample;
>
> CC> <h:commandButton value="Ajax Reset"> <f:ajax render="@form"
> CC> execute="@this" resetInput="true|false"/> </h:commandButton>
>
> EB> I'm fine with this approach, but can you please write up instructions
> EB> for implementing it? Alternatively, you could sign the Oracle
> EB> Contributor Agreement, I could give you commit access, and you could
> EB> implement it yourself. If you'd rather write instructions, make them
> EB> suitably clear that someone familiar with a JSF implementation can look
> EB> at them and apply the changes they request. For example, something
> like
> EB>
> EB> In the code that handles ajax partial responses, at the point in time
> EB> where the individial UIComponent is being processed, if the component
> EB> is an EditableValueHolder and the value of the resetInput attribute is
> EB> true, do this, otherwise do that...
>
> EB> This level of detail makes it so much easier to resolve issues.
>
> KM> That's doable. We should first decide how we're going to implement the
> KM> other case, though, because this implementation depends on that one.
>
> Ok, let's drill down on the non-ajax case.
>
The proposal states:
ResetInput Tag
This tag goes in core namespace named <f:resetInput /> to cover
non-ajax requests. This is the solution
used in PrimeFaces and MyFaces Trinidad.
<h:commandButton value="Non-Ajax Reset" immediate="true">
<f:resetInput for="firstname surname or an ancestor of
these components" />
</h:commandButton>
Cagatay, can you explain how the behavior of this tag is different than
than the modified <f:ajax>?
CC> For backward compatibility, default value of the resetInput
> CC> attribute should be false. I know we don't want to add another
> CC> context-param but consider javax.faces.RESET_INPUT (false by
> CC> default) to globally override the resetInput attribute
> CC> setting. Still page authors can override the global setting per
> CC> component.
>
> EB> I'd like to leave this part out for now.
>
> KM> Why?
>
> To keep it simple. But if you assert we simply must have *some*
> solution in place for global configuration, let's just put the
> context-param in there for now. We need a better name than what was
> proposed, though. I suggest
> javax.faces.VALIDATION_CAUSES_SUBMITTED_VALUE_CLEARED_ON_INPUTS. At the
> very least, this atrocious name will spur us to address the global
> configuration of this feature more elegantly.
>
How about javax.faces.CLEAR_SUBMITTED_VALUES_AFTER_VALIDATION?
What sort of solution would be more elegant?
>
> [...]
>
> CC> FacesContext.reset(String clientId)
> CC> FacesContext.reset(String clientIds as varargs)
> CC> UIViewRoot.reset(String clientId)
> CC> UIViewRoot.reset(String clientIds as varargs)
> EB>
> EB> That method name is too broad, also, is it possible to use
> EB> PartialViewContext for this? I know PartialViewContext is primarily
> EB> used in an Ajax request, but because we are in fact doing a partial
> EB> traversal here, it doesn't make sense to re-invent partial traversal
> EB> code just for reset.
>
> KM> We could use something like resetEditableValueHolders() (ugh). Is the
> KM> PartialViewContext available for regular requests?
>
> Kito, above you said, "We should first decide how we're going to
> implement the other case, though". I assume this is the "other case"
> you were talking about. Yes, the PartialViewContext is available for
> regular requests. Kito, run with that name you suggested. Can you
> write up a concrete javadoc specification for that method, in the
> context of the right class?
>
Sure. After we flesh out a couple of things, I can take a stab at a 2nd
version of the proposal.
>
> Thanks,
>
> Ed
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/
>