I'd like default error messages, although I'd like to suggest that when one's used, Wicket logged a debug message saying exactly what to set where in order to override it...
/Gwyn On 28/08/05, SourceForge.net <[EMAIL PROTECTED]> wrote: > Feature Requests item #1275198, was opened at 2005-08-28 18:34 > Message generated for change (Tracker Item Submitted) made by Item Submitter > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1275198&group_id=119783 > > Please note that this message will contain a full copy of the comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: core > Group: 1.1 > Status: Open > Priority: 5 > Submitted By: Eelco Hillenius (eelco12) > Assigned to: Nobody/Anonymous (nobody) > Summary: have formcomponents/ validation do more out-of-the-box > > Initial Comment: > If you look at validating conversion, I think there is > no reason why this shouldn't be done out-of-the-box for > FormComponents. Right after validation, the conversion > will happen for model updating. Currently, we do double > work (conversion for validation and for model > updating), and only when the user either coupled a > TypeValidator to the component, or provided a type > argument with the TextField constructor. This case > isn't even complete, as it doesn't take overriding > getConverter of a component into account. > > If we support conversion validation out-of-the-box, > this would be one thing less to worry about for users - > who now have to do this stuff manually to avoid > exceptions -; the default of messaging instead of > exceptions is much better anyway. As a side efffect, we > could optimize this, using the knowledge that > validation and model updating happens as part of the > same request. We can cache the conversion result of the > validation, and reuse that for our model update. > > A related rfe which I file with this one as it's also > about making using formcomponents and validation > easier, is to have a bunch of default error messages > (maybe even localized for the locales we can support) > delivered with Wicket. We could have default for stuff > like invalid types, invalid lengths, etc. The main > reason for wanting this, is that a lot of these > messages would be good enough for a large share of our > users (certainly including me), and that in that case > it saves them the effort of creating the messagebundles > over and over again. Hence, it could speed up > development with Wicket quite a bit. > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1275198&group_id=119783 > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Wicket-develop mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-develop > ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
