Florent Guillaume wrote:
Does it work to just set __parent__ to the container? Or does the
zopesecuritypolicy require more accurate context?
Yes, the unset location is the problem, why the local security cannot
be looked up.
Martijn Faassen wrote:
Benji York wrote:
Martijn Faassen wrote:
* after object creation but before the object is added,
various things are done to the object.
> * authorization error: user cannot access various attributes.
If these things are done by subscribers, would using trusted
I guess it could; I've used a trusted adapter in a few places to get
around security concerns.
However, not everything is done by subscribers. I have a little
workflow system that in some cases can create new versions of objects,
My frustration is more that one has to do *something* special than
that there aren't any solutions. Knowing to use trusted subscribers
and having to design ones application around them would be another
thing one would need to know to 'please' the security system. I know
of course that security is hard, so maybe there's no way than to just
bite the bullet...
A year ago we wrote a little initializer framework
(svn://svn.tiks.org/repos/Tiks/trunk/src/tiks/initializer) that offers a
possible *general* way to initialize components. A inializer subscribers
is hooked in using the ObjectAddedEvent. At that time the component is
already located within its parent and all intialisation actions can be
performed (including utility registration etc.):
- Offers class- or adapter-based inialisation ( -> ClassInializer, ->
- Takes inheritence during initialisation (reversed rmo) of classes and
adapters into account
- Offers initalisation data handling using keyword arguments and a
signature specifying those arugments
- Supports the form framework (-> add form, add wizard)
General Subscriber Hook-Problem:
- Those subscribers are not ordered. So I can imagine a scenario that
other subscribers like to 'use' the object before it is initialized
correctly (-> For example catalog indexes and unpolished object). So far
we had no concerns with that fact.
Its only a conceptual exampe for the tiks.typing resp. tiks.system
framework that is basing on generic implementation that gets
typed/classified only by a marker interface. But there you will see how
you can handle the inialisation including addforms and addwizards:
If you (or anybody else) are interessest to use or to extend the
framework, we could move the package to the zope repos too.
Zope3-dev mailing list