* Cédric Krier [2011-11-29 11:25 +0100]:
> One question I got is when should we test the access right/state.
> For now, this design looks like it is only done on client side except if
> there is some extra code in the method. Or as you said we could use a
> decorator but the issue with decorator is the extension by other
> modules where you lose the fact that the decorator is called first but
> it is perhaps not a problem.
What about overriding __getattribute__ method or something like that in Model?
Too much overhead, maybe?
Don't like too much. I prefer explicit.
I have an idea about decorators (I like them they are a nifty syntax).
Maybe the decorator is used only to register the method as being
protected by inserting its name into an object specifying the access
rights. Then we doing the resolution of the request the first thing to
do would be to check this object to grant/refuse access to the method.
Something like:
1 import types
2
3 def grant(method):
4 method._protected = True
5 return method
6
7 def register_methods(klass):
8 for name in dir(klass):
9 attribute = getattr(klass, name)
10 if isinstance(attribute, types.MethodType):
11 if getattr(attribute, '_protected', False):
12 klass._protected[name] = 'protected'
13 return klass
14
15 @register_methods
16 class A(object):
17
18 _protected = {}
19
20 def toto(self, a):
21 print a
22
23 @grant
24 def tata(self, b):
25 print b
26
27 print A._protected
That way only the name is stored and the clash between inheritance and
decorators do not happen.
The issue with '_protected' being a class attribute is that when using
a multiple database set-up an installed module might change the
behavior of another behavior. This side effect has to be take into
account (I'll try to think about that after having done some
codereviews and GIS stuffs).
--
Nicolas Évrard
B2CK SPRL
rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
E-mail/Jabber: nicolas.evr...@b2ck.com
Website: http://www.b2ck.com/
--
tryton-dev@googlegroups.com mailing list
