I think it strongly depends... Overuse of session when parameters will do is as wrong as trying to avoid session at all by making the rest complicated and unmaintainable.
If you need security / permission there is no decision you can make. For writing stateful wizard like dialogs it depends on complexity of your dialog(s). Concerning the initial question, maybe a dispatcher will do? You know the request and you can access the sessionstate. If session objects follow a page like naming scheme you can wipe objects you no longer need because the user went to a different page (hierarchy) for example. Jens Von meinem iPhone gesendet > Am 07.11.2013 um 12:44 schrieb "John" <j...@quivinco.com>: > > 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. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
