Re: Application level state

Hi Esteban,

Thank you for your answer.

What I would like to achieve is to have two independent instances (completely independent data) of the same application (code) in the same image, accessible through different context paths. The applications share all the code but should not share any data, e.g. each instance would have their own users etc.

To make my own global registry is a definitely a way to achieve this. However, I wondered if there might be a better way using Seaside facilities.

Cheers,
Bernhard

> Am 20.07.2017 um 20:15 schrieb Esteban A. Maringolo <[email protected]>:
> 
> I'm not sure I understand what you want to achieve. If the application
> model is a globally accessible singleton, then the #applicationModel
> method you defined would be enough.
> 
> But if you want to share a single "application" among different
> Seaside applications then I think that is not possible, or at least
> not designed to be used in that way.
> 
> What I normally do is to have a "application/system" object per each
> user session,which is tied to a single Seaside Application, if you
> wanted to share that "system" between two different sessions, then
> you'll need a way to register them globally and lookup it when a new
> session is created for another seaside app.
> 
> Let's say you have two apps: /app1 and /app2
> When user Alice logs into app1, then you create an instance of
> YourApplication and assign it to app1 session and register it globally
> somewhere, when Alice logs into app2, you could lookup first if there
> already is a registered instance for her and use that one instead. It
> seems dirty and I don't know why you'd want to do that. But that's the
> first, albeit dirty, solution that comes to my mind.
> 
> Regards,
> 
> Esteban A. Maringolo
> 
> 
> 2017-07-20 14:50 GMT-03:00 Bernhard Pieber <[email protected]>:
>> Hi Philippe,
>> 
>> Thanks for the reply. It is the business model of the application. Now I have a class called BpApplicationModel with a class variable default. On my components I have the following method:
>> 
>> applicationModel
>>        ^BpApplicationModel default
>> 
>> I want to register the same application twice under different context paths using different BpApplicationModel instances. I could solve this with a dictionary singleton with the WAApplication as the key. However, it seems easier and cleaner if I could implement something like:
>> 
>> applicationModel
>>        ^self session application model
>> 
>> Cheers,
>> Bernhard
>> 
>> 
>>> Am 20.07.2017 um 13:13 schrieb Philippe Marschall <[email protected]>:
>>> 
>>> On Wed, Jul 19, 2017 at 6:39 PM, Bernhard Pieber <[email protected]> wrote:
>>>> Hi all!
>>>> 
>>>> I have subclassed WASession to add my own session specific state. I would like to do the same for WAApplication. However, I have read in the mailing list that WAApplication is not supposed to be subclassed.
>>>> 
>>>> I tried using preferenceAt:put: to set my root model object. However, I get WAAttribute not found. This feature seems to be for configuration purposes, mostly simple data types and classes.
>>>> 
>>>> So far I used the singleton pattern, a class variable in my root object model class. But now I would like to register the same component class twice using different context paths.
>>>> 
>>>> What is the most idiomatic way to achieve this in Seaside?
>>> 
>>> Can you go a bit into the details of the state? Is that more
>>> configuration is nature or more a business model?
>>> 
>>> Cheers
>>> Philippe
>>> _______________________________________________
>>> seaside mailing list
>>> [email protected]
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>> 
>> _______________________________________________
>> seaside mailing list
>> [email protected]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> seaside mailing list
> [email protected]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[email protected]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside