Eelco, Can you elaborate how validation in your new scheme will work for invisible components? Right now it seems to be a "bug" that invisible components are validated. Do you agree? If you do not agree, can you elaborate why it might be good to validate invisible components? For instance, if a field is required normally but for a particular reason it is made invisible the NotNull validator still runs.
Right now whenever we add a validator we try and check for the invisibility flag but putting that code check everywhere is getting a bit tedious :-). Thanks for all your hard work! Satisfied Wicket user, Shahid. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Kulak Sent: Sunday, July 10, 2005 2:24 PM To: [email protected] Subject: Re: [Wicket-develop] [ wicket-Bugs-1220639 ] form processing could be better defined Getting rid of IFormValidationStrategy will actually break some of my code. I created a ValidateVisiableComponents strategy for when I have many fields, but only a couple are visible (editing individual rows of a ListView). However, the rest of it sounds great (can't see it in CVS quite yet). This was really due for a reworking and I'm glad that it will be in the 1.1 release. On 7/10/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > I reworked the form handling. I didn't come up with a new strategy > class, as I think that would only make things fuzzier. I see no added > value in being able to provide a seperate extension mechism where most > of Wicket works with overriding the components themselve. For that > reason, I also got rid of IFormValidationStratey. Also, I removed > IFormValidator (which I introduced a couple of weeks ago in 1.1). > IFormValidator on itself was not a bad idea I think, but too many > possible strategies on it's usage exists, thus making form processing > more difficult to understand (should those validators be executed before > or after updating the models, and in the latter case, should the > model(s) be rolled back in case any validator reported an error?). > > Here's the current documentation of Form: > > Base class for forms. To implement a form, subclass this class, add > FormComponents (such as CheckBoxes, ListChoices or TextFields) to the > form. You can nest multiple buttons if you want to vary submit > behaviour. However, it is not nescesarry to use Wicket's button class, > just putting e.g. <input type="submit" value="go"> suffices. > > # By default, the processing of a form works like this: The submitting > button is looked up. A submitting button is a button that is nested in > this form (is a child component) and that was clicked by the user. If a > submitting button was found, and it has the immediate field true > (default is false), it's onSubmit method will be called right away, thus > no validition is done, and things like updating form component models > that would normally be done are skipped. In that respect, nesting a > button with the immediate field set to true has the same effect as > nesting a normal link. If you want you can call validate() to execute > form validation, hasError() to find out whether validate() resulted in > validation errors, and updateFormComponentModels() to update the models > of nested form components. > # When no immediate submitting button was found, this form is validated > (method validate()). Now, two possible paths exist: > > * Form validation failed. All nested form components will be marked > valid, and onError() is called to allow clients to provide custom > error handling code. > * Form validation succeeded. The nested components will be asked to > update their models and persist their data is applicable. After > that, method delegateSubmit with optionally the submitting button > is called. The default when there is a submitting button is to > first call onSubmit on that button, and after that call onSubmit > on this form. Clients may override delegateSubmit if they want > different behaviour. > > Please experiment with it (note that it will take a few hours before > annonymous cvs is synced), and as allways, comments are welcome! > > Eelco > > > Eelco Hillenius wrote: > > > Good idea. > > > > Eelco > > > > Igor Vaynberg wrote: > > > >>> 3. One of the things I wanted to tackle with this issue was that > >>> code like updating form components in a validate method doesn't make > >>> much sense. The whole processing should be broken up in clearer > >>> steps with methods that fit them, I'd like to see whether > >>> IFormValidationStrategy still suffices and we may need to provide a > >>> couple of call back/ template methods so that users can 'intercept' > >>> in the form processing. > >>> I'm still thinking about the best way, but jet lag strikes again. > >>> > >> > >> > >> How about renaming IFormValidationStrategy into > >> IFormProcessingStrategy and > >> having validation as part of that. That will clean things up since > >> validation is part of processing. > >> > >> Igor > >> > >> > >> > >> > >> ------------------------------------------------------- > >> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > >> from IBM. Find simple to follow Roadmaps, straightforward articles, > >> informative Webcasts and more! Get everything you need to get up to > >> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > >> _______________________________________________ > >> Wicket-develop mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/wicket-develop > >> > >> > > > > > > > > ------------------------------------------------------- > > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > > from IBM. Find simple to follow Roadmaps, straightforward articles, > > informative Webcasts and more! Get everything you need to get up to > > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > > _______________________________________________ > > Wicket-develop mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual > core and dual graphics technology at this free one hour event hosted by HP, > AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar > _______________________________________________ > Wicket-develop mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-develop > ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
