Organizing Session Vars in Scala/Lift
Asked Answered
C

2

7

Would like to get some thoughts on how to best organize session vars within a scala / lift application.

I've read over a number of scala materials online and have found generally the following paradigm in all examples that introduce session vars:

  1. declare an object that extends the SessionVar class
  2. put that object into a file that contains a snippet (or any file)
  3. access that object from anywhere in the codebase (lift will take care of the session var's lifecycle based on the lifetime of the user's http session)

Perhaps I'm not understanding something, but I'm concerned that this approach would lead to a whole bunch of these objects in various files all over the place. Its not such a big deal if its a small app, but when a project gets larger this could lead to chaos.

For those who have worked on larger scala projects, is there a generally accepted better approach? (even if its something simple like putting all of these objects into a common file?)

Thanks.

Contracted answered 17/6, 2011 at 5:33 Comment(1)
...and there are reasons not everyone likes LiftWeb :pVitelline
S
5

This is a bit subjective, but I'll give it a try. I think it depends on the scope the session var has in your project.

  • If you need the session var only in one snippet, you should make it a private member of that class.
  • If you need it in several but not all snippets, put those snippets in a package and make the object private to that package. If you have a lot of them, you could create an extra file to hold them.
  • If you need it globally, put it into a central location, maybe inside a package object.
  • If possible, avoid using SessionVars completely.
Symer answered 17/6, 2011 at 8:2 Comment(0)
I
4

SessionVars should be used sparingly in your application. They are similar to Servlet Session Variables, except they are type safe.

How many session variables do you need? Personally, I have a session variable for the primary key of the current user and maybe one or two more. The rest of the state of the application should be stored in closures (because functions associated with GUIDs close over scope).

Incantatory answered 28/6, 2011 at 23:58 Comment(2)
Okay. I understand that functions can close over vars declared outside of the function's definition, but I'm unclear how one can associate a function with a GUID. Can you point me to a concrete example on how to achieve this? Perhaps I'm missing something. Thanks again!Contracted
I would also appreciate a little bit more detail (URL to text or to a working source file would suffice). I have similar doubts and can't find a good resource (within Assembla, Exploring Lift book or even the mailing list) that can enlighten me a little. Thanks in advance.Bootjack

© 2022 - 2024 — McMap. All rights reserved.