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 wich...@wiggy.netIt 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 wich...@wiggy.netIt 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 wich...@wiggy.netIt 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
-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 Designhttp://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
