On Jan 27, 2008 10:35 AM, Ryan Sonnek <[EMAIL PROTECTED]> wrote:
> On Jan 27, 2008 12:20 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > but then my app wont work. i add my own ajax behavior that knows how
> > to do all this... so i would have to override some method on the form
> > and tell it not to do its default thing? let me quote someone
> > "Yuk...I'd hate to go through my *entire* application and replace
> > org.apache.wicket.Form with com.mysite.MySpecialForm.  very messy." :)
>
> Yes, class extension IS messy.  That's the point of using behaviors,
> correct?  No, you wouldn't need to override a method in Form.  You'd
> override a method in Application or ApplicationSettings to set
> "useGlobalAjaxFormValidation"

will we also then have useGlobalAjaxComponentReplacement that is
enabled by default? cause you know...we could...

>
> on startup, the application would check this setting and attach a
> component instantiation listener to add this behavior to all forms.
>
> > your default is simply not good - updating feedback panels is rarely
> > enough. also a lot of times users add a feedback panel per form
> > component, so you will needlessly update tens of feedback panels
> > rather then the single one that needs it. not a good default.
>
> If it's such a shitty default,  WHY ship the
> AjaxFormValidatingBehavior with Wicket at all?!  What is the
> "preferred" way to do this?

because that class encapsulates the workflow needed to get this done,
so users dont have to reinvent the wheel. its there for you to use
optionally...if you want.

there is really no preferred way to use it because the usecase space
for this is huge across all applications. i dont really see anything
wrong with rolling your own form subclass, any ide can do a search and
replace for you. what next? someone wants their textfields not to trim
input globally, so we have to provide a hook for that?

> I *know* there are a million ways to do this, but that shouldn't stop
> a framework from having good default behavior.

good, so you can see where im coming from when i say what you suggest
is not a good default.

anyways, feel free to start a vote on this, because i fear this is a
kind of thread that can get pretty long without getting anything
accomplished...

-igor

>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to