Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Organizing Session Vars in Scala/Lift

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.

like image 299
jli_123 Avatar asked Jun 17 '11 05:06

jli_123


2 Answers

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.
like image 90
Kim Stebel Avatar answered Nov 15 '22 11:11

Kim Stebel


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).

like image 44
David Pollak Avatar answered Nov 15 '22 11:11

David Pollak