You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Jamie Orchard-Hays <ja...@dang.com> on 2004/05/19 15:28:14 UTC
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
Re: form listeners
Posted by Jamie Orchard-Hays <ja...@dang.com>.
I would want them to work like other listeners in that they would be called
before the form listener.
Jamie
----- Original Message -----
From: "Richard Lewis-Shell" <rl...@mac.com>
To: "Tapestry development" <ta...@jakarta.apache.org>
Sent: Wednesday, May 19, 2004 6:00 PM
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Easiest way to share templates between pages
Posted by Paul Ferraro <pm...@columbia.edu>.
Create a component. Check out the Border component in the workbench
example application from the Tapestry source distribution.
Paul
Jeremy Mayes wrote:
> Hi All,
> I'm interested in using a single html template across multiple
> pages, i.e., I'll have multiple page java classes in order to
> specialize the functionality but the general page layout will stay the
> same. Is there anyway to do this?
>
> Thanks,
> Jeremy
>
> This message contains confidential information and is intended only
> for the individual named. If you are not the named addressee you
> should not disseminate, distribute or copy this e-mail. Please
> notify the sender immediately by e-mail if you have received this
> e-mail by mistake and delete this e-mail from your system and destroy
> any copies thereof.
>
> E-mail transmission cannot be guaranteed to be secure or error-free
> as information could be intercepted, corrupted, lost, destroyed,
> arrive late or incomplete, or contain viruses. The sender therefore
> does not accept liability for any errors or omissions in the contents
> of this message which arise as a result of e-mail transmission. If
> verification is required please request a hard-copy version. This
> message is provided for informational purposes and should not be
> construed as a solicitation or offer to buy or sell any securities or
> related financial instruments.
>
>
>
> ---------------------------------------------------------------------
> 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
Easiest way to share templates between pages
Posted by Jeremy Mayes <je...@ubs.com>.
Hi All,
I'm interested in using a single html template across multiple pages,
i.e., I'll have multiple page java classes in order to specialize the
functionality but the general page layout will stay the same. Is there
anyway to do this?
Thanks,
Jeremy
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system and destroy
any copies thereof.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: form listeners
Posted by Jamie Orchard-Hays <ja...@dang.com>.
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" <mi...@yahoo.com>
To: "Tapestry development" <ta...@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" <rl...@mac.com>
> To: "Tapestry development" <ta...@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" <mi...@yahoo.com>
> > To: "Tapestry development" <ta...@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" <ja...@dang.com>
> > > To: "Tapestry development" <ta...@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
Re: form listeners
Posted by Mindbridge <mi...@yahoo.com>.
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" <rl...@mac.com>
To: "Tapestry development" <ta...@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" <mi...@yahoo.com>
> To: "Tapestry development" <ta...@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" <ja...@dang.com>
> > To: "Tapestry development" <ta...@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
Re: form listeners
Posted by Richard Lewis-Shell <rl...@mac.com>.
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" <mi...@yahoo.com>
To: "Tapestry development" <ta...@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" <ja...@dang.com>
> To: "Tapestry development" <ta...@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
Re: form listeners
Posted by Mindbridge <mi...@yahoo.com>.
> 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" <ja...@dang.com>
To: "Tapestry development" <ta...@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