Actually, don't do that. The Form listener property will be connected to
the listener parameter ... and the parameter will recognize the listener as
invariant, so it only updates the listener property ONCE.
Instead, have the Submit update a property of the page, ie:
private IActionListener _submitListener;
public void get/setSubmitListener() ...
public void formSubmit(IRequestCycle cycle)
{
if (_submitListener != null) _submitListener.actionTriggered(....)
...
}
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: "Tapestry Developer" <[EMAIL PROTECTED]>;
"Richard Lewis-Shell" <[EMAIL PROTECTED]>
Sent: Friday, December 06, 2002 5:16 PM
Subject: Re: [Tapestry-developer] StaleLink
> Perhaps an improvement would be fore Submit listeners to be deferred,
executed
> just before the form's listener is executed. That could be arraigned as
well.
>
>
> You can kind of fudge this now, by specifying the listener as the tag, and
> binding the form's listener property to the selected parameter of the
Submit.
>
> This will, in effect, overwrite the listener for the Form with the
listener of
> the selected Submit. Well, I haven't tried that in practice, but it
*should*
> work.
>
> --
> [EMAIL PROTECTED]
>
> http://tapestry.sf.net
> > Yes, WOF handles nested lists/conditionals and, from memory, without
putting
> > render state in the page. As I remember it (and it was over 3 years ago
> > when I used WOF last), WOF generally has 3 cycles (takeValues,
invokeAction,
> > appendToResponse), compared with Tapestry's 2: rewind/render. In WOF
the
> > first two cycles both rewind - the first one to take (form) values from
the
> > request. The second to invoke whatever action triggered the request.
The
> > third cycle is essentailly the render cycle. I have often wished
Tapestry
> > had the extra cycle, as it seemed a simpler/more logical to separate
these
> > phases of the request cycle (but that is not surprising given a WOF
> > background). There are no doubt some negative performance implications
here
> > too with an extra rewind cycle.
> >
> > BTW, in the early days of Tapestry there was no listener parameter for a
> > Submit component - just the selected/tag parameters, and the Form
listener.
> > So in order to implement a submit listener one had to set the 'tag' for
the
> > submit to a listener, set the 'selected' to some property that the Form
> > could access, and then invoke the listener from the form submit
listener.
> > Seemed a pain at the time - but we still do this, and almost never have
to
> > even think about StaleLinkExceptions (ActionLink's being the frustrating
> > exception from memory). This was also in the days before the
'listeners'
> > magic that meant you had to create your own (usually anonymous) listener
> > class/object - which also meant that you could more easily record
> > important/relevant rewind state at the time the getter for the listener
was
> > called. In the form listener case, this much later in the rewind - ie.
> > after your Foreach's have finished iterating so you don't have access to
the
> > the Foreach value during your action (well, you typically do, but it's
the
> > value of the last object in the Foreach source, which leads to really
weird
> > behaviour!).
> >
> > Sometimes these wizzy new features actually make things more
complex/murky
> > when they are intended to simplify...
> >
> > Richard
> >
> > ----- Original Message -----
> > From: "Howard M. Lewis Ship" <[EMAIL PROTECTED]>
> > To: "Craig Miskell" <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Friday, December 06, 2002 1:31 AM
> > Subject: Re: [Tapestry-developer] StaleLink
> >
> >
> > > It's possible the WOF approach is better. Can WOF support loops and
> > > conditionals inside forms?
> > >
> > > Can you describe in greater detail what WOF does in its phases?
Perhaps
> > we
> > > can adapt some ideas to Tapestry.
> > >
> > > When I say that Tapestry is inspired by WOF, it's very literally true.
I
> > > didn't have vast amounts of knowledge of WOF beyond skimming the
manuals
> > and
> > > doing a couple of simple demos. I just became facinated with the
concept
> > > and started a mental game to figure out how you would accomplish
something
> > > like it ... that grew into Tapestry. I think Tapestry has been aided
by
> > the
> > > fact that I didn't try to copy WOF class-for-class and
method-for-method
> > > (there is at least one failed open-source project to do just that).
> > >
> > > ----- Original Message -----
> > > From: "Craig Miskell" <[EMAIL PROTECTED]>
> > > To: "Ivanhoe Abrahams" <[EMAIL PROTECTED]>
> > > Cc: <[EMAIL PROTECTED]>
> > > Sent: Friday, December 06, 2002 4:10 AM
> > > Subject: Re: [Tapestry-developer] StaleLink
> > >
> > >
> > > > Yeah, this can be a tricky one to get around. The short story is
that
> > > > whatever changes you make in the listener for a submit button cannot
> > > > change how the rest of the form renders (in terms of number of
> > > > components). In practice, this means it shouldn't modify *anything*
> > that
> > > > changes how the form renders (even stuff earlier in the page, just
in
> > case
> > > > things are rearranged later).
> > > >
> > > > In our situation, the trivial way we could see to do it was to set
> > > > flags in the submit button listeners (might be interesting in your
> > case),
> > > and
> > > > only perform the actual processing which modifies
conditionals/number of
> > > > elements etc. in the FORM listener (by which stage the form has
rendered
> > > > and the number of components checked to ensure that no
> > StaleLinkException
> > > > is thrown).
> > > >
> > > > The actual mechanics of what to set/record in the submit button
> > listeners
> > > > will vary depending on the page and what the submit buttons should
do.
> > > > And there may very well be a better solution, because this approach
> > could
> > > > easily degenerate into having trivial submit button listeners, and a
big
> > > > horrible if/elseif/else structure in the form listener. Typically
that
> > > > should raise alarm bells in a OO design. If it gets ugly, perhaps
some
> > > > sort of use of the Command pattern (I think that's the one...).
Command
> > > > objects implement logic, each submit button listener creates a
Command
> > and
> > > > stores it for execution during the form action listener... that's a
bit
> > > > nicer, but more heavyweight in terms of the number of classes etc.,
> > > > However, I suppose the argument could be made that if the submit
> > listener
> > > > is doing enough to modify enough of the page to make a difference to
the
> > > > form rendering, then the might need encapsulating outside the page
class
> > > > anyway. YMMV.
> > > >
> > > > I'm personally a little iffy on whether this is a good feature of
> > > > Tapestry.. only having 2 phases to the Request/Response loop (rewind
and
> > > > render) pretty much forces this situation, unlike the 3 phases in
> > > > WebObjects (takeValues, invokeAction, appendToResponse) which
handles it
> > > > better. However, changing this at version 2.2+ is probably a little
> > late.
> > > > And I'm sure Howard has good reasons for the route he's chosen
to-date
> > > > (and I'd love to hear them???? Hint??? ;-))
> > > >
> > > > Whoops, this turned into a mini-essay. Sorry 'bout that,
> > > >
> > > > Craig
> > > >
> > > >
> > > > On Fri, 6 Dec 2002, Ivanhoe Abrahams wrote:
> > > >
> > > > > Hello everyone
> > > > >
> > > > > I am seeking some help on the StaleLink exception I keep getting
> > > > >
> > > > > My situation:
> > > > > I have at the top of my page a PropertySelection(which auto
submits on
> > > > > change) which holds a list of Products (names).
> > > > > Each product can be configured differently, allowing for different
> > input
> > > > > mechanisms per product.
> > > > >
> > > > > So now as I change from product to product some components are
> > rendered
> > > or
> > > > > not based on conditional variables
> > > > > which means that the one product has maybe four elements on the
screen
> > > while
> > > > > the next has maybe six.(I think you guys get
> > > > > the picture)
> > > > >
> > > > > Now I understand Tapestry's need to make sure that when rewinding
> > there
> > > must
> > > > > be exactly the same amount of
> > > > > components on the page than when it rendered. But in my situation
The
> > > > > PropertySelection fires off a submit AFTER which I only set the
> > > conditional
> > > > > variables to show the different parts or hide different
components. It
> > > is
> > > > > this part which I dont understand or would appreciate some
> > > guidance/hints as
> > > > > to how to fix this.
> > > > >
> > > > > Any help will be highly appreciated.
> > > > > PS. When I turn off Template cache as explained in the FAQ all my
> > submit
> > > > > buttons(eg. save/new with listener methods) on this particular
form
> > > generate
> > > > > Stale Links (I havent tried this with a simple page yet).
> > > > >
> > > > > For what its worth I think Tapestry's got a good future going for
it.
> > > > >
> > > > > Thank you
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ---
> > > > > Outgoing mail is certified Virus Free.
> > > > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > > > Version: 6.0.423 / Virus Database: 238 - Release Date: 2002/11/25
> > > > >
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This sf.net email is sponsored by:ThinkGeek
> > > > > Welcome to geek heaven.
> > > > > http://thinkgeek.com/sf
> > > > > _______________________________________________
> > > > > Tapestry-developer mailing list
> > > > > [EMAIL PROTECTED]
> > > > > https://lists.sourceforge.net/lists/listinfo/tapestry-developer
> > > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This sf.net email is sponsored by:ThinkGeek
> > > > Welcome to geek heaven.
> > > > http://thinkgeek.com/sf
> > > > _______________________________________________
> > > > Tapestry-developer mailing list
> > > > [EMAIL PROTECTED]
> > > > https://lists.sourceforge.net/lists/listinfo/tapestry-developer
> > > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Tapestry-developer mailing list
> > > [EMAIL PROTECTED]
> > > https://lists.sourceforge.net/lists/listinfo/tapestry-developer
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Tapestry-developer mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/tapestry-developer
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Tapestry-developer mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/tapestry-developer
>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer
