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 ...) ;-) I still do think that the use case I exposed (with monkeys) is great to show what could be the limits of the frameworks I test. Wicket is great at Component composition ? Great ! I have a good old Form composition problem for it ;-) And it's actually a problem I had with an old project (but of course not talking about monkeys and bananas, not that fun ;-), and it was a pain in the ass to do it "cleanly" with struts. 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 ? > 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. > 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 ? > Finally, regarding complex validations... As soon as you need to do > validations that are dependent on other model properties etc, it is > probably wise to leave the default validation path in Wicket. > IValidators are very useful for simple validations that are 1-1 > related to components, Sure, a solution that would imply to abandon even the power of the wicket-provided IValidators implementations for the (intermediate model) should be avoided. > but if you need to do more complex things, they > are probably more in your way than any help. If you want to do complex > validations easy, you can do them in onSubmit handler code. I guess the IValidator should mainly be used for 1-1 validations, "superficial" validations such as required, ranges, types, .... > Anyway, I think that when looking whether we can make things easier > for more complex use cases, we shouldn't be thinking too much about > how we can ease things automagically, but instead focus on flexibility i agree, things should remain straightforward for common use cases. Flexibility should allow to handle more complex use cases by replacing default behaviour with some other one. > and - maybe more important as not everyone seems to understand to > current form processing - clarity of form processing and it's possible > interception points. 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 ;-) cu, -- laurent ------------------------------------------------------- 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
