"Phillip J. Eby" a écrit :
> It sounds to me like you need to be using the getId() method instead of the
> .id attribute. I think that the id attribute is being phased out in favor
> of getId().
I was already told about the getId but the problem goes further than access to
I get the same non authorized message when accessing other attributes computed
by the skinscript.
I do not understand why I have no problem (I mean do not need
access_to_unprotected hack) with standard stored ZClass-dataskin instances but
non stored instances...
I suppose there is something different between the two cases going on during
the construction of the instances
but have not been able until now to get the point.
My Python is not fluent enough to allow me to understand the following code of
_v_itemConstructor = ComputedAttribute(lambda s,
> I'm somewhat reluctant to enable access to unprotected subobjects in the
> DataSkin base class; it seems a little too broad of an access level. The
> other alternative would be to allow SkinScript expressions free rein as
> regards security - but that's too broad also. The optimum would be to
> allow SkinScript expressions full access to the targeted DataSkin's direct
> attributes, but normal (validated) access to everything else, but I'm not
> sure how to do this safely.
> This is an example of why I consider ZPatterns a hack - too many places
> where it depends on Zope innards like this.
I get your point but I think that something a la ZPatterns should be integrated
in the Zope core
to separate logic and storage especially now that ZPT allow a very clean
separation between logic and presentation.
I would appreciate to know the position of DC about the design objectives of
rue Victor Horta, 30
Tel 010 457490
Mob 0477 363942
TVA 467 093 008
RC Niv 49849
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -