Hi, I worked on a monster of an e-commerce package called Blue Martini. Their consultants also liked to build the system where all the data was put in hidden page fields and not use the session. This burdens the network with sending data that is not required on the client and you cannot use get method because of practical limitations on request lengths. But then again you preserve server memory and retain some more server scalability. I can't recall how things were with using back buttons, of course when stat eis in the page you effectively get back to the previous state which is good, but I think there may of been other issues? I think memory is more scalable reliable and secure vs network resourcing, there is big memory. It seems to be about finding the right balance and I think technical developments and limitations favour server memory.
Having said that ,I tend to just keep the bare minimum in session such as the users ID and permissions. I am using Tapestry FLASH property persistence where possible, this seems to be a good compromise. I'm interested to hear more about approaches on this topic. ----- Original Message ----- From: Lance Java To: Tapestry users Sent: Wednesday, November 06, 2013 8:37 PM Subject: Re: T5.3: per page context session storage? Any time someone wants to use the session, I always ask why. I avoid session usage wherever possible. If there's no real need for it, I suggest you keep your app stateless and use the page activation context / event context to pass parameters.
