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
[hidden email]:
> 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.
>>
>>
>
>
>
Locked
