On 11/16/05, Laurent PETIT <[EMAIL PROTECTED]> wrote:
Hello Eelco,
First of all, let's agree that your use case is not a typical one. We
shouldn't make core adjustements that would make things easier for 5%
but harder for 95% of the cases.
Not sure if you're talking about Matej's or mines (a drawback of the
GMail's view ...) ;-)
Matje's.
I don't understand why you would make things harder for 95% of the
other cases ? I think that simplicity can be combined with "proper"
default behaviour ?
It wouldn't nescesarily be the case. I just wanted to issue a warning
that we shouldn't make things more complex in order to make that 5% a
little bit easier.
Anyway, I think what you want can be done rather elegant now. Like you
outlined, you should use Button.defaultFormProcessing = false to begin
with. In your onSubmit methods of these buttons, you can manually
trigger validation and/ or model updates (e.g. call
Form.updateFormComponentModels).
Except if I didn't well understand the behaviour of the
defaultFormProcessing flag, I think this would not help in my use case
(if I add a New Banana, I definitely don't want to update the other
models at the same time, while still re-rendering the page with the
current user inputs).
By the time, I'll checkout the HEAD version, since Johan told about an
"immediant" button. I want to check what this is.
Johan referred to 'immediate' which was the name that I gave to the
property that is now defaultFormProcessing. I used immediate because
JSF (and Tapestry?) use that name. But other devs felt
defaultFormProcessing was a better name.
The point of that property is that once you set it off, you can do
form processing in any way you want - or at least that is the idea. So
you can do an update of all models, but you can also do a partial
update if you want. Same goes for validation.
The next trick is to use models specifically for your view layer, and
once you're done with your wizard style functionality, combine these
models into something you really need. You won't loose any input this
way.
Yes, but you will still lack the automatic field type validation and
conversion, won't you ? Because if I use models, and if I allow users
to temporarily enter bad inputs (such as "foo" in a numeric
textfield), my (intermediate) model will have to handle only strings.
For all form components then ... (except maybe those from combobox,
radio buttons & checkboxes).
And so, when my complete form is finally submitted, I will have to do
all the validations manually (required, type conversions, ranges,
...). Not so good, is it ?
If you are ready for validation, you can call Form.validate manually
or even for each form component you want to validate
FormComponent.validate. You can use FormComponent.isValid and/ or
Form.hasError to see whether that validation got you any errors.
I guess the IValidator should mainly be used for 1-1 validations,
"superficial" validations such as required, ranges, types, ....
Months ago, I worked on a form level validation interface for a couple
of days. But I abandonned it as it made things more complex than it
would actually helped people, and I focussed on openening up form
processing instead.
Yes, I'll dive into the code ASAP, so that (I hope so) my next posts
will be more constructive, and not only feature requests ;-)
That would be good. Patches or concrete improvement suggestions are
always welcome, at least for discussion :)
Eelco
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_idv28&alloc_id845&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
