tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jamie Orchard-Hays" <ja...@dang.com>
Subject Re: form listeners
Date Thu, 20 May 2004 20:08:03 GMT
Mindbridge, I agree completely. I can't see a practical use for a delayed
form listener and the delayed listener should only ever be invoked once.

Jamie
----- Original Message ----- 
From: "Mindbridge" <mindbridgeweb@yahoo.com>
To: "Tapestry development" <tapestry-dev@jakarta.apache.org>
Sent: Thursday, May 20, 2004 3:50 PM
Subject: Re: form listeners


> Hi Richard and Jamie,
>
> > Does your "delayed
> > listener" proposal have the listener invoked before or after the form
> > listener?  Perhaps both would be needed, though that means two more
> > parameters to the submitting components.
>
> What I described invokes the delayed listeners before the form listener.
> Just to make sure this is clear, the sequence I was proposing was:
>
> - rewind + normal listeners
> - delayed listeners
> - form listener
>
>
> My last point was that a "delayed listener" could be added to the Form
> component as well, and the invocation sequence be changed to:
>
> - rewind + normal listeners
> - form listener
> - delayed listeners
> - delayed form listener
>
> This is a bit more flexible and covers pretty much every situaton, I
think,
> but I have to admit that I am hard pressed to find practical cases where
the
> original suggestion woudn't be sufficient. (Is there such a case?) Perhaps
> there is wisdom in doing something like the latter anyway...
>
>
> Just to note: if a component is in a loop, the normal listener of that
> component can be invoked N times. What the invocation refers to can be
> determined by the state of the component.
>
> If that component has a delayed listener, however, it only makes sense to
> invoke that listener only once, it seems, since the component state will
not
> be changing at this point and there will be no way to determine which
cycle
> of the loop the invocation refers to (I hope this makes sense). So a
delayed
> listener will need to be invoked only once, perhaps?
>
>
>
> ----- Original Message ----- 
> From: "Richard Lewis-Shell" <rlewisshell@mac.com>
> To: "Tapestry development" <tapestry-dev@jakarta.apache.org>
> Sent: Thursday, May 20, 2004 1:00 AM
> Subject: Re: form listeners
>
>
> > I am all for "delayed listeners" too.  In all the Tapestry projects I
have
> > been involved with (now 2!), it's just about the first thing
implemented.
> > In fact this was one of the first questions I asked about Tapestry 3 or
so
> > years ago, when Howard advised using tag/selected to pull it off, and I
am
> > still using it!  The downside to using this method is that each
submitting
> > component has to know where to store the delayed listener (the selected
> > parameter) - I have always used a property in a common Page superclass.
> So
> > it would be great if Tapestry would handle this.  Does your "delayed
> > listener" proposal have the listener invoked before or after the form
> > listener?  Perhaps both would be needed, though that means two more
> > parameters to the submitting components.
> >
> > R
> >
> > ----- Original Message ----- 
> > From: "Mindbridge" <mindbridgeweb@yahoo.com>
> > To: "Tapestry development" <tapestry-dev@jakarta.apache.org>
> > Sent: Wednesday, May 19, 2004 11:45 PM
> > Subject: Re: form listeners
> >
> >
> > > > Any disagreements?
> > >
> > > Yes, to the proposal in that form. Unfortunately, this is totally
> backward
> > > incompatible and will cause a hell of a lot of chaos if one were to
> > upgrade
> > > from 3.0 to 3.1.
> > >
> > > There have been a lot of discussions about this in the past -- search
> for
> > > "delayed listeners".
> > >
> > > The proposal that I personally favour at the moment is to add new,
> > > additional listener parameters (e.g. 'delayedListener') to all of the
> > > components that currently have a listener (they are quite a few).
Those
> > > delayed listeners would be invoked after the form goes through the
> rewind
> > > process, but before the form's listener is invoked. Basically the
> > invocation
> > > sequence becomes:
> > >
> > > - form rewind + normal listeners
> > > - delayed listeners
> > > - form listener
> > >
> > > This provides the needed behaviour and the old listeners are
preserved.
> > >
> > > (one other possibility is to have the form component also provide a
> > > delayedListener and adjust the invocation sequence appropriately, but
I
> > > pesonally do not see any reason to do that)
> > >
> > > Overall, however, there is a great need to have something like this
> > > implemented.
> > >
> > > -mb
> > >
> > >
> > > ----- Original Message ----- 
> > > From: "Jamie Orchard-Hays" <jamie@dang.com>
> > > To: "Tapestry development" <tapestry-dev@jakarta.apache.org>
> > > Sent: Wednesday, May 19, 2004 4:28 PM
> > > Subject: form listeners
> > >
> > >
> > > > I encountered unexpected behavior with form listeners yesterday
> (thanks
> > > > Howard for telling me how things work). I had some Hidden components
> > > listed
> > > > in my form *after* my LinkSubmit components. Since the listeners
were
> > > > rendered in rewind before the Hidden components, the Hidden values
> kept
> > > > coming up null. Listeners should be called at the end of the form
> > rewind,
> > > > just before the form listener. I propose to modify the processing to
> > work
> > > > this way. Any disagreements?
> > > >
> > > > Jamie
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
tapestry-dev-help@jakarta.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Mime
View raw message