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
