Just to wrap up, the StatefulSession suggestion, coupled with the usage of RequestVars in a few place to preserve data across links and calls to S.redirectTo s did the trick for us.
Session variables are really no different in Lift than in any other web framework. They are appropriate for data that is either read-only or generally not volatile, and tends to have the lifespan as the session itself . A "current user" object is the classic use case IMO. Our (admittedly self-inflicted) problem was that we we using a SessionVar to manage a highly transient UI state, basically forcing a tool that is suited for read-mostly data storage into managing what was effectively a multi-writer situation (different versions of pages via the back button, independent browser tabs, etc.), with predictable results. Chalk it up to inexperience on our part. Many aspects of Lift's stateful design are very different from other frameworks; this one is not! Sean On Feb 25, 3:04 pm, tiro <tim.romb...@googlemail.com> wrote: > because I haven't yet encountered a use case where they correspond to > expected behaviour if the user happens to know how to work with a > tabbed browser. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
