You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Igor Vaynberg <ig...@gmail.com> on 2007/03/25 05:20:50 UTC
Re: form.onsubmit vs button.onsubmit
so should we change this in 1.3?
-igor
On 2/15/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> I agree with it now too. A typical thing you want to do in a button is
> do a component replacement (at least, that's what we do often here) of
> a component above the form. The problem with buttons being called
> before the form's onSubmit is that then the component is already
> detached from the page.
>
> Eelco
>
>
> On 2/15/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > i am going to resurrect this discussion again since we now have more
> > committers and none of you old ones have agreed with me before! i still
> > think this
> > is a good idea!
> >
> > the old thread can be seen here:
> >
> >
> http://www.nabble.com/form.onsubmit-vs-button.onsubmit-tf1977859.html#a5431105
> >
> > -igor
> >
> >
> > ---------- Forwarded message ----------
> > From: Igor Vaynberg <ig...@gmail.com>
> > Date: Jul 20, 2006 3:55 PM
> > Subject: form.onsubmit vs button.onsubmit
> > To: wicket-develop@lists.sourceforge.net
> >
> > i just noticed that we call button.onsubmit() /before/ form.onsubmit(),
> i
> > always believed this to be the other way around because that is more
> > intuitive - cascading onsubmit down the component hierarchy. is there a
> > reason why we do it "backwards"?
> >
> > i have also noticed a pattern where i group certain fields in a panel
> and
> > would like to let the panel also have an onsubmit() for processing. i
> was
> > thinking of implementing IFormSubmitAware { void onSubmit(); } and
> bubble
> > this down via a visitor in form.delegatesubmit() but of course with the
> > button getting called first it makes no sense.
> >
> > shall we reverse it in 2.0? should i put the iformsubmitaware into 2.0core?
> >
> > -Igor
> >
>
Re: form.onsubmit vs button.onsubmit
Posted by Igor Vaynberg <ig...@gmail.com>.
aha! thats what i thought. and given this, what use is form.onsubmit() ?
what kind of stuff can you put in there?
-igor
On 3/26/07, Matej Knopp <ma...@gmail.com> wrote:
>
> Well, I would generaly not put navigation logic to form's onSubmit. I
> always use button's onSubmit for things like that. I actually use
> Form.onSubmit rather rarely.
>
> But i didn't vote -1 for this.
>
> -Matej
>
> On 3/26/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > i find that funny coming from you seeing how you are the one who came up
> > with nesting forms.
> >
> > if you do your navigation logic inside the form's onsubmit and you nest
> > forms it will be broken wont it? that only leaves you one place to do
> > navigation logic, which is the button's onsubmit. but everything else
> must
> > be processed before you can decide where to navigate to - which makes
> form's
> > onsubmit useless. so if you think you have a usecase where your form
> might
> > be nested and you want to do navigation then you must do it in the
> button's
> > onsubmit. take reusability into account and then that always becomes the
> > case.
> >
> > -igor
> >
> >
> > On 3/25/07, Matej Knopp <ma...@gmail.com> wrote:
> > >
> > > I haven't read the whole discussion so I might be missing something.
> > > But I, personally, find calling button's onSubmit before form's more
> > > intuitive.
> > >
> > > -Matej
> > >
> > > On 3/25/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > +1
> > > >
> > > > Eelco
> > > >
> > > >
> > > > On 3/24/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > > so should we change this in 1.3?
> > > > >
> > > > > -igor
> > > > >
> > > > >
> > > > > On 2/15/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > > >
> > > > > > I agree with it now too. A typical thing you want to do in a
> button
> > > is
> > > > > > do a component replacement (at least, that's what we do often
> here)
> > > of
> > > > > > a component above the form. The problem with buttons being
> called
> > > > > > before the form's onSubmit is that then the component is already
> > > > > > detached from the page.
> > > > > >
> > > > > > Eelco
> > > > > >
> > > > > >
> > > > > > On 2/15/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > > > > i am going to resurrect this discussion again since we now
> have
> > > more
> > > > > > > committers and none of you old ones have agreed with me
> before! i
> > > still
> > > > > > > think this
> > > > > > > is a good idea!
> > > > > > >
> > > > > > > the old thread can be seen here:
> > > > > > >
> > > > > > >
> > > > > >
> > >
> http://www.nabble.com/form.onsubmit-vs-button.onsubmit-tf1977859.html#a5431105
> > > > > > >
> > > > > > > -igor
> > > > > > >
> > > > > > >
> > > > > > > ---------- Forwarded message ----------
> > > > > > > From: Igor Vaynberg <ig...@gmail.com>
> > > > > > > Date: Jul 20, 2006 3:55 PM
> > > > > > > Subject: form.onsubmit vs button.onsubmit
> > > > > > > To: wicket-develop@lists.sourceforge.net
> > > > > > >
> > > > > > > i just noticed that we call button.onsubmit() /before/
> > > form.onsubmit(),
> > > > > > i
> > > > > > > always believed this to be the other way around because that
> is
> > > more
> > > > > > > intuitive - cascading onsubmit down the component hierarchy.
> is
> > > there a
> > > > > > > reason why we do it "backwards"?
> > > > > > >
> > > > > > > i have also noticed a pattern where i group certain fields in
> a
> > > panel
> > > > > > and
> > > > > > > would like to let the panel also have an onsubmit() for
> > > processing. i
> > > > > > was
> > > > > > > thinking of implementing IFormSubmitAware { void onSubmit(); }
> and
> > > > > > bubble
> > > > > > > this down via a visitor in form.delegatesubmit() but of course
> > > with the
> > > > > > > button getting called first it makes no sense.
> > > > > > >
> > > > > > > shall we reverse it in 2.0? should i put the iformsubmitaware
> into
> > > 2.0core?
> > > > > > >
> > > > > > > -Igor
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: form.onsubmit vs button.onsubmit
Posted by Matej Knopp <ma...@gmail.com>.
Well, I would generaly not put navigation logic to form's onSubmit. I
always use button's onSubmit for things like that. I actually use
Form.onSubmit rather rarely.
But i didn't vote -1 for this.
-Matej
On 3/26/07, Igor Vaynberg <ig...@gmail.com> wrote:
> i find that funny coming from you seeing how you are the one who came up
> with nesting forms.
>
> if you do your navigation logic inside the form's onsubmit and you nest
> forms it will be broken wont it? that only leaves you one place to do
> navigation logic, which is the button's onsubmit. but everything else must
> be processed before you can decide where to navigate to - which makes form's
> onsubmit useless. so if you think you have a usecase where your form might
> be nested and you want to do navigation then you must do it in the button's
> onsubmit. take reusability into account and then that always becomes the
> case.
>
> -igor
>
>
> On 3/25/07, Matej Knopp <ma...@gmail.com> wrote:
> >
> > I haven't read the whole discussion so I might be missing something.
> > But I, personally, find calling button's onSubmit before form's more
> > intuitive.
> >
> > -Matej
> >
> > On 3/25/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > +1
> > >
> > > Eelco
> > >
> > >
> > > On 3/24/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > so should we change this in 1.3?
> > > >
> > > > -igor
> > > >
> > > >
> > > > On 2/15/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > >
> > > > > I agree with it now too. A typical thing you want to do in a button
> > is
> > > > > do a component replacement (at least, that's what we do often here)
> > of
> > > > > a component above the form. The problem with buttons being called
> > > > > before the form's onSubmit is that then the component is already
> > > > > detached from the page.
> > > > >
> > > > > Eelco
> > > > >
> > > > >
> > > > > On 2/15/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > > > i am going to resurrect this discussion again since we now have
> > more
> > > > > > committers and none of you old ones have agreed with me before! i
> > still
> > > > > > think this
> > > > > > is a good idea!
> > > > > >
> > > > > > the old thread can be seen here:
> > > > > >
> > > > > >
> > > > >
> > http://www.nabble.com/form.onsubmit-vs-button.onsubmit-tf1977859.html#a5431105
> > > > > >
> > > > > > -igor
> > > > > >
> > > > > >
> > > > > > ---------- Forwarded message ----------
> > > > > > From: Igor Vaynberg <ig...@gmail.com>
> > > > > > Date: Jul 20, 2006 3:55 PM
> > > > > > Subject: form.onsubmit vs button.onsubmit
> > > > > > To: wicket-develop@lists.sourceforge.net
> > > > > >
> > > > > > i just noticed that we call button.onsubmit() /before/
> > form.onsubmit(),
> > > > > i
> > > > > > always believed this to be the other way around because that is
> > more
> > > > > > intuitive - cascading onsubmit down the component hierarchy. is
> > there a
> > > > > > reason why we do it "backwards"?
> > > > > >
> > > > > > i have also noticed a pattern where i group certain fields in a
> > panel
> > > > > and
> > > > > > would like to let the panel also have an onsubmit() for
> > processing. i
> > > > > was
> > > > > > thinking of implementing IFormSubmitAware { void onSubmit(); } and
> > > > > bubble
> > > > > > this down via a visitor in form.delegatesubmit() but of course
> > with the
> > > > > > button getting called first it makes no sense.
> > > > > >
> > > > > > shall we reverse it in 2.0? should i put the iformsubmitaware into
> > 2.0core?
> > > > > >
> > > > > > -Igor
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: form.onsubmit vs button.onsubmit
Posted by Igor Vaynberg <ig...@gmail.com>.
i find that funny coming from you seeing how you are the one who came up
with nesting forms.
if you do your navigation logic inside the form's onsubmit and you nest
forms it will be broken wont it? that only leaves you one place to do
navigation logic, which is the button's onsubmit. but everything else must
be processed before you can decide where to navigate to - which makes form's
onsubmit useless. so if you think you have a usecase where your form might
be nested and you want to do navigation then you must do it in the button's
onsubmit. take reusability into account and then that always becomes the
case.
-igor
On 3/25/07, Matej Knopp <ma...@gmail.com> wrote:
>
> I haven't read the whole discussion so I might be missing something.
> But I, personally, find calling button's onSubmit before form's more
> intuitive.
>
> -Matej
>
> On 3/25/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > +1
> >
> > Eelco
> >
> >
> > On 3/24/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > so should we change this in 1.3?
> > >
> > > -igor
> > >
> > >
> > > On 2/15/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > >
> > > > I agree with it now too. A typical thing you want to do in a button
> is
> > > > do a component replacement (at least, that's what we do often here)
> of
> > > > a component above the form. The problem with buttons being called
> > > > before the form's onSubmit is that then the component is already
> > > > detached from the page.
> > > >
> > > > Eelco
> > > >
> > > >
> > > > On 2/15/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > > i am going to resurrect this discussion again since we now have
> more
> > > > > committers and none of you old ones have agreed with me before! i
> still
> > > > > think this
> > > > > is a good idea!
> > > > >
> > > > > the old thread can be seen here:
> > > > >
> > > > >
> > > >
> http://www.nabble.com/form.onsubmit-vs-button.onsubmit-tf1977859.html#a5431105
> > > > >
> > > > > -igor
> > > > >
> > > > >
> > > > > ---------- Forwarded message ----------
> > > > > From: Igor Vaynberg <ig...@gmail.com>
> > > > > Date: Jul 20, 2006 3:55 PM
> > > > > Subject: form.onsubmit vs button.onsubmit
> > > > > To: wicket-develop@lists.sourceforge.net
> > > > >
> > > > > i just noticed that we call button.onsubmit() /before/
> form.onsubmit(),
> > > > i
> > > > > always believed this to be the other way around because that is
> more
> > > > > intuitive - cascading onsubmit down the component hierarchy. is
> there a
> > > > > reason why we do it "backwards"?
> > > > >
> > > > > i have also noticed a pattern where i group certain fields in a
> panel
> > > > and
> > > > > would like to let the panel also have an onsubmit() for
> processing. i
> > > > was
> > > > > thinking of implementing IFormSubmitAware { void onSubmit(); } and
> > > > bubble
> > > > > this down via a visitor in form.delegatesubmit() but of course
> with the
> > > > > button getting called first it makes no sense.
> > > > >
> > > > > shall we reverse it in 2.0? should i put the iformsubmitaware into
> 2.0core?
> > > > >
> > > > > -Igor
> > > > >
> > > >
> > >
> >
>
Re: form.onsubmit vs button.onsubmit
Posted by Matej Knopp <ma...@gmail.com>.
I haven't read the whole discussion so I might be missing something.
But I, personally, find calling button's onSubmit before form's more
intuitive.
-Matej
On 3/25/07, Eelco Hillenius <ee...@gmail.com> wrote:
> +1
>
> Eelco
>
>
> On 3/24/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > so should we change this in 1.3?
> >
> > -igor
> >
> >
> > On 2/15/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > I agree with it now too. A typical thing you want to do in a button is
> > > do a component replacement (at least, that's what we do often here) of
> > > a component above the form. The problem with buttons being called
> > > before the form's onSubmit is that then the component is already
> > > detached from the page.
> > >
> > > Eelco
> > >
> > >
> > > On 2/15/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > i am going to resurrect this discussion again since we now have more
> > > > committers and none of you old ones have agreed with me before! i still
> > > > think this
> > > > is a good idea!
> > > >
> > > > the old thread can be seen here:
> > > >
> > > >
> > > http://www.nabble.com/form.onsubmit-vs-button.onsubmit-tf1977859.html#a5431105
> > > >
> > > > -igor
> > > >
> > > >
> > > > ---------- Forwarded message ----------
> > > > From: Igor Vaynberg <ig...@gmail.com>
> > > > Date: Jul 20, 2006 3:55 PM
> > > > Subject: form.onsubmit vs button.onsubmit
> > > > To: wicket-develop@lists.sourceforge.net
> > > >
> > > > i just noticed that we call button.onsubmit() /before/ form.onsubmit(),
> > > i
> > > > always believed this to be the other way around because that is more
> > > > intuitive - cascading onsubmit down the component hierarchy. is there a
> > > > reason why we do it "backwards"?
> > > >
> > > > i have also noticed a pattern where i group certain fields in a panel
> > > and
> > > > would like to let the panel also have an onsubmit() for processing. i
> > > was
> > > > thinking of implementing IFormSubmitAware { void onSubmit(); } and
> > > bubble
> > > > this down via a visitor in form.delegatesubmit() but of course with the
> > > > button getting called first it makes no sense.
> > > >
> > > > shall we reverse it in 2.0? should i put the iformsubmitaware into 2.0core?
> > > >
> > > > -Igor
> > > >
> > >
> >
>
Re: form.onsubmit vs button.onsubmit
Posted by Eelco Hillenius <ee...@gmail.com>.
+1
Eelco
On 3/24/07, Igor Vaynberg <ig...@gmail.com> wrote:
> so should we change this in 1.3?
>
> -igor
>
>
> On 2/15/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > I agree with it now too. A typical thing you want to do in a button is
> > do a component replacement (at least, that's what we do often here) of
> > a component above the form. The problem with buttons being called
> > before the form's onSubmit is that then the component is already
> > detached from the page.
> >
> > Eelco
> >
> >
> > On 2/15/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > i am going to resurrect this discussion again since we now have more
> > > committers and none of you old ones have agreed with me before! i still
> > > think this
> > > is a good idea!
> > >
> > > the old thread can be seen here:
> > >
> > >
> > http://www.nabble.com/form.onsubmit-vs-button.onsubmit-tf1977859.html#a5431105
> > >
> > > -igor
> > >
> > >
> > > ---------- Forwarded message ----------
> > > From: Igor Vaynberg <ig...@gmail.com>
> > > Date: Jul 20, 2006 3:55 PM
> > > Subject: form.onsubmit vs button.onsubmit
> > > To: wicket-develop@lists.sourceforge.net
> > >
> > > i just noticed that we call button.onsubmit() /before/ form.onsubmit(),
> > i
> > > always believed this to be the other way around because that is more
> > > intuitive - cascading onsubmit down the component hierarchy. is there a
> > > reason why we do it "backwards"?
> > >
> > > i have also noticed a pattern where i group certain fields in a panel
> > and
> > > would like to let the panel also have an onsubmit() for processing. i
> > was
> > > thinking of implementing IFormSubmitAware { void onSubmit(); } and
> > bubble
> > > this down via a visitor in form.delegatesubmit() but of course with the
> > > button getting called first it makes no sense.
> > >
> > > shall we reverse it in 2.0? should i put the iformsubmitaware into 2.0core?
> > >
> > > -Igor
> > >
> >
>
Re: form.onsubmit vs button.onsubmit
Posted by Gwyn Evans <gw...@gmail.com>.
Sorry, I thought it would be clear from the thread, but just for the
record, I'm -1 on this because my recollection is that we have in the
past documented the ordering involved and given that, I don't believe
we should change it in such a way that there's a likelihood that the
change would be overlooked.
Ideally I'd like some sort of compile-time warning, (no idea how
thought!) but failing that, at least an explict poll on the user list
to get an idea how much of an issue this might be & flag the
possibility of the change.
/Gwyn
On 26/03/07, Igor Vaynberg <ig...@gmail.com> wrote:
> gwyn, you cannot vote -1 without giving a reason
>
> -igor
>
>
> On 3/25/07, Gwyn Evans <gw...@gmail.com> wrote:
> >
> > Adding a setting:+0 Reversing the present order:-1
> > /Gwyn
> >
> > On 25/03/07, Martijn Dashorst <ma...@gmail.com> wrote:
> > > For me the argument still remains: you break a lot of stuff in a
> > > silent way. Why can't this be a setting on the form?
> > >
> > > The things you describe are at least very specific to one method of
> > > development, given that we can build web applications using the
> > > current method of development for over 2 years.
> > >
> > > Making it a setting with the default being the current way of
> > > processing sounds much safer than inverting it because of a method of
> > > development that is in swing now.
> > >
> > > Martijn
> > >
> > > On 3/25/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > so should we change this in 1.3?
> > > >
> > > > -igor
> > > >
> > > >
> > > > On 2/15/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > >
> > > > > I agree with it now too. A typical thing you want to do in a button
> > is
> > > > > do a component replacement (at least, that's what we do often here)
> > of
> > > > > a component above the form. The problem with buttons being called
> > > > > before the form's onSubmit is that then the component is already
> > > > > detached from the page.
> > > > >
> > > > > Eelco
> > > > >
> > > > >
> > > > > On 2/15/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > > > i am going to resurrect this discussion again since we now have
> > more
> > > > > > committers and none of you old ones have agreed with me before! i
> > still
> > > > > > think this
> > > > > > is a good idea!
> > > > > >
> > > > > > the old thread can be seen here:
> > > > > >
> > > > > >
> > > > >
> > http://www.nabble.com/form.onsubmit-vs-button.onsubmit-tf1977859.html#a5431105
> > > > > >
> > > > > > -igor
> > > > > >
> > > > > >
> > > > > > ---------- Forwarded message ----------
> > > > > > From: Igor Vaynberg <ig...@gmail.com>
> > > > > > Date: Jul 20, 2006 3:55 PM
> > > > > > Subject: form.onsubmit vs button.onsubmit
> > > > > > To: wicket-develop@lists.sourceforge.net
> > > > > >
> > > > > > i just noticed that we call button.onsubmit() /before/
> > form.onsubmit(),
> > > > > i
> > > > > > always believed this to be the other way around because that is
> > more
> > > > > > intuitive - cascading onsubmit down the component hierarchy. is
> > there a
> > > > > > reason why we do it "backwards"?
> > > > > >
> > > > > > i have also noticed a pattern where i group certain fields in a
> > panel
> > > > > and
> > > > > > would like to let the panel also have an onsubmit() for
> > processing. i
> > > > > was
> > > > > > thinking of implementing IFormSubmitAware { void onSubmit(); } and
> > > > > bubble
> > > > > > this down via a visitor in form.delegatesubmit() but of course
> > with the
> > > > > > button getting called first it makes no sense.
> > > > > >
> > > > > > shall we reverse it in 2.0? should i put the iformsubmitaware into
> > 2.0core?
> > > > > >
> > > > > > -Igor
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Learn Wicket at ApacheCon Europe: http://apachecon.com
> > > Join the wicket community at irc.freenode.net: ##wicket
> > > Wicket 1.2.5 will keep your server alive. Download Wicket now!
> > > http://wicketframework.org
> > >
> >
> >
> > --
> > Download Wicket 1.2.5 now! - http://wicketframework.org
> >
>
--
Download Wicket 1.2.5 now! - http://wicketframework.org
Re: form.onsubmit vs button.onsubmit
Posted by Igor Vaynberg <ig...@gmail.com>.
gwyn, you cannot vote -1 without giving a reason
-igor
On 3/25/07, Gwyn Evans <gw...@gmail.com> wrote:
>
> Adding a setting:+0 Reversing the present order:-1
> /Gwyn
>
> On 25/03/07, Martijn Dashorst <ma...@gmail.com> wrote:
> > For me the argument still remains: you break a lot of stuff in a
> > silent way. Why can't this be a setting on the form?
> >
> > The things you describe are at least very specific to one method of
> > development, given that we can build web applications using the
> > current method of development for over 2 years.
> >
> > Making it a setting with the default being the current way of
> > processing sounds much safer than inverting it because of a method of
> > development that is in swing now.
> >
> > Martijn
> >
> > On 3/25/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > so should we change this in 1.3?
> > >
> > > -igor
> > >
> > >
> > > On 2/15/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > >
> > > > I agree with it now too. A typical thing you want to do in a button
> is
> > > > do a component replacement (at least, that's what we do often here)
> of
> > > > a component above the form. The problem with buttons being called
> > > > before the form's onSubmit is that then the component is already
> > > > detached from the page.
> > > >
> > > > Eelco
> > > >
> > > >
> > > > On 2/15/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > > i am going to resurrect this discussion again since we now have
> more
> > > > > committers and none of you old ones have agreed with me before! i
> still
> > > > > think this
> > > > > is a good idea!
> > > > >
> > > > > the old thread can be seen here:
> > > > >
> > > > >
> > > >
> http://www.nabble.com/form.onsubmit-vs-button.onsubmit-tf1977859.html#a5431105
> > > > >
> > > > > -igor
> > > > >
> > > > >
> > > > > ---------- Forwarded message ----------
> > > > > From: Igor Vaynberg <ig...@gmail.com>
> > > > > Date: Jul 20, 2006 3:55 PM
> > > > > Subject: form.onsubmit vs button.onsubmit
> > > > > To: wicket-develop@lists.sourceforge.net
> > > > >
> > > > > i just noticed that we call button.onsubmit() /before/
> form.onsubmit(),
> > > > i
> > > > > always believed this to be the other way around because that is
> more
> > > > > intuitive - cascading onsubmit down the component hierarchy. is
> there a
> > > > > reason why we do it "backwards"?
> > > > >
> > > > > i have also noticed a pattern where i group certain fields in a
> panel
> > > > and
> > > > > would like to let the panel also have an onsubmit() for
> processing. i
> > > > was
> > > > > thinking of implementing IFormSubmitAware { void onSubmit(); } and
> > > > bubble
> > > > > this down via a visitor in form.delegatesubmit() but of course
> with the
> > > > > button getting called first it makes no sense.
> > > > >
> > > > > shall we reverse it in 2.0? should i put the iformsubmitaware into
> 2.0core?
> > > > >
> > > > > -Igor
> > > > >
> > > >
> > >
> >
> >
> > --
> > Learn Wicket at ApacheCon Europe: http://apachecon.com
> > Join the wicket community at irc.freenode.net: ##wicket
> > Wicket 1.2.5 will keep your server alive. Download Wicket now!
> > http://wicketframework.org
> >
>
>
> --
> Download Wicket 1.2.5 now! - http://wicketframework.org
>
Re: form.onsubmit vs button.onsubmit
Posted by Gwyn Evans <gw...@gmail.com>.
Adding a setting:+0 Reversing the present order:-1
/Gwyn
On 25/03/07, Martijn Dashorst <ma...@gmail.com> wrote:
> For me the argument still remains: you break a lot of stuff in a
> silent way. Why can't this be a setting on the form?
>
> The things you describe are at least very specific to one method of
> development, given that we can build web applications using the
> current method of development for over 2 years.
>
> Making it a setting with the default being the current way of
> processing sounds much safer than inverting it because of a method of
> development that is in swing now.
>
> Martijn
>
> On 3/25/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > so should we change this in 1.3?
> >
> > -igor
> >
> >
> > On 2/15/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > I agree with it now too. A typical thing you want to do in a button is
> > > do a component replacement (at least, that's what we do often here) of
> > > a component above the form. The problem with buttons being called
> > > before the form's onSubmit is that then the component is already
> > > detached from the page.
> > >
> > > Eelco
> > >
> > >
> > > On 2/15/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > i am going to resurrect this discussion again since we now have more
> > > > committers and none of you old ones have agreed with me before! i still
> > > > think this
> > > > is a good idea!
> > > >
> > > > the old thread can be seen here:
> > > >
> > > >
> > > http://www.nabble.com/form.onsubmit-vs-button.onsubmit-tf1977859.html#a5431105
> > > >
> > > > -igor
> > > >
> > > >
> > > > ---------- Forwarded message ----------
> > > > From: Igor Vaynberg <ig...@gmail.com>
> > > > Date: Jul 20, 2006 3:55 PM
> > > > Subject: form.onsubmit vs button.onsubmit
> > > > To: wicket-develop@lists.sourceforge.net
> > > >
> > > > i just noticed that we call button.onsubmit() /before/ form.onsubmit(),
> > > i
> > > > always believed this to be the other way around because that is more
> > > > intuitive - cascading onsubmit down the component hierarchy. is there a
> > > > reason why we do it "backwards"?
> > > >
> > > > i have also noticed a pattern where i group certain fields in a panel
> > > and
> > > > would like to let the panel also have an onsubmit() for processing. i
> > > was
> > > > thinking of implementing IFormSubmitAware { void onSubmit(); } and
> > > bubble
> > > > this down via a visitor in form.delegatesubmit() but of course with the
> > > > button getting called first it makes no sense.
> > > >
> > > > shall we reverse it in 2.0? should i put the iformsubmitaware into 2.0core?
> > > >
> > > > -Igor
> > > >
> > >
> >
>
>
> --
> Learn Wicket at ApacheCon Europe: http://apachecon.com
> Join the wicket community at irc.freenode.net: ##wicket
> Wicket 1.2.5 will keep your server alive. Download Wicket now!
> http://wicketframework.org
>
--
Download Wicket 1.2.5 now! - http://wicketframework.org
Re: form.onsubmit vs button.onsubmit
Posted by Igor Vaynberg <ig...@gmail.com>.
On 3/25/07, Martijn Dashorst <ma...@gmail.com> wrote:
>
> For me the argument still remains: you break a lot of stuff in a
> silent way. Why can't this be a setting on the form?
heh, you were pro for the attach/detach refactor and that broke a ton of
things very very silently
The things you describe are at least very specific to one method of
> development, given that we can build web applications using the
> current method of development for over 2 years.
you can build web applications using struts too :) changing the order adds a
lot of flexibility, the only con is that it breaks things.
Making it a setting with the default being the current way of
> processing sounds much safer than inverting it because of a method of
> development that is in swing now.
a setting wont fix anything, it needs to be a constant part of the workflow
otherwise you cannot make assumptions.
-igor
Martijn
>
> On 3/25/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > so should we change this in 1.3?
> >
> > -igor
> >
> >
> > On 2/15/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > I agree with it now too. A typical thing you want to do in a button is
> > > do a component replacement (at least, that's what we do often here) of
> > > a component above the form. The problem with buttons being called
> > > before the form's onSubmit is that then the component is already
> > > detached from the page.
> > >
> > > Eelco
> > >
> > >
> > > On 2/15/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > i am going to resurrect this discussion again since we now have more
> > > > committers and none of you old ones have agreed with me before! i
> still
> > > > think this
> > > > is a good idea!
> > > >
> > > > the old thread can be seen here:
> > > >
> > > >
> > >
> http://www.nabble.com/form.onsubmit-vs-button.onsubmit-tf1977859.html#a5431105
> > > >
> > > > -igor
> > > >
> > > >
> > > > ---------- Forwarded message ----------
> > > > From: Igor Vaynberg <ig...@gmail.com>
> > > > Date: Jul 20, 2006 3:55 PM
> > > > Subject: form.onsubmit vs button.onsubmit
> > > > To: wicket-develop@lists.sourceforge.net
> > > >
> > > > i just noticed that we call button.onsubmit() /before/ form.onsubmit
> (),
> > > i
> > > > always believed this to be the other way around because that is more
> > > > intuitive - cascading onsubmit down the component hierarchy. is
> there a
> > > > reason why we do it "backwards"?
> > > >
> > > > i have also noticed a pattern where i group certain fields in a
> panel
> > > and
> > > > would like to let the panel also have an onsubmit() for
> processing. i
> > > was
> > > > thinking of implementing IFormSubmitAware { void onSubmit(); } and
> > > bubble
> > > > this down via a visitor in form.delegatesubmit() but of course with
> the
> > > > button getting called first it makes no sense.
> > > >
> > > > shall we reverse it in 2.0? should i put the iformsubmitaware into
> 2.0core?
> > > >
> > > > -Igor
> > > >
> > >
> >
>
>
> --
> Learn Wicket at ApacheCon Europe: http://apachecon.com
> Join the wicket community at irc.freenode.net: ##wicket
> Wicket 1.2.5 will keep your server alive. Download Wicket now!
> http://wicketframework.org
>
Re: form.onsubmit vs button.onsubmit
Posted by Martijn Dashorst <ma...@gmail.com>.
For me the argument still remains: you break a lot of stuff in a
silent way. Why can't this be a setting on the form?
The things you describe are at least very specific to one method of
development, given that we can build web applications using the
current method of development for over 2 years.
Making it a setting with the default being the current way of
processing sounds much safer than inverting it because of a method of
development that is in swing now.
Martijn
On 3/25/07, Igor Vaynberg <ig...@gmail.com> wrote:
> so should we change this in 1.3?
>
> -igor
>
>
> On 2/15/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > I agree with it now too. A typical thing you want to do in a button is
> > do a component replacement (at least, that's what we do often here) of
> > a component above the form. The problem with buttons being called
> > before the form's onSubmit is that then the component is already
> > detached from the page.
> >
> > Eelco
> >
> >
> > On 2/15/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > i am going to resurrect this discussion again since we now have more
> > > committers and none of you old ones have agreed with me before! i still
> > > think this
> > > is a good idea!
> > >
> > > the old thread can be seen here:
> > >
> > >
> > http://www.nabble.com/form.onsubmit-vs-button.onsubmit-tf1977859.html#a5431105
> > >
> > > -igor
> > >
> > >
> > > ---------- Forwarded message ----------
> > > From: Igor Vaynberg <ig...@gmail.com>
> > > Date: Jul 20, 2006 3:55 PM
> > > Subject: form.onsubmit vs button.onsubmit
> > > To: wicket-develop@lists.sourceforge.net
> > >
> > > i just noticed that we call button.onsubmit() /before/ form.onsubmit(),
> > i
> > > always believed this to be the other way around because that is more
> > > intuitive - cascading onsubmit down the component hierarchy. is there a
> > > reason why we do it "backwards"?
> > >
> > > i have also noticed a pattern where i group certain fields in a panel
> > and
> > > would like to let the panel also have an onsubmit() for processing. i
> > was
> > > thinking of implementing IFormSubmitAware { void onSubmit(); } and
> > bubble
> > > this down via a visitor in form.delegatesubmit() but of course with the
> > > button getting called first it makes no sense.
> > >
> > > shall we reverse it in 2.0? should i put the iformsubmitaware into 2.0core?
> > >
> > > -Igor
> > >
> >
>
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org