There is an userInfo dictionary in the editing context, you can store stuff in there as well. At page level, when you have access to all contextual information (local, user, etc.) it’s time to set that in the editingContext userInfo dictionary before you trigger your core methods.
Depending on the use case, ERXThreadStorage or EOEditingContext userInfo are good candidates. jfv > Le 7 nov. 2015 à 10:38, Ken Anderson <[email protected]> a écrit : > > Is currentUser not an EO? I’m guessing not, otherwise you wouldn’t have this > 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. > >> On Nov 7, 2015, at 9:56 AM, Markus Ruggiero <[email protected] >> <mailto:[email protected]>> 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 protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com >> >> <https://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com> >> >> This email sent to [email protected] <mailto:[email protected]> > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected] > <mailto:[email protected]>) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/jean_francois_veillette%40yahoo.ca > > <https://lists.apple.com/mailman/options/webobjects-dev/jean_francois_veillette%40yahoo.ca> > > This email sent to [email protected] > <mailto:[email protected]>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
