>>>>> 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.
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.
[...]
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?
Thanks,
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/