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
