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 [email protected]:
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-tp4813595.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
