Re: StaleLink

Folks,

I suggest extreme caution if you are thinking about changing Tapestry to 
have more WOF-like request-response loop processing simply to solve this 
narrow problem. I have used WOF since it was first released and I understand 
the WOF cycle pretty well. One of the greatest virtues of Tapestry w/ 
regards to WOF is that the r-r cycle processing is conceptually much 
simpler, operationally much simpler, and seems to have fewer side effects. 
Most of my time in WOF was spent *de-engineering* stuff, i.e. trying to get 
WOF out of the way, and much of that was related to the request-response 
cycle processing.

We should think really hard about how to solve this problem with the 
existing processing approach before resorting to copying WOFs idiom.

Joseph Panico
[email protected]




>From: "Howard M. Lewis Ship" <[email protected]>
>To: "Craig Miskell" <[email protected]>
>CC: <[email protected]>
>Subject: Re: [Tapestry-developer] StaleLink
>Date: Thu, 5 Dec 2002 07:31:01 -0500
>
>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


_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
http://join.msn.com/?page=features/virus



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf