Right - that would only work for POST since I believe the HTTP RFC limits GET requests to 2 or 4K. By experience, in JSF, pushing state this way to the webpage (base64 encoded and pk encrypted) has the benefits of request scope (no thread-safety issue, no multi-browser issue etc.) while maintaining benefits of session scope (resume a conversation, avoid hitting the database etc.). I am not so much concerned with scalability as much as I am with simplicity of not having to think about synchronization. Anyway, thanks for the feedback guys.
/Casper jwcarman wrote: > > He's not suggesting going stateless. He's suggesting an alternate way > of maintaining state (by pushing it to the client in hidden fields). > Tapestry supports (or supported) this as an option, but it made for > some pretty gnarly URLs (all the state had to be appended to the end) > for links. On forms, though, it wasn't that bad. The user never knew > it. To use this methodology effectively, I believe you have to go > into the "everything is a POST" land. Of course, I guess you could > get creative with redirect-after-post and using "flash" memory. > -- View this message in context: http://www.nabble.com/Noob-question%3A-Wicket-and-statefull-stateless-tp20578870p20582087.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
