If you want to keep the "[-NO-RAW-INPUT-]" approach, this won't
prevent me to sleep tonight, but then I think you should get rid of
the modelUpToDate property.
I hate to have another boolean for every formcomponent off every version of the page over all the pages that are in the session.
it's a pitty that we just can't use the null value as a valid one. Because the input from the browser can be null of course.
The modelUpToDate property is already gone. I just commeted it out for now. will be removed completely.
- I would have been pleased if you had filled the "due-to" section of
the changes.xml doc concerning the 2 proposals I made on the list.
(Form aware things solution, & html escaping fix in
FormComponent.getValue ()). It took me time to do this, and this little
reward would have been welcomed (it's not too late to correct this,
though ;-).
i will do.
I also have to do Christian's Submit links, that also touches that area a bit.
- changes.xml:
You wrote:
<action type="add" dev="Johan Compagner">Form will hold the values now
in its own state until everything is validated</action>
I think the following sentence may been better explain the fix :
<action type="add" dev="Johan Compagner" due-to="Laurent
Petit">FormComponent will now hold the values until they are
(successfully) validated</action>
I don't agree 100% because you don't think about formcomponents holding something.
It is the form that holds all its data (that it uses the formcomponents for that is an implementation detail)
and the form will if it knows everything is valid and then everythign is pushed to the models.
A formcomponent for example doesn't hold valueS , it holds a value.
i made it this:
"The Form will hold the values now in its own state until everything is (successfully) validated to the model(s)"
- Form.java:
It seems that in your commit you've mixed the fix that allows
FormComponents to keep the user input until they are successfully
validated, with something else, related to cssId.
I have a remark and a question on this:
- remark: I can see in the code this line :
tag.put("action",
Strings.replaceAll(urlFor(IFormSubmitListener.class), "&", "&"));
This reminds me on the current discussion we have with the possibility
that ComponentTag class could just do the html escaping as a service
for Components developers. If the team accepts this modification, then
it may be possible that this line has to be updated (getting rid of
the Strings.replaceAll() call).
This code doesn't have anything to do with one of the fixes. It was already there.
But we could push it all to ComponentTag and see if that works for all cases.
Will try to do that this weekend.
For me holding values in the Form is because of the other fix. That you can now have
events on anything in the form (see DropDown selection change) and don't do that with a get request
but with a form submit so that everything a user already fills in stays there.
- question: could you enhance the javadoc of the methods
getCssId() and onComponentTagBody() in order to explain the purpose of
the cssId stuff ?
will be resolved some time in the further. Because i just to name the form right so that i can call submit on it
in a event dispatch call.
johan
