Re: [Zope-CMF] Extending FTI.isConstructionAllowed
Wichert Akkerman wrote: > Previously yuppie wrote: >> 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? >> Question: zope.container.constraints handles this in a different way, >> using a precondition defined in the interface. Did you have a look at >> that code? If we switch to that pattern, we could use different >> preconditions for containers with different interfaces. Would that be >> sufficient for your use case? > > I don't think that is sufficient since it does not provide an extension > point you can hook into 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"? 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. 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: > 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). 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 iD8DBQFKH+mA+gerLs4ltQ4RAhG7AKDZsLKNRVUHBfLoq/tbGsqU50TVJgCgr3Np 06Ck6T4Xyvru7WKgm8vUjbs= =2I0k -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
Previously yuppie wrote: > 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? > > Question: zope.container.constraints handles this in a different way, > using a precondition defined in the interface. Did you have a look at > that code? If we switch to that pattern, we could use different > preconditions for containers with different interfaces. Would that be > sufficient for your use case? I don't think that is sufficient since it does not provide an extension point you can hook into and does not support portal types. 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
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? Question: zope.container.constraints handles this in a different way, using a precondition defined in the interface. Did you have a look at that code? If we switch to that pattern, we could use different preconditions for containers with different interfaces. Would that be sufficient for your use case? 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
[Zope-CMF] CMF Tests: 7 OK
Summary of messages to the cmf-tests list. Period Thu May 28 12:00:00 2009 UTC to Fri May 29 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: Thu May 28 21:31:14 EDT 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-May/011540.html Subject: OK : CMF-2.1 Zope-2.11 Python-2.4.6 : Linux From: CMF Tests Date: Thu May 28 21:33:20 EDT 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-May/011541.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.6 : Linux From: CMF Tests Date: Thu May 28 21:35:26 EDT 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-May/011542.html Subject: OK : CMF-trunk Zope-2.11 Python-2.4.6 : Linux From: CMF Tests Date: Thu May 28 21:37:27 EDT 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-May/011543.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.6 : Linux From: CMF Tests Date: Thu May 28 21:39:27 EDT 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-May/011544.html Subject: OK : CMF-trunk Zope-trunk Python-2.5.4 : Linux From: CMF Tests Date: Thu May 28 21:41:27 EDT 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-May/011545.html Subject: OK : CMF-trunk Zope-trunk Python-2.6.1 : Linux From: CMF Tests Date: Thu May 28 21:43:27 EDT 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-May/011546.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
[Zope-CMF] Extending FTI.isConstructionAllowed
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? Wichert. ___ 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
