Howard Lewis Ship wrote: > Yes, and persistent properties on the client help ensure that the > appllication state stays associated with the request not the session. > That's definitely a cool thing that I'd like to have backported in Tapestry 3.0 (or at least a major reason to upgrade ;-) ).
We've build apps that only have "one" page containing tabs inside with dozends of components to let it virtually look like a GUI app. We just adjust the components & rerender the page instead of switching between pages. That means we rely heavily on form submission and having the correct state. The browser back button is really a bad thing in such a scenario. Components like ListEdit or FormConditionals are IHMO just a partial workaround. But client-side state could solve this once and forever. BTW: Is the client side state encoded or encrypted somehow in Tapestry 4.0? I wouldn't like users to be able to mess around too easily in that state. As long as you could only do this with normal form fields or hidden fields one could mess around using plain form parameters or the html page itself, but if "all" state is client-side one should try to crypt things or people could basically stick anything in our apps. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
