[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
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
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 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
-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 Designhttp://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
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
