Application level state
Locked
 
|
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? Cheers, Bernhard _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Application level state
|
|
On Wed, Jul 19, 2017 at 6:39 PM, Bernhard Pieber <[hidden email]> 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 [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
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 <[hidden email]>: > > On Wed, Jul 19, 2017 at 6:39 PM, Bernhard Pieber <[hidden email]> 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 > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Application level state
|
|
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 <[hidden email]>: > 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 <[hidden email]>: >> >> On Wed, Jul 19, 2017 at 6:39 PM, Bernhard Pieber <[hidden email]> 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 >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
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 <[hidden email]>: > > 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 <[hidden email]>: >> 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 <[hidden email]>: >>> >>> On Wed, Jul 19, 2017 at 6:39 PM, Bernhard Pieber <[hidden email]> 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 >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Application level state
|
|
2017-07-20 15:41 GMT-03:00 Bernhard Pieber <[hidden email]>:
> 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. Then you should use a regular Seaside Session for that and have your own "application" class whose instances will be referenced by each separate session in a 1:1 relationship (each session will have it's own application instance). You could achieve something similar using WARequestFilters, but I find it convoluted when you can simply create your own WASession subclass. Esteban A. Maringolo _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
I forgot to explicitly describe one key requirement: each application should be able to have multiple sessions.
I thought about request filters. However, as they are on session level, I don’t know which application to assign when the session is created. The only time I can think of assigning the application is during registering. Something like: registerApps | app1 app 2 | app1 := WAAdmin registerAsApplication: BpRootComponent at: ‚/app1'. app1 applicationModel: BpApplicationModel new. app2 := WAAdmin registerAsApplication: BpRootComponent at: ‚/app2'. app2 applicationModel: BpApplicationModel new. Cheers, Bernhard > Am 20.07.2017 um 20:45 schrieb Esteban A. Maringolo <[hidden email]>: > > 2017-07-20 15:41 GMT-03:00 Bernhard Pieber <[hidden email]>: >> 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. > > Then you should use a regular Seaside Session for that and have your > own "application" class whose instances will be referenced by each > separate session in a 1:1 relationship (each session will have it's > own application instance). > > You could achieve something similar using WARequestFilters, but I find > it convoluted when you can simply create your own WASession subclass. > > Esteban A. Maringolo > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Application level state
|
|
2017-07-20 15:57 GMT-03:00 Bernhard Pieber <[hidden email]>:
> I forgot to explicitly describe one key requirement: each application should be able to have multiple sessions. > > I thought about request filters. However, as they are on session level, I don’t know which application to assign when the session is created. The only time I can think of assigning the application is during registering. Something like: > > registerApps > | app1 app 2 | > app1 := WAAdmin registerAsApplication: BpRootComponent at: ‚/app1'. > app1 applicationModel: BpApplicationModel new. > app2 := WAAdmin registerAsApplication: BpRootComponent at: ‚/app2'. > app2 applicationModel: BpApplicationModel new. It confuses me because I can't see the use case of that. Your app1 will have app1session1 to app1sessionN, and they will all share the same app1 applicationModel. And The same for app2 sessions. You could use the WAUserConfiguration for that, I only had to dealt with its implementation when doing some GLORP related stuff. The whole Configuration features of Seaside seems to be very powerful, but quite intrincated to me, so I avoid getting into it. See WAUserConfiguration and WASharedConfiguration, I think this might lead you to the behavior you want to achieve. Regards, Esteban A. Maringolo _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Application level state
|
|
In reply to this post by bpi
On Thu, Jul 20, 2017 at 7:50 PM, Bernhard Pieber <[hidden email]> wrote:
> 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 You could try to using the seaside configurations for this. A list attribute with an options block that returns all applications models may do it. As an example have a look at WAExceptionFilterConfiguration. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Application level state
|
|
In reply to this post by bpi
On Thu, Jul 20, 2017 at 8:57 PM, Bernhard Pieber <[hidden email]> wrote:
> I forgot to explicitly describe one key requirement: each application should be able to have multiple sessions. I don't quite understand what you mean by this, can you elaborate a bit? Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |