Facu,
you might consider working with 1+n sessions. Use one (shared) session for all the general stuff and 1/session for session specific stuff.
Another approach is to share a MagmaSession between Seaside sessions until a user logs in. Then you'll have a MagmaSession per logged-in user.
e.g.
MySystem>#magmaSession | seasideMagmaSession | seasideMagmaSession := WASession current magmaSession. seasideMagmaSession notNil: [^seasideMagmaSession]. ^self sharedMagmaSession
MyWASession>#magmaSession ^magmaSession
MyWASession>#loginUser: aUserName magmaSession := self createMagmaSessionConnectAs: aUserName
Hope you get the idea.
CU,
Udo
On 14.11.10 23:49, Facundo Vozzi wrote:
Hi all, I added magma session to my application seaside session (a subclass of WASession) so each user has his own magma session. My problem is with magritte description because I need, on the class side, set list of options. By example:
User class >>descriptionRol "Answer a magritte meta description for the receiver rol attribute."
^MAMultipleOptionDescription new accessor: #roles; label: 'Roles'; priority: 200; componentClass: MAListCompositonComponent; options: MySystem singleton roles; beSorted; yourself
The problem is "MySystem singleton roles" beacuse is in other magma session when the user add or edit an instance of User on the seaside application. I "hack" my seaside components to override the options with a collection of instances (by example: Rol allInSession: aUserSession) inside of the user session but it's very ugly. Just a test. How do you configure the maggrite description to deal with this problem? Is a common practice add a new magma session in every session session?
Thanks in advance, Facu
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma