AW: [Zope3-dev] role (contextual) services?l

[Roger ineichen]

Thanks for all infos
to this topic.

> On Friday 02 April 2004 19:32, Roger Ineichen wrote:
> > What do you think about to let,
> > in a site, for each role, register a (adapter, menu,
> presentation ...)
> > service?
> 
> I'll give you a tentative pronouncement: no way!
> 
> > This role (contextual) services can serv different adaperts, views 
> > etc for different roles.
> >
> > This way we could build role (contextual) sites
> > which look different for each role.
> >
> > And a nice side effect could be, it could reduce
> > the permission settings, because you know which role
> > is accessing a view which is served from a role
> (contextual) service.
> 
> The component architecture in Zope 3 has nothing to do with
> security. In fact, 
> the CA is on a lower level than security, since security 
> depends on the CA.
> 
> BTW, if you want different looking sites for different roles,
> I guess you 
> could implement some default skin or new URL namespace that 
> picks a skin 
> based on a user's permission. The plugability of Zope 3 
> should make this 
> possible. 

Yes, I know, that's a way for doing this,
but we have a more complex situation where we should 
simplify. This could be one way for us, perhaps we will
find another way for to serv contextual information
of our instances.

If somebody is interested in what we try to do, 
you can read more. But I won't waste your time,
it's just background information. Feel free to ask
if you have questions. 



We working on a contextual content type, which provides models. The main
target is to give different models to a instance. Each model is in a context
of the instance. 
(This context has nothing to do with the Zope3 context) 
We look up the different models in the context's thru different 
adapters.
This could be like Stephan told, if a principal has a role and 
has based on this role a permission he get a adapter or not. This means also
if a principal is in more then one role he has more dapaters and can access
more context's in a instance. Perhaps that's not what we whant. Perhaps Yes.
I'm not shure at this time. Or it could depend on customers whishes.

We looking for a way if a principal has a role A, he get the 
adapter Adapter_A and if a principal has role B, he get the adapter
Adapter_B. Ok, that's not provided form Zope3 that's OK.

Hm, I was checking out to return different adapters
for different roles. 
Perhapse a group concept like Philip told and where  
a principal just can be in one group. (Perhaps called
context group) could solve this.

This could mean if you are in a (context)group Master, you get a
MasterAdapter() where you can lookup a Model_A in the instance in a context
IInfo_A. And if you are in a group Member you get 
the adapter MemberAdapter() where you lookup Model_B in a context IInfo_B. 

This means, the contextual content type can provide for each 
(context)group different models.

I you are wondering what we do, read more below.

Why do we provide different models in a instance and 
this in different contexts???

Our idea: A instance is just a location and is persistent. 
The models in this instance can be easy
replaced and enhanced. We can provide old models 
and new models at the same time in different context's. 

This means a customer whould like to have new 
functions in a content type, but some users of the 
system whould like to have the old functions provided. 

Sometimes if the new model and the old model are 
inconsitent there is a hard way to bring this whishes 
together and needs big changes or a new content type 
which works totaly different.

This also means in such a case you can't use standard 
models on each project and you have to develope every 
time custom classes. We are looking for a way where we 
can use simply models and bring them togehter in a context 
of a instance. 

For me it's hard to explain our concept in english
and perhaps I use the wrong words that give a wrong meaning, perhaps we can
give more informations in the next month if 
we have a little example. 

Till now a simply description could be:
We use the annotation concept in a standard way, where 
everybody can use and develope with. This concept
gives you empty instances where you can fill up with 
a content (meta) type. If you give a instance such a 
type, the instance provides context and models in it.

(This gives also a marker interface to the instance.
Till now, on this marker interface are the dapters 
registred. (This means we have all adapters available
and have to enabel or disable them over permissions.)
Remember, each of our adapter is providing a different 
model in a context.)

This means also you are totaly free of implementing 
what you whant in such a instance.

Another part of our idea is to break up the hard 
relation of a content type and it's data.
This means the model describes just what he can 
contain/provide. Like a model can have childs of 
IPerson. Now it's up to the (Meta-Type) administator 
which implementation of IPerson he whould let put in this model. (A
Meta-Type Adminstrator could be a Administrator of a site. He has the
permission to define new Meta-Type's in this site) 
(A Meta-Type is a definition which describes a Type.
A Instance is based on a Type)

In a working application this could mean. A user
is putting Friends (IPerson) in his model and he can
also put every other IPerson implementation in this 
model. (It depends on a Meta-Type definition in a site,
which is defining the Domain-Model.)
(A Domain-Model is defining simply models to a 
business model).
And a instance can have more Domain-Model's in different context of the
instance. And so on...  
 

Thanks for answering my questions about roles, groups etc
I think with this informations I can find a way for to 
lookup our models in the different context in a instance.

Regards Roger
 
> Regards,
> Stephan
> --
> Stephan Richter
> CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. 
> student) Web2k - Web Software Design, Development and Training
> 
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev at zope.org http://mail.zope.org/mailman/listinfo/zope3-dev
>