Patrick Casey <patcasey <at> adelphia.net> writes: > Wouldn't Howard's proposed approach of serializing and compressing > all relevant page data in the outbound stream and then echoing it back in > the POST still let you do things like loops, but without having to muck > around with the rewind cycle? I don't see why his approach would prevent you > doing what you want to do, while it would definitely save a great deal of > the headache associated with the rewind cycle. It is, after all, the way > .net has been doing it for 3 or so years and it seems to work for them. > > --- pat
.NET doesn't base it's existence on bi-directional model-to-component binding. Such binding can be done, but the last time I looked it seemed rather difficult and somewhat non-standard. JSF (which saves page state either to hidden form fields or to the session) does do bi-directional binding, but it is much more limited than Tapestry in what you can and cannot bind a component's property to. It should be possible to make a "saved-state" approach work, but it might be difficult. It would be especially difficult to track the temporary page variables (like loop variables) so that the appropriate instance of a model object is bound to the correct component when the view is restored during form processing. Maybe this is already part of the design. If so, that's great! Another thing to consider is that, even with a "saved-state" approach, you'd still run into SOME of the same problems as with the current "rewind cycle." The main problem (as I see it) with the current rewind is that you can get a mismatch of the submitted values (which came from the original page render) and the in-memory components (which came from the re-render). With a "saved-state" approach, you instead get a mismatch of the components and the model (i.e. a component is bound to a model object that no longer exists or has been modified is some way that prevents the binding from working). To some extent, it might be just brushing the dirt under a different rug. You still get a mismatch of some sort and must find a way to deal with it. Again, I'm not saying we must keep the rewind... I'm just saying that it has some nice features (when used carefully) that we should make sure we preserve. -Nathan > > -----Original Message----- > > From: news [mailto:news <at> sea.gmane.org] On Behalf Of Nathan Kopp > > Sent: Monday, January 09, 2006 8:39 PM > > To: tapestry-user <at> jakarta.apache.org > > Subject: Why I like the rewind cycle > > > > I've written a blog post on why I like Tapestry's poorly-named-yet-very- > > useful > > "rewind cycle." Before we get out the torches and pitchforks and > > eradicate all > > memories of the dreaded rewind cycle from Tapestry's code, let's have a > > look at > > what it has to offer and maybe think about why it was created in the first > > place. That way we won't lose functionality when the replacement is > > designed and built. > > > > Here's the blog post: > > http://nate-tech.blogspot.com/2006/01/why-tapestrys-crazy-rewind-is- > > good.html > > > > To summarize (for those who's time is limited), I like how the rewind > > cycle > > replays the page render for processing, because (among other things) it > > allows > > components to be bound directly to loop variables, so I don't need to > > track a > > loop index for my bindings. No other framework that I know of can do this > > in > > such an elegant way as Tapestry. > > > > BTW, I have really enjoyed working with Tapestry, especially Tap 4. This > > is > > great stuff! > > > > -Nathan Kopp > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: tapestry-user-unsubscribe <at> jakarta.apache.org > > For additional commands, e-mail: tapestry-user-help <at> jakarta.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: tapestry-user-unsubscribe <at> jakarta.apache.org > For additional commands, e-mail: tapestry-user-help <at> jakarta.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
