Giving this another thought, you may want to think about dividing between user-specific and "global" state in general. This is not so important if you don't want to persist the data, but if you do, you can store user-specific data seperately. So this is not only helpful when multiple users can use the application in parallel (web apps), but also if people use it one after the other. So make it two objects: one associated to the app, one for each user. In some cases, there may not be "global" state, everything is probably user-specific Then we're back to your initial idea ;-) Joachim Am 20.03.15 um 14:58 schrieb jtuchel@objektfabrik.de:
Sanjay,
I am not a big fan of Dictionaries for these kinds of things, but if you need "named slots" for a previously unknown list of settings, the approach you describe is perfectly okay, IMO. This approach can also be extended into a database or any other kind of storage and also stands the test of web apps, in so far as you can distribute things between an application centric (global) and user-centric (session) objects.
Joachim
Am 20.03.15 um 14:14 schrieb Sanjay Minni:
Hi
What is the usual practices in storing values of variables / parameters the persist through an users usage of an application.
e.g. say the user logs in and then selects a current printer, current company, accounting year and then moves between various application options and eventually logs out. What is a good practice of storing the values
... one way could be to keep a separate application level object with a dictionary for all the variables ... would that be ok or there are other better ways
regards Sanjay
----- --- Regards, Sanjay -- View this message in context: http://forum.world.st/practices-in-storing-users-application-level-variables... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.