Re: [Zope-CMF] Extending FTI.isConstructionAllowed
Previously Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Wichert Akkerman wrote: > > I have a use case where I need to put additional restrictions on object > > creation, in particular I need to restrict the maximum depth of items > > inside of a container of a specific type. The ideal place to put such a > > restriction seems to be the isConstructionAllowed method on the FTI. > > Currently this method is not very extensible, which leads to complicated > > code in various FTI types. > > > > I am considering to add an extension point here, something like this: > > > > class ITypeConstructionFilter(Interface): > > def __init__(fti, container): > > """Adapt on the FTI of the object being created and the target > > container""" > > > > def allowed(): > > """Check if construction is allowed.""" > > > > > > current checks such as the workflow check that was added in CMF 2.2, or > > the type constraint logic Plone has in ATContentTypes could be moved to > > such an adapter. The standard isConstructionAllowed method could then > > query all registered adapters to check if construction should be possible. > > > > Does this sound sensible? > > I'm not sure about querying all adapters: I think it would be clearer > to query the one adapter whose name corresponds to the type name of the > FTI (the "query all" case leads to tricky / emergent behavior). Querying a single adapter makes it very hard to use this as an extension point. Being able to have multiple independent validation-hooks is the whole point of my suggestion, and being able to only use a single adapter would make that impossible. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Extending FTI.isConstructionAllowed
Previously yuppie wrote: > It's no hook for adding restrictions, but it's a hook for using > different implementations. > > > and does not support portal types. > > Do you mean "does not support per portal type hooks" or do you mean > "does not support filtering based on portal type name"? The latter. zope.* has no concept of FTIs or portal types. > A CMF specific precondition would look up type restrictions in the fti > of the container. > > checkFactory and checkObject are quite similar to isConstructionAllowed. > I think we should reimplement this based on zope.container before we > start adding new features. I looked at the code in zope.container and frankly it scared me. I found the documentation and code hard to follow, and the usage of sys._getframe() made me drop the idea of using it. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Extending FTI.isConstructionAllowed
Previously Wichert Akkerman wrote: > I have a use case where I need to put additional restrictions on object > creation, in particular I need to restrict the maximum depth of items > inside of a container of a specific type. The ideal place to put such a > restriction seems to be the isConstructionAllowed method on the FTI. > Currently this method is not very extensible, which leads to complicated > code in various FTI types. > > I am considering to add an extension point here, something like this: > > class ITypeConstructionFilter(Interface): > def __init__(fti, container): > """Adapt on the FTI of the object being created and the target > container""" > > def allowed(): > """Check if construction is allowed.""" > > > current checks such as the workflow check that was added in CMF 2.2, or > the type constraint logic Plone has in ATContentTypes could be moved to > such an adapter. The standard isConstructionAllowed method could then > query all registered adapters to check if construction should be possible. I have implemented this on the wichert-constructionfilter branch of Products.CMFCore. I intend to merge this to trunk end of this week. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] CMF Tests: 7 OK
Summary of messages to the cmf-tests list. Period Mon Jun 1 12:00:00 2009 UTC to Tue Jun 2 12:00:00 2009 UTC. There were 7 messages: 7 from CMF Tests. Tests passed OK --- Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.6 : Linux From: CMF Tests Date: Mon Jun 1 21:19:31 EDT 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-June/011568.html Subject: OK : CMF-2.1 Zope-2.11 Python-2.4.6 : Linux From: CMF Tests Date: Mon Jun 1 21:21:32 EDT 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-June/011569.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.6 : Linux From: CMF Tests Date: Mon Jun 1 21:23:41 EDT 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-June/011570.html Subject: OK : CMF-trunk Zope-2.11 Python-2.4.6 : Linux From: CMF Tests Date: Mon Jun 1 21:25:41 EDT 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-June/011571.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.6 : Linux From: CMF Tests Date: Mon Jun 1 21:27:41 EDT 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-June/011572.html Subject: OK : CMF-trunk Zope-trunk Python-2.5.4 : Linux From: CMF Tests Date: Mon Jun 1 21:29:42 EDT 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-June/011573.html Subject: OK : CMF-trunk Zope-trunk Python-2.6.1 : Linux From: CMF Tests Date: Mon Jun 1 21:31:45 EDT 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-June/011574.html ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Extending FTI.isConstructionAllowed
Wichert Akkerman wrote: > Previously yuppie wrote: >> A CMF specific precondition would look up type restrictions in the fti >> of the container. >> >> checkFactory and checkObject are quite similar to isConstructionAllowed. >> I think we should reimplement this based on zope.container before we >> start adding new features. > > I looked at the code in zope.container and frankly it scared me. I found > the documentation and code hard to follow, and the usage of > sys._getframe() made me drop the idea of using it. That scary code is used for supporting 'contains' declarations in the interface. I don't propose to write something similar for CMF. AFAICS it is sufficient to set __setattr__.precondition directly for supporting checkObject. A precondition that just checks allowType would look like this: class PortalTypePrecondition: def __call__(self, container, name, obj): ti = container.getTypeInfo() if ti is None: return if not ti.allowType(obj.getPortalTypeName()): raise ValueError(u'Disallowed subobject type: %s' % type_name) Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Extending FTI.isConstructionAllowed
Previously yuppie wrote: > Wichert Akkerman wrote: > > Previously yuppie wrote: > >> A CMF specific precondition would look up type restrictions in the fti > >> of the container. > >> > >> checkFactory and checkObject are quite similar to isConstructionAllowed. > >> I think we should reimplement this based on zope.container before we > >> start adding new features. > > > > I looked at the code in zope.container and frankly it scared me. I found > > the documentation and code hard to follow, and the usage of > > sys._getframe() made me drop the idea of using it. > > That scary code is used for supporting 'contains' declarations in the > interface. I don't propose to write something similar for CMF. > > AFAICS it is sufficient to set __setattr__.precondition directly for > supporting checkObject. > > A precondition that just checks allowType would look like this: > > >class PortalTypePrecondition: > >def __call__(self, container, name, obj): > >ti = container.getTypeInfo() >if ti is None: >return > >if not ti.allowType(obj.getPortalTypeName()): >raise ValueError(u'Disallowed subobject type: %s' % > type_name) That assumes the object has already been constructed and you're only testing constraints for adding the instance to the container. Our use case is different: we are testing at a point where construction has not happened yet. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Extending FTI.isConstructionAllowed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: > Previously Tres Seaver wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Wichert Akkerman wrote: >>> I have a use case where I need to put additional restrictions on object >>> creation, in particular I need to restrict the maximum depth of items >>> inside of a container of a specific type. The ideal place to put such a >>> restriction seems to be the isConstructionAllowed method on the FTI. >>> Currently this method is not very extensible, which leads to complicated >>> code in various FTI types. >>> >>> I am considering to add an extension point here, something like this: >>> >>> class ITypeConstructionFilter(Interface): >>> def __init__(fti, container): >>> """Adapt on the FTI of the object being created and the target >>> container""" >>> >>> def allowed(): >>> """Check if construction is allowed.""" >>> >>> >>> current checks such as the workflow check that was added in CMF 2.2, or >>> the type constraint logic Plone has in ATContentTypes could be moved to >>> such an adapter. The standard isConstructionAllowed method could then >>> query all registered adapters to check if construction should be possible. >>> >>> Does this sound sensible? >> I'm not sure about querying all adapters: I think it would be clearer >> to query the one adapter whose name corresponds to the type name of the >> FTI (the "query all" case leads to tricky / emergent behavior). > > Querying a single adapter makes it very hard to use this as an extension > point. Being able to have multiple independent validation-hooks is the > whole point of my suggestion, and being able to only use a single > adapter would make that impossible. I don't *want* multiple third-party products to register this adapter: I think it belongs to the integrator to set the policy for the site. "Reusable policy" is an oxymoron. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKJVTi+gerLs4ltQ4RAnT7AJ0aNlB5Vr1MHdSnBMcxrcfb70dIDQCgmAv0 VhcD0BrbHpW1c60aZlCvai0= =haLI -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Extending FTI.isConstructionAllowed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: > Wichert Akkerman wrote: >> Previously Tres Seaver wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> Wichert Akkerman wrote: I have a use case where I need to put additional restrictions on object creation, in particular I need to restrict the maximum depth of items inside of a container of a specific type. The ideal place to put such a restriction seems to be the isConstructionAllowed method on the FTI. Currently this method is not very extensible, which leads to complicated code in various FTI types. I am considering to add an extension point here, something like this: class ITypeConstructionFilter(Interface): def __init__(fti, container): """Adapt on the FTI of the object being created and the target container""" def allowed(): """Check if construction is allowed.""" current checks such as the workflow check that was added in CMF 2.2, or the type constraint logic Plone has in ATContentTypes could be moved to such an adapter. The standard isConstructionAllowed method could then query all registered adapters to check if construction should be possible. Does this sound sensible? >>> I'm not sure about querying all adapters: I think it would be clearer >>> to query the one adapter whose name corresponds to the type name of the >>> FTI (the "query all" case leads to tricky / emergent behavior). >> Querying a single adapter makes it very hard to use this as an extension >> point. Being able to have multiple independent validation-hooks is the >> whole point of my suggestion, and being able to only use a single >> adapter would make that impossible. > > I don't *want* multiple third-party products to register this adapter: > I think it belongs to the integrator to set the policy for the site. > "Reusable policy" is an oxymoron. Ugh, following up to myself: If you really *want* to allow every adapter registered anywhere for that interface to play, you can still get that under my scenario, by registering the default (unnamed) adapter to do your dance. That implementation would be:: class PromiscuousConstructionFilter: implements(ITypeConstructionFilter) def __init__(self, (obj, container): self.obj = obj self.container = container def __call__(self): for name, filter in getAdapters((self, container), ITypeConstructionFilter): if name: # skip default if not filter.allowed(): return False The policy choice would then be whether to actually register the "promiscuous" adapter (which would *not* be anabled by default in CMF). Your alternative makes anybody who does not want the feature responsible for suppressing the unwanted filter adapter registrations everywhere, which is unacceptable. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKJViS+gerLs4ltQ4RAuTHAJsGPfSmI2TrhJdbnMvyzDlNt/pbRgCgpxEz jbBCxsR5758+fjM5heSL+5M= =by9h -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
