Re: Making EOs aware of session properties (I know they should not but I need this anyway)
Re: Making EOs aware of session properties (I know they should not but I need this anyway)
- Subject: Re: Making EOs aware of session properties (I know they should not but I need this anyway)
- From: Markus Ruggiero <email@hidden>
- Date: Sun, 08 Nov 2015 13:45:52 +0100
- X_v_e_cd: 330e8c24d8b12c0bb7395745c0da4376
- X_v_r_cd: 035f2288e6ab56c1f85103b6b68d6d7b
Thanks Ken (and others who have responded),
> On 07.11.2015, at 16:38, Ken Anderson <email@hidden> wrote:
>
> Is currentUser not an EO? I’m guessing not, otherwise you wouldn’t have this problem :)
Yes, it is, but I fail to see why I should not have that problem.
>
> Are the EOs shared across sessions? If not, you could always subclass ERXEC and add a region property, then set your subclass as the factory EC. When the user logs in and the session is created, set the region of the default EC to be the region of the user.
That's something I'll go to try.
Just to give you a feeling of what I am trying to accomplish, maybe someone else also has/had this sort of requirement.
We have a (lets talk database at the moment) table PRODUCT with only ID (pk) and PRODUCT_CODE columns. The customer wants to have the ultimate flexibility to kind of add any column to the PRODUCT table without having to actually alter the table itself. So I came up with some kind of relational meta model: I have a table COLUMN_VALUE with ID, COLUMN_NAME, VALUE, DISPLAY_SEQUENCE and to-one foreign keys to PRODUCT and REGION. Each of the column values may be region specific.
A user of our appliation is assigned to one or more regions. Depending on his/her credentials the user might be allowed to only view certain columns, change region specific values or even create a new column, which will then be assigned to any/all regions (that's an admin's task to do, a business manager's to decide).
A logged-in user must select one of his/her assigned regions to have kind of a context for what he/she is doing. A user must however be able to switch that regional context on the fly while logged in.
So what I try to create is some kind of region layer that is put underneath the standard EO layer that takes into consideration at any given time the regional context of the logged-in user. So the basic question is where do I put the region information so that the controller classes in the application as well as the whole business logic in the separate EO framework can access it.
It's fun.... certainly it's a challenge
---markus---
>
>> On Nov 7, 2015, at 9:56 AM, Markus Ruggiero <email@hidden> wrote:
>>
>> Folks,
>>
>> I have the following problem:
>> My application must support different geographical regions. A logged-in user is assigned a region. This uses info is stored in Session. My EOs have business logic that must act region specific. How can I let the EOs know about the current region (from session().currentUser().region() )? The business logic is in its own framework and knows nothing about sessions (which is how it supposed to be). Would ERXThreadStorage be of any help here?
>>
>> Example of what I need:
>> Entity Product has a region specific product description. So simple accessors "description()" and "setDescription(String text)" are not good enough. The logic inside these accessors MUST take the current user's region into account.
>>
>> I used to have my own editing context class with a session instance variable. This worked before because I had the business logic and all the controller code in the same project. Now with the separation into different projects this does not work anymore (which is actually quite ok, I know it was a kludge before).
>>
>> Thanks for any help
>> ---markus---
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden