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
