Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
Hi! Hanno Schlichting wrote: I don't know how such a feature removal or deprecation would be handled on the CMF level. AFAICS IWorkflowAware and IOpaqueItemManager methods (as defined in CMF 2.2) were added to CMFCatalogAware because at that time events were not available and it was easier to have all manage_after* and manage_before* methods in one place. But IWorkflowAware and IOpaqueItemManager have nothing to do with ICatalogAware and I can no longer see a good reason to keep them all in one mixin. I propose to split up CMFCatalogAware in CatalogAware, WorkflowAware and OpaqueItemManager mixins. All the interfaces provided by these base classes should be optional for CMF content. PortalFolderBase e.g. is not catalog or workflow aware, so it should not use those base classes. In a next step we can replace the OpaqueItemManager base class by an adapter and provide an alternative adapter that just looks for talkback. That makes opaque item support configurable and we can disable it by default. 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] CMF Tests: 3 OK, 1 Unknown
CMF Tests Summarizer wrote: Unknown --- Subject: UNKNOWN : CMF-trunk Zope-2.12 Python-2.6.2 : Linux From: CMF Tests Date: Sun Jul 26 21:12:15 EDT 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-July/011810.html Products.CMFCore 2.2.0dev now requires 'Zope2=2.12.0b4dev', but the last released version is 2.12.0b3. With 2.12.0b3 and Python 2.6 we would see one failure. I propose to wait for the next Zope release. 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] [dev] CMF 2.2 dependencies
Tres Seaver wrote: David Glick wrote: How soon can we expect a CMF 2.2 release? Are there blockers, aside from a final Zope 2.12 release? Ideally we'd like to make an alpha release of Plone 4 around the beginning of October (right, Eric?) I don't know of any real blockers: we should be able to release whenever Zope 2.12 does. I think these issues should be resolved before making a release: https://bugs.launchpad.net/zope-cmf/+bug/161664 (add views) https://bugs.launchpad.net/zope-cmf/+bug/308947 (_checkWorkflowAllowed) https://bugs.launchpad.net/zope-cmf/+bug/397795 (icon_expr) 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] [dev] CMF 2.2 dependencies
Tres Seaver wrote: yuppie wrote: Possible solutions: --- 1.) Make Zope = 2.12 required for CMF 2.2 and change all imports. 2.) Make Zope 2.13 required for CMF 2.2. 3.) Add zope.app.component and zope.app.container to CMF dependencies. 4.) Re-add zope.app.component and zope.app.container to Zope 2 trunk dependencies. 5.) Add a lot of try except imports and modify zcml files to make imports from both locations working. Any preferences or better ideas? I would change CMF 2.2 to import from the new locations, and require Zope = 2.12: I can see no benefit in trying to straddle with 2.11, and Plone 4.0 is supposed to move to Zope 2.12 and CMF 2.2 this year. Ok. I'm fine with that. If there are no objections I'll make 'Zope2 = 2.12.0b3dev' required and remove obsolete BBB code. 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] SVN: Products.CMFCore/trunk/setup.py - made new testing dependency caused by r99878 explicit
Modified: Products.CMFCore/trunk/setup.py === --- Products.CMFCore/trunk/setup.py 2009-07-05 15:31:13 UTC (rev 101587) +++ Products.CMFCore/trunk/setup.py 2009-07-05 15:32:51 UTC (rev 101588) @@ -50,8 +50,13 @@ 'five.localsitemanager=0.3', 'Products.GenericSetup', ], - tests_require=['zope.testing=3.7.0', -], + tests_require=[ + 'zope.testing = 3.7.0', + 'Products.DCWorkflow', + ], + extras_require = dict( + test = ['Products.DCWorkflow'], + ), test_loader='zope.testing.testrunner.eggsupport:SkipLayers', test_suite='Products.%s' % NAME, entry_points= WA! Let's not codify the mistake: we should be ripping that dependency out by the roots! I don't think that change made things worse. +1 for removing that dependency in setup.py *and* the test 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] GenericSetup 1.5 release plans?
Hi! Tres Seaver wrote: I'm fine with releasing a 1.5.0b1 as soon as we establish the correct way to test the checkout: at the moment, I have one set of failures with the Zope 2.10 branch, another set with the 2.11 branch, and a third set with the trunk. The problem is that some fixes in GenericSetup 1.5 depend on five.localsitemanager 2.0 which in turn depends on Zope 2.12 (both without a final release). CMF.buildout includes five.localsitemanager trunk and Zope trunk, so all GenericSetup tests pass with that buildout. But that's no strict dependency. If you don't need the components handler improvements, GenericSetup trunk still works with older five.localsitemanager versions and Zope 2.10/2.11. In that case I see two testing errors in test_components. Not sure how to resolve this. 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] GenericSetup 1.5 release plans?
Wichert Akkerman wrote: Is there anything holding up a GenericSetup 1.5 release? I would like to start using it, and as far as I can see there is nothing holding up a release anymore. No objections. But it would be nice if someone could finish the documentation changes before the release: https://bugs.launchpad.net/zope-cmf/+bug/388380 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
Hi Wichert! Wichert Akkerman wrote: Previously yuppie wrote: 2.) The distinction between allowType() and isConstructionAllowed() was clear in CMF 2.1: allowType() checked a cheap, not permission related CMF specific restriction. isConstructionAllowed() checked generic permission related restictions. The new restrictions _checkWorkflowAllowed and ITypeConstructionFilter don't fit in one of these two categories. Is there a reason that the two have to be separate? I don't know the reasons, I just can guess. AFAICS it's not absolutely necessary, but using one method would require several changes. What is the downside of one call that does all necessary checks? These come to my mind: - You no longer can use TypeInformation.constructInstance to bypass the allowType() check. PortalFolderBase.invokeFactory checks allowType() before calling constructInstance. - You no longer can call CopyContainer._verifyObjectPaste from PortalFolderBase._verifyObjectPaste without performing redundant permission checks. - Actions have a similar distinction between 'available' and 'allowed'. The new 'add' actions in CMF 2.2 map allowType() and isConstructionAllowed() to 'available' and 'allowed' keys. allowType() and isConstructionAllowed() are both the wrong place for checking additional restrictions. But allowType() could become part of a more general precondition that could be checked by checkObject and a new checkPortalType (=CMF specific checkFactory) function. How do you see this working? If it's simple enough I might have enough time to work on it this week. In CMF we would add a __setattr__.precondition to IFolderish, Plone folders would use a modified interface with a different precondition. The preconditions would implement an interface like this one: class IFolderishPrecondition(Interface): def __call__(container, name, object): Test whether container setitem arguments are valid. Raise zope.interface.Invalid if the object is invalid. def portaltype(container, name, portaltype): Test whether objects provided by the portal type are acceptable Return a boolean value. _verifyObjectPaste would use checkObject, other places where currently allowType() is used would use a new checkPortalType function. Does that make sense to you? 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
Hi Wichert! 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? After (re)reading all the comments and having a closer look at the code I came to these conclusions: 1.) CMF 2.1 checks two different restrictions: allowType() and isConstructionAllowed(). PortalFolderBase._verifyObjectPaste just checks allowType() because in CMF 2.1 isConstructionAllowed() does basically the same permission check as CopyContainer._verifyObjectPaste. Changing isConstructionAllowed() without changing PortalFolderBase._verifyObjectPaste creates inconsistent behavior. The _checkWorkflowAllowed change and your branch are both broken. 2.) The distinction between allowType() and isConstructionAllowed() was clear in CMF 2.1: allowType() checked a cheap, not permission related CMF specific restriction. isConstructionAllowed() checked generic permission related restictions. The new restrictions _checkWorkflowAllowed and ITypeConstructionFilter don't fit in one of these two categories. 3.) I was wrong about comparing isConstructionAllowed with checkFactory and checkObject. These are used for checking general container constraints, not for checking user specific permissions. checkFactory doesn't work for CMF because it doesn't take the portal type as argument. My conclusion: allowType() and isConstructionAllowed() are both the wrong place for checking additional restrictions. But allowType() could become part of a more general precondition that could be checked by checkObject and a new checkPortalType (=CMF specific checkFactory) function. Plone could use its own precondition that checks registered ITypeConstructionFilter adapters. 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
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
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
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] SVN: Products.GenericSetup/trunk/Products/GenericSetup/browser/addWithPresettings.pt - don't rely on manage_page_header, manage_form_title and manage_page_footer (in Zope 2.12 they can'
Tres Seaver wrote: Log message for revision 100073: - don't rely on manage_page_header, manage_form_title and manage_page_footer (in Zope 2.12 they can't be acquired) What? That can't be right: it will break *tons* of applications. Who did that? Sorry. That checkin message was too short: This is only the case if the context of the view is also a view. In all other cases they still work. 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] which CMF for zope2.12
Michael Haubenwallner wrote: Thanks for your help, that works now. I installed these packages: Products.CMFCore-2.2.0dev-py2.6.egg Products.CMFDefault-2.2.0dev-py2.6.egg Products.GenericSetup-1.5.0dev-py2.6.egg five.localsitemanager-2.0dev-py2.6.egg Products.DCWorkflow-2.2.0dev-py2.6.egg I cannot add a 'CMF Site' though in the ZMI, here is the traceback http://gbe.d2m.at/Pastebin/37 Strange. That error looks like you are using five.localsitemanager-2.0dev with zope.component 3.5.0, but your Zope 2.12 should have zope.component 3.5.1 installed. Can you check your zope.component version? Maybe a different version is somewhere on your path? HTH, 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] Best use of source numbers in GS upgrade steps?
Hi Maurits!
Maurits van Rees wrote:
yuppie, on 2009-04-16:
I added several tests and cleaned up the behavior on the trunk:
http://svn.zope.org/*checkout*/Products.GenericSetup/trunk/Products/GenericSetup/tests/upgrade.txt
Please let me know if I did break useful behavior.
Ah, that looks much saner, thanks! Nothing breaks here AFAICT.
And this tells me that my way of specifying source=1.1.9 and dest=2.0
should still work. A snippet of those tests adapted to my numbers
gives this result:
1.1.9 (source) 1.1.2 (current) 1.2 (dest)
e.versionMatch('1.1.2')
False
e.isProposed(tool, '1.1.2')
False
bool(_extractStepInfo(tool, 'ID', e, '1.1.2'))
True
If you add that test to the trunk this behavior will become officially
supported...
So the version does not match and the step is not proposed, but the
step info is extracted anyway, and as far as I can see this is what
matters in the end, as this is called in listUpgradeSteps.
Well. I was focused on 'isProposed'. This is the definition:
Check if a step can be applied.
False means already applied or does not apply.
True means can be applied.
Your result is False for a step that should be applied.
BTW, do I understand correctly that when in this example we add a
checker that returns False the step will still be shown?
*All* unchecked steps are not recommended, run on your own risk. The
checker is just a restriction like versionMatch. In same cases it might
still make sense to (re-)run these steps.
But I'm sure the UI can be improved. Please note that hiding these steps
better will also hide your unchecked step.
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] Best use of source numbers in GS upgrade steps?
Rob Miller wrote: thinking about it now, though, i'd say perhaps the zcml should support only including a source version, with the setup tool persisting the id of each upgrade step when it is run. then the UI would show an upgrade step as needing to be run if a) the loaded profile version is greater than the source version specified in the ZCML and b) the id of the upgrade step is not yet stored in the setup tool's list of completed steps. feel like fixing it? ;) Did you have a look at the changes I made on GS trunk? Looks like your proposal is based on the 1.4 code and moves in a different direction. 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] IIndexableObjectWrapper
Martin Aspeli wrote: Plone 3.3's IIndexableObjectWrapper implementation (in plone.indexer) has a method _getWrappedObject(), to return the object that was wrapped by the indexable object wrapper. It is (or rather, will be) used by TextIndexNG3, which needs to access the raw object during indexing. Why is there a need to access the raw object? The wrapper should provide all the interfaces and attributes required for indexing. 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] IIndexableObjectWrapper
Wichert Akkerman wrote: Previously yuppie wrote: Martin Aspeli wrote: Plone 3.3's IIndexableObjectWrapper implementation (in plone.indexer) has a method _getWrappedObject(), to return the object that was wrapped by the indexable object wrapper. It is (or rather, will be) used by TextIndexNG3, which needs to access the raw object during indexing. Why is there a need to access the raw object? The wrapper should provide all the interfaces and attributes required for indexing. TextIndexNG3 needs the unwrapped object to be able to look for adapters that provide indexable text for that object. That's BBB code for old IndexableObjectWrappers that don't use IndexableObjectSpecification. With the correct __providedBy__ there is no need to unwrap the object before looking up adapters. 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] IndexableObjectWrapper
Hi! Miles wrote: And I would prefer a new marker interface 'IIndexableObject'. I guess there are use cases that don't require restricted searchResults based on allowedRolesAndUsers and usually we want to catalog more attributes than just this one. So we need an interface that marks objects that provide all the attributes we want to catalog, not an interface that specifies the available attributes. It's taken several readings for me to understand this, but I think I agree. I've adjusted the registrations so that they are based on a marker interface, IIndexableObject. Sorry. But it looks like you did get my point anyway. If the object already provides this index, no wrapping is carried out. I added some tests for this. I'm afraid there are still different opinions about useful fallbacks. Please see my reply to Tres. I also adjusted the registration to use ICatalogAware rather than IContentish, as that seemed to make more sense. In the long run I'd like to get rid of ICatalogAware. Improving the usage of object events should make it obsolete. The IndexableObjectWrapper doesn't use any features of ICatalogAware, so I can't see a need to use it here. I agree it belongs somewhere else. Maybe a registerWrapper method. But can't we make the adapter lookup in catalog_object optional and wouldn't that make test setups simpler? Ok, I bit the bullet and did some work on the tests. Great! 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] IndexableObjectWrapper
Hi! Tres Seaver wrote: yuppie wrote: But can't we make the adapter lookup in catalog_object optional and wouldn't that make test setups simpler? Agreed. I had expected that the catalog would do a queryAdapter, and default to the existing wrapper class if not found. Well. I had expected it would default to the unwrapped object. Restricted catalog queries rely on allowedRolesAndUsers, but AFAICS it is not essential for CMFCore that the object is wrapped before cataloged. The current code on the branch requires the new IIndexableObject interface. I'm not sure if we should make it required. It makes things more explicit, but creates an additional burden for simple use cases and unit tests. It should be sufficient to assume that objects without registered adapter are indexable unwrapped. 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] IndexableObjectWrapper
Hi! Tres Seaver wrote: Falling back to the current behavior is cheap, both at runtime and in maintenance costs. Why break BBB gratuitously? Because this would be a simple *generic* solution: w = queryMultiAdapter((obj, self), IIndexableObject, default=obj) That code could be pushed down the stack to ZCatalog and CMF could use that feature by registering a CMF-specific adapter. No need to override the catalog_object method in CatalogTool. And I doubt missing BBB would hurt many people: If you don't include the ZCML files from CMF, you have to update your registrations anyway. And who catalogs content that doesn't implement IContentish? 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] [dev] five.localsitemanager: 1.0 branch dependencies
Hi! setup.py says: install_requires=[ 'setuptools', 'zope.component 3.5dev', ], But CHANGES.txt says: * Rewrite PersistentComponents.registeredUtilities to not use internal methods. This makes it compatible with both zope.component 3.5.0dev and 3.5.0dev. [wichert] AFAICS the 1.0 branch works fine with zope.component 3.5. Two tests are currently failing, but they just show different, not broken behavior. I'd like to change install_requires to 'zope.component 3.6dev' and make tests work with zope.component 3.5.1 and older versions. Any objections? 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] [dev] five.localsitemanager: 1.0 branch dependencies
Tres Seaver wrote: Wichert Akkerman wrote: Previously yuppie wrote: setup.py says: install_requires=[ 'setuptools', 'zope.component 3.5dev', ], But CHANGES.txt says: * Rewrite PersistentComponents.registeredUtilities to not use internal methods. This makes it compatible with both zope.component 3.5.0dev and 3.5.0dev. [wichert] AFAICS the 1.0 branch works fine with zope.component 3.5. Two tests are currently failing, but they just show different, not broken behavior. I'd like to change install_requires to 'zope.component 3.6dev' and make tests work with zope.component 3.5.1 and older versions. Any objections? I would just rip out the version requirement altogether (I did this the other day when testing CMFCore against the Zope2 trunk). Some fixes in GenericSetup 1.5 just work with zope.component = 3.5.0, so there is a need for a five.localsitemanager version that works with zope.component 3.5 *and* Zope 2.10/2.11. I haven't tested if zope.component trunk can be used with Zope 2.10 and I can't see a need for supporting that combination. For Zope 2.12 we will have five.localsitemanager 2.0, so I can't see a need to use five.localsitemanager 1.x with Zope = 2.12. five.localsitemanager trunk (2.0) has no version requirement specified. 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] IndexableObjectWrapper
Hi Martin! Martin Aspeli wrote: yuppie wrote: Martin Aspeli wrote: yuppie wrote: AFAICS wrapping the object before looking up adapters is unnecessary. The catalog should do the lookup directly and the existing features provided by IndexableObjectWrapper should be reimplemented as adapters. Bear in mind that there is a difference between getting the wrapper itself, and getting the value to catalogue for a particular *attribute* of the wrapper (e.g. allowedRolesAndUsers). Why do we need the wrapper? Why can't we look up directly the adapter for the particular attribute? This could work as well. It does make it harder to change the policy en masse for a particular type (you'd need to override all the adapters, say). One reason to do that may be if you have a very simple object that you know exactly how to catalogue, and you don't want the overhead of looking up various adapters. I did have a closer look at this: The right place for looking up attribute specific adapters directly is deep in the ZCatalog code. And it might indeed be overkill to use separate adapters for several attributes of several content types. So now I basically agree with the solution Miles and you did propose. But I still have some questions: Why is IIndexableObjectWrapper in Plone a multi-adapter and not a simple adapter for object? Could we push this further down the stack to the ZCatalog, making it unnecessary to override catalog_object in CMF? AFAICS all CMF-specific stuff could be done inside the wrapper. Still, the important use case, imho, is to make custom indexers for your custom types. I quite like the pattern in plone.indexer where we use an annotation to make a function into an indexer adapter: http://pypi.python.org/pypi/plone.indexer I agree that's an important use case, but looking up IIndexableObjectWrapper based on the object provides already a solution for it. So we have a basic solution inside the framework and hook for plugging in alternative solutions like plone.indexer. 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] IndexableObjectWrapper
Hi! Miles wrote: Hi, snip Could we push this further down the stack to the ZCatalog, making it unnecessary to override catalog_object in CMF? AFAICS all CMF-specific stuff could be done inside the wrapper. Maybe. Touching ZCatalog is kinda scary, though. I think trying to remove catalog_object completely might require significantly more thought. There are lots more ways in which the basic ZCatalog can be used that we need to consider, in contrast to CatalogTool. What happens if you have two catalogs - should they always both apply the same wrappers? What if you want an unwrapped object to be cataloged in one of them? It's making my head hurt ... It would be an additional hook. If no wrapper is registered the behavior of ZCatalog would be exactly the same as now. But so far we don't have decided to make Zope 2.12 required for CMF 2.2, so we have start with an implementation in CMF. For now I just want to make sure we don't add CMF-specific stuff if we don't need it. However, one thing that I'd like an opinion on is whether it's useful to move the handling of workflow variables out of catalog_object and into the IndexableObjectWrapper class? To my mind it seems cleaner to move it, but I'm not sure on the BBB impact. +1 I can't see any additional BBB issues. Who ever uses a customized IndexableObjectWrapper uses also a customized catalog_object method. I'm still not sure if we should just adapt the object or also the portal or the catalog: Registering different adapters for different portals doesn't make much sense to me. If you need portal specific behavior you can register local adapters. Registering different adapters for different kinds of catalogs might be more useful and while 'portal' is a CMF specific concept the catalog itself exists always. The other reason for adapting portal or catalog is that we want to use them inside the adapter. We need some kind of context for looking up stuff like workflow variables. But do we need the portal, the context of the catalog or the context of the object? If the context of the object is sufficient, we don't need a multi-adapter. If we just need the catalog and its context, we still have a generic solution for Zope 2. If we need the portal, we have a CMF-specific solution. 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] SVN: Products.CMFCore/trunk/Products/CMFCore/tests/test_CatalogTool.py Clean out module-scope imports.
Hi Tres! Tres Seaver wrote: yuppie wrote: Tres Seaver wrote: Log message for revision 97800: Clean out module-scope imports. [...] What was wrong with these imports? I don't like module-scope imports in unit tests: I want tests to *fail*, not be skipped, when something is not importable. I put my rationale in this blog entry: http://palladion.com/home/tseaver/obzervationz/2008/unit_testing_notes-20080724 Thanks for the pointer. I agree with the Never import the module-under-test at test module scope-rule, but I'm not convinced the Minimize module-scope dependencies guideline is important. If you don't like module-scope imports and I don't like method-scope imports we need a policy to make sure we don't work against each other. I'm fine with following your policy if you think it is important, but I think we need an official decision. 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] IndexableObjectWrapper
Hi! Wichert Akkerman wrote: Previously Jens Vagelpohl wrote: That's not the issue I was trying to address. I was specifically talking about putting functionality in the most appropriate part of the stack, meaning moving it further towards the core. If there are bits and pieces that make more sense in the CMF then saying well, just install our package may satisfy users, but developers will continue wasting time maintaining different implementations. Why would there be multiple implementations if they can just use the existing one? I do not see that. For the CMF project it is essential to have full control over its own layer of the stack and to participate in the development of the Zope layer. Using packages from the Plone repository means either using them as a black box or joining the Plone Foundation to participate in their development. IMO both options are not acceptable. I do agree that work should be in in CMF itself, and this particular instance of the indexable wrappers is an excellent example of that. I hope that in the last few years we have already demonstrated that we really do want to work closer with the CMF and Zope communities. For technical reasons this collaboration is asymmetric. Plone is built on top of Zope and CMF, not the other way round. If you want to work really close with these communities, you have to be part of them and use their repository. 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] IndexableObjectWrapper
Hi! Miles wrote: Thanks for the clarification. The bits that confused me were: class IndexableObjectSpecification(ObjectSpecificationDescriptor) ... class IndexableObjectWrapper(object): implements(IIndexableObjectWrapper) __providedBy__ = IndexableObjectSpecification() What does this code actually achieve (I get the implements bit, obviously)?! This makes the wrapper transparent, allowing the index to look up adapters for the interfaces of the object. TextIndexNG3 works that way. Whether that is good or bad or should be changed is a different issue. I will write up a short proposal. AFAICS wrapping the object before looking up adapters is unnecessary. The catalog should do the lookup directly and the existing features provided by IndexableObjectWrapper should be reimplemented as adapters. 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] IndexableObjectWrapper
Hi Martin! Martin Aspeli wrote: yuppie wrote: For the CMF project it is essential to have full control over its own layer of the stack and to participate in the development of the Zope layer. Using packages from the Plone repository means either using them as a black box or joining the Plone Foundation to participate in their development. IMO both options are not acceptable. You don't need to join the Plone Foundation to develop packages in svn.plone.org. You *do* need to sign a contributor agreement granting some IP rights over that code to the Plone Foundation, in return for a promise that it will always be available under an open source license. There are no limits on who can sign that agreement or for what purpose they choose to work with the code in that repository. Of course, the same goes for svn.zope.org: you need to sign a document and grant certain rights over your work to the Zope Foundation. If CMF really cannot use packages not in svn.zope.org, then that's a bit sad and will invariably lead to a lot of re-invention rather than re-use. I don't really understand why it is essential to have this level of control over every line of code you use. This is entirely a self-imposed restriction. Just to make it clear: I'm talking about the code in the CMF and the Zope layer. Not about lower level layers. I'm absolutely fine with having Python and some other libraries in different repositories. And I'm not talking about CMF users. I'm sure there are good reasons to use Plone libraries together with the CMF. I'm talking about closely related code. Maintaining it in different repositories with different code ownership, license and policies creates extra costs. Either everybody has to work in both repositories or you have to ask people to make changes are releases. Refactoring code across repository boundaries becomes almost impossible. For technical reasons this collaboration is asymmetric. Plone is built on top of Zope and CMF, not the other way round. If you want to work really close with these communities, you have to be part of them and use their repository. I wrote a package that, I hope, is useful. I am pretty sure it'll work with plain CMF and therefore with other consumers of the CMF, and if doesn't, I'd consider that a bug and fix it. I'm willing to work to make that package a part of the CMF platform, whether optional or fully integrated. To a certain extent, it already is: someone suing the CMF can choose to use plone.indexer in their own project, though they'll need to install it themselves. I don't quite see how this is asymmetric. Rather, it is an outcome of the evolution of this particular package. It's up to the CMF maintainers to decide whether it is desirable to actually adopt this package as part of a standard release. It's not always going to be appropriate (or even if it is, it's not always going to be the case) for every new line of code that *could* be useful to all/most CMF consumers to be built as part of the CMF itself from the outset. If the CMF project has no model for incorporating code from outside its (rather small) community, then I think that is more to the detriment of CMF than to those who created those packages and chose to put the effort in to reduce their dependencies and make them more generally useful. I don't think it's the role of the CMF project to integrate all the code that could be useful for people building applications. Others like Plone can do that much better. The CMF has to become simpler, not more complex. Third party products always add complexity. Incorporating new code means replacing old code in a backwards compatible way, not just adding another hook. Code evolution is useful, but it can't replace discussions and consolidation. 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] IndexableObjectWrapper
Martin Aspeli wrote: yuppie wrote: AFAICS wrapping the object before looking up adapters is unnecessary. The catalog should do the lookup directly and the existing features provided by IndexableObjectWrapper should be reimplemented as adapters. Bear in mind that there is a difference between getting the wrapper itself, and getting the value to catalogue for a particular *attribute* of the wrapper (e.g. allowedRolesAndUsers). Why do we need the wrapper? Why can't we look up directly the adapter for the particular attribute? 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] SVN: Products.CMFCore/trunk/Products/CMFCore/tests/test_CatalogTool.py Clean out module-scope imports.
Tres Seaver wrote: Log message for revision 97800: Clean out module-scope imports. Changed: U Products.CMFCore/trunk/Products/CMFCore/tests/test_CatalogTool.py -=- Modified: Products.CMFCore/trunk/Products/CMFCore/tests/test_CatalogTool.py === --- Products.CMFCore/trunk/Products/CMFCore/tests/test_CatalogTool.py 2009-03-10 12:59:04 UTC (rev 97799) +++ Products.CMFCore/trunk/Products/CMFCore/tests/test_CatalogTool.py 2009-03-10 13:20:03 UTC (rev 97800) @@ -16,17 +16,7 @@ import unittest -import Testing -from AccessControl.SecurityManagement import getSecurityManager -from AccessControl.SecurityManagement import newSecurityManager -from DateTime import DateTime -from zope.interface.verify import verifyClass - -from Products.CMFCore.tests.base.dummy import DummyContent -from Products.CMFCore.tests.base.dummy import DummySite -from Products.CMFCore.tests.base.security import OmnipotentUser -from Products.CMFCore.tests.base.security import UserWithRoles from Products.CMFCore.tests.base.testcase import SecurityTest What was wrong with these imports? 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] GenericSetup Zope support
Hi! Wichert Akkerman wrote: Currently GenericSetup trunk no longer runs on Zope 2.10. If I try to run the tests I get this: File /src/Products.GenericSetup/Products/GenericSetup/registry.py, line 23, in ? from App.class_init import InitializeClass ImportError: cannot import name InitializeClass I can see two solutions: - add a BBB import to import from Globals - from App.class_init import default__class_init__ as InitializeClass Does anyone have preferences? Well. The third solution is making the next releases of Zope 2.10 and Zope 2.11 required for GenericSetup 1.5. Importing directly from App.class_init exposed a circular import issue in Zope, see: http://mail.zope.org/pipermail/zope-cmf/2008-December/028003.html I fixed that issue on Zope 2.10 and Zope 2.11 trunk and added InitializeClass as alias for default__class_init__. If you really need to run GenericSetup on older versions I'd prefer your first solution (BBB import from Globals) because it makes sure modules are imported in the right order. 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] GenericSetup Zope support
Wichert Akkerman wrote: Previously yuppie wrote: If you really need to run GenericSetup on older versions I'd prefer your first solution (BBB import from Globals) because it makes sure modules are imported in the right order. I see no good reasons not to support existing Zope 2.10 (and older) releases, and it would make it possible to use GenericSetup 1.5 with Plone, which is exactly what I want to do. In case you are waiting for a go-ahead: I didn't remember the GenericSetup 1.5 release is scheduled before the next Zope 2.10 release. In that case the BBB import from Globals is obviously the right solution. 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] [dev] CMF 2.2 plans?
Hi! Hanno Schlichting wrote: yuppie wrote: That would mean that CMFDefault-the-example-application will depend on z3c.form. If we are going to split off the forms we need to split off all browser views and the profiles that use these views. Something like 'cmf.app' that includes all the CMFDefault stuff Plone doesn't depend on. I'd be generally in favor of making the distinction between the CMFDefault-example-application and the reusable parts as used by for example Plone clearer. This can happen in two ways, though. Either move the example-application bits into a different package or move the reusable bits into one. It is much easier to move views, skins and profiles around than moving persistent or base classes to a new package. If you are really interested in doing this work, I'd be happy to figure out what parts of CMFDefault Plone is actually using. Fine. I'll come back to you *if* I'll do this work. But I currently have no plans to split off *everything* Plone doesn't use. E.g. moving content types to a different package doesn't seem to be worth the trouble. 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] [dev] CMF 2.2 plans?
Hi! Charlie Clark wrote: Am 02.03.2009 um 19:27 schrieb yuppie: This is on my todo list, but I still have to write a proposal. Hmm, I don't recall the issue here. There wasn't much discussion about this. Some time ago Dieter asked for grouping support: http://mail.zope.org/pipermail/zope-cmf/2008-September/027776.html I'm still struggling with the abolition of TypeInfo actions so I'd appreciate more discussion or simply explanation of this. The actions stored inside TypeInfos are not deprecated. We still have no replacement for them. CMF trunk makes the TypeInfos themselves also actions. I don't plan to change that. I just like to change how they are looked up. I'll write a proposal for that. 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] [dev] CMF 2.2 plans?
Hi! Martin Aspeli wrote: Jens Vagelpohl wrote: I'll look at CMFCore and CMFDefault over the next few days (I'm traveling). Are there any code changes that you still need or is the current trunk state ready to be released from your point of view? I haven't looked into it in great detail, but from what I can tell, these things are al stable. Yuppie would know best, though. There are 2 issues I'd like to see resolved before a beta is released: 1.) look up add view actions in a different way --- The current implementation is not flexible enough. There is no way to sort or group these actions. This is on my todo list, but I still have to write a proposal. 2.) get rid of redundant type info properties - See http://mail.zope.org/pipermail/zope-cmf/2009-January/028059.html Unfortunately nobody seems to feel responsible for this. We also should decide when to switch from zope.formlib to z3c.form. I have no ambitions to maintain zope.formlib based code for a long time. If we make Zope 2.12 the required platform for CMF 2.2 we can easily add z3c.form to the dependencies and refactor existing forms. Or we could move the forms and other views to a separate package. That way CMFDefault would not depend on zope.formlib nor on z3c.form. 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] [dev] CMF 2.2 plans?
Hi! Tres Seaver wrote: yuppie wrote: 1.) look up add view actions in a different way --- The current implementation is not flexible enough. There is no way to sort or group these actions. This is on my todo list, but I still have to write a proposal. Hmm, I don't recall the issue here. There wasn't much discussion about this. Some time ago Dieter asked for grouping support: http://mail.zope.org/pipermail/zope-cmf/2008-September/027776.html And I am missing a way to control the order of the add actions. The latter could be resolved by making the types tool an ordered container. But I tend to use special IActionCategory objects in the actions tool instead. They would look up the add actions in the types tool and provide features like filtering and sorting. The current mechanism was never released, so I'd rather change that now than after a release. We also should decide when to switch from zope.formlib to z3c.form. I have no ambitions to maintain zope.formlib based code for a long time. If we make Zope 2.12 the required platform for CMF 2.2 we can easily add z3c.form to the dependencies and refactor existing forms. I'm actually uncomfortable with either dependency. Or we could move the forms and other views to a separate package. That way CMFDefault would not depend on zope.formlib nor on z3c.form. I would favor the latter. cmf.forms, maybe? Don't know. I don't think we have the resources to maintain several kinds of full skins for CMFDefault. The browser views should *replace* the old skins and z3c.form is quite useful for writing all the necessary forms. That would mean that CMFDefault-the-example-application will depend on z3c.form. If we are going to split off the forms we need to split off all browser views and the profiles that use these views. Something like 'cmf.app' that includes all the CMFDefault stuff Plone doesn't depend on. 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] [dev] .zexp imports and notifyWorkflowCreated
Hi! Moving the notifyWorkflowCreated call from _finishConstruction to the IObjectAddedEvent subscriber changed the behavior of .zexp imports: The workflow state is now always reset to the initial state. AFAICT that's no useful behavior for imports. This is caused by the fact that the notifyCreated method of WorkflowTool always resets the workflow states. Is that a feature or a bug of notifyCreated? Is anybody using notifyCreated for resetting workflow states? Where is the best place to fix this? Should IObjectAddedEvent be triggered on imports? Should the subscriber call notifyWorkflowCreated if the object already has a workflow history? Should notifyWorkflowCreated call WorkflowTool.notifyCreated if the object already has a workflow history? Should WorkflowTool.notifyCreated call notifyCreated of workflows that already have a state? Should notifyCreated of workflows keep existing states untouched? AFAICS the easiest way to fix this is changing WorkflowTool.notifyCreated, making sure it only calls notifyCreated for workflows without a state in the workflow history. Any objections or better ideas? 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] [dev] .zexp imports and notifyWorkflowCreated
Hi! Tres Seaver wrote: yuppie wrote: Moving the notifyWorkflowCreated call from _finishConstruction to the IObjectAddedEvent subscriber changed the behavior of .zexp imports: The workflow state is now always reset to the initial state. AFAICT that's no useful behavior for imports. This is caused by the fact that the notifyCreated method of WorkflowTool always resets the workflow states. Is that a feature or a bug of notifyCreated? Is anybody using notifyCreated for resetting workflow states? It turned out that CMF itself uses notifyCreated for resetting workflow states :( That's how copy and paste resets the workflow state. Where is the best place to fix this? Should IObjectAddedEvent be triggered on imports? Should the subscriber call notifyWorkflowCreated if the object already has a workflow history? Should notifyWorkflowCreated call WorkflowTool.notifyCreated if the object already has a workflow history? Should WorkflowTool.notifyCreated call notifyCreated of workflows that already have a state? Should notifyCreated of workflows keep existing states untouched? AFAICS the easiest way to fix this is changing WorkflowTool.notifyCreated, making sure it only calls notifyCreated for workflows without a state in the workflow history. +1. This alone will not work. Does it make sense to keep old workflow history records after copy and paste? Or can we just remove the complete workflow_history attribute before notifyCreated is called? If the subscriber for IObjectCopiedEvent removes the workflow_history everything seems to work fine. 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] [Checkins] SVN: Products.CMFCalendar/trunk/setup.py - dependency cleanup
Hi! Jens Vagelpohl wrote: I'm wondering, ist it necessary to declare a dependency where we know that it is a required dependency for another dependency we already declare? Specifically, if CMFDefault is declared as dependency, is it necessary to also declare CMFCore because we know CMFDefault already declares it? No. But as Hanno pointed out yesterday, it is good practice to specify all *direct* dependencies: http://mail.zope.org/pipermail/zope-dev/2009-February/034582.html The Zope2 package is an exception because it represents the Zope 2 platform and ships with a KGS. So direct dependencies on packages Zope2 also depends on should not be specified if Zope2 is specified as dependency. I thought that was consensus, but if you don't agree I'm fine with further discussions. 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] [dev] five.localsitemanager: dependencies
Hi! I have some trouble using five.localsitemanager in a buildout with Zope2 2.12.dev. This is the error I get: Error: There is a version conflict. We already have: zope.location 3.5.3 but Zope2 2.12.dev requires 'zope.location==3.5.2'. The setup.py of five.localsitemanager specifies these dependencies: install_requires=[ 'setuptools', 'zope.component = 3.5.0', 'zope.container', 'zope.event', 'zope.interface', 'zope.location = 3.5.0', 'zope.site = 3.6.0', 'zope.traversing', 'Acquisition', 'Zope2', 'ZODB3', ], If I remove the dependencies that are also part of the Zope2 2.12.dev dependencies everything works fine: install_requires=[ 'setuptools', 'Zope2 = 2.12.dev', ], Is that the right way to resolve that issue? Could it cause any trouble if I would check in that change? 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] Charsets
Charlie Clark wrote: Am 18.01.2009 um 23:00 schrieb yuppie: I agree that there shouldn't be implemented in a different way than for Zope 3. And if we can solve the problems by fixing form encoding I'm happy. Although I'd like to see UTF-8 always the first charset returned if * the quality is the same. zope.publisher.http.HTTPCharsets explicitly prefers utf-8. Are you sure getPreferredCharsets()[0] is iso-8859-1 with your browser? Or do you override somewhere the Content-Type header set by setPageEncoding()? AFAICS CMFDefault works exactly the way you expect it to. 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] Charsets
Dieter Maurer wrote: yuppie wrote at 2009-1-19 11:32 +0100: Charlie Clark wrote: Am 18.01.2009 um 23:00 schrieb yuppie: I agree that there shouldn't be implemented in a different way than for Zope 3. And if we can solve the problems by fixing form encoding I'm happy. Although I'd like to see UTF-8 always the first charset returned if * the quality is the same. zope.publisher.http.HTTPCharsets explicitly prefers utf-8. Are you sure getPreferredCharsets()[0] is iso-8859-1 with your browser? This might be true for the Zope 3 publisher however, Zope 2 HTTPResponse uses default_encoding (configured in zope.conf) unless an encoding is prescribed by the response content type -- and this has nothing to do with the Accept-Charset request header. Products.Five.browser.decode.setPageEncoding sets the response content type charset based on zope.publisher.http.HTTPCharsets. And setPageEncoding is called by the update method of formlib forms in Zope 2. So in this case the response encoding has something to do with the Accept-Charset request header. 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] Charsets
Hi Charlie! Charlie Clark wrote: Am 29.12.2008 um 15:01 schrieb Charlie Clark: CMFDefault.utils def getBrowserCharset(request): Get charset preferred by the browser. envadapter = IUserPreferredCharsets(request) charsets = envadapter.getPreferredCharsets() or ['utf-8'] return charsets[0] This will always be iso-8859-1 for Opera and Firefox because all charsets have the same quality, again even if UTF-8 encoding is specified. getBrowserCharset does almost the same as zope.publisher.http.getCharsetUsingRequest. And it is only used for encoding and decoding 'portal_status_message'. It is not relevant for the issue you noticed. I haven't been able to track where the decoding of form data occurs for Zope 2 stuff but I can identify the problem in zpublisher.browser.BrowserRequest You mean zope.publisher.browser.BrowserRequest. The Zope 2 version is in Products.Five.browser.decode. def _decode(self, text): Try to decode the text using one of the available charsets. if self.charsets is None: envadapter = IUserPreferredCharsets(self) self.charsets = envadapter.getPreferredCharsets() or ['utf-8'] for charset in self.charsets: try: text = unicode(text, charset) break except UnicodeError: pass return text Here the naive assumption is that we decode from a charset without an error then we have the correct charset. Sometimes this goes unnoticed but with characters like u2013 and u2014 (en-dash and em-dash) it will raise errors as those codepoints are not in the Latin-1 charset but it has it's own equivalents. AFAICS the fallback to other charsets is usually not required in Zope 3. If the publisher encodes responses using zope.publisher.http.getCharsetUsingRequest, the first charset will be the right one. I would suggest that we work towards enforcing UTF-8 in where possible but at the very least add the accept-charset attribute to forms and use the portal's default_charset for this. I'd very much appreciate your comments on this. I can't see a need to implement this in a different way than Zope 3. So I propose to fix the encoding of forms sent to the browser. 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] GenericSetup 1.5
yuppie wrote: Right now the versions are mostly ignored if a checker exist. I'd like to evaluate the versions first and use the checker as an additional restriction. Also, running a step with checker should not update the current version of the profile. These changes would allow to split upgrades between versions into several task centric steps. That gives users more control over the upgrade process, doing upgrades step by step or skipping specific steps. If people agree that this doesn't require a proposal and discussion first, I could try to implement this in time for your release. This is now implemented. I hope I didn't break anything. There were no tests and same behavior didn't look right. CMFDefault now uses the 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] CMF add views and browser:page /
Hi! Martin Aspeli wrote: Providing customized solutions for specific use cases makes it easier to solve these use cases, but it also makes the framework more complex and less framework-ish. Then why do we have browser:page /? I guess primarily for historical reasons. And because zope.app is in some parts an application, not a framework. And because the 'template' attribute is sometimes a convenient shortcut. You could of course do: adapter for=.interfaces.IMyType Products.CMFDefault.interfaces.ICMFDefaultLayer provides=zope.interface.Interface name=myview factory=.myview.MyView / class class=.myview.MyView require permission=zope2.View allowed_interface=zope.publisher.interfaces.browser.IBrowserPage / /class The class/ hack is not necessary in Zope 3. This is much closer to browser:page/ and easier to read: adapter for=.interfaces.IMyType Products.CMFDefault.interfaces.ICMFDefaultLayer provides=zope.publisher.interfaces.browser.IBrowserPage name=myview factory=.myview.MyView permission=zope2.View / 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] CMF add views and browser:page /
Lennart Regebro wrote: On Tue, Dec 9, 2008 at 14:31, Martin Aspeli optilude-hi6y0cq0...@public.gmane.org wrote: I'd wager this is a lot closer to what people would expect: cmf:addview for=Products.CMFCore.interfaces.IFolderish fti=..interfaces.IDexterityFTI class=.add.DefaultAddView permission=cmf.AddPortalContent / Yes, although I'd probably call it addform. There is a browser:addform in Zope3, right? 'browser:addform' and 'browser:editform' automatically generate forms based on a schema. The no longer supported 'browser:addview' directive was much closer to the directive Martin proposes. Since this registers an adapter that provides IBrowserPage, 'cmf:addpage' might be an alternative. 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] CMF add views and browser:page /
Hi! Martin Aspeli wrote: Martin Aspeli wrote: Mmmm... I'm not sure most people would find it natural to think about the add form as an adapter like this. Well. I find it natural to think about browser pages as a special kind of adapters. Having explained this to a lot of different people with different levels of experience, I think natural is too strong a word for most people. The fact that browser views are adapters is an implementation detail that often give people an aha! type reaction when they really understand it. However, a lot of people will use browser views for a long time without really understanding adapters (if they ever do or care). Well. I guess it depends on your perspective. For Plone users adapters might be implementation details, for others they are important tools for solving many different problems. I can't see a fundamental problem in using the generic adapter directive for registering browser pages. I just see limited support for the adapter directive in Zope 2. As long as these issues are not resolved, I can live with Zope 2 security declarations in add views. FWIW, I think this'll work: adapter for=Products.CMFCore.interfaces.IFolderish zope.publisher.interfaces.browser.IBrowserRequest ..interfaces.IDexterityFTI provides=zope.publisher.interfaces.browser.IBrowserView factory=.add.DefaultAddView / class class=.add.DefaultAddView require permission=cmf.AddPortalContent interface=zope.publisher.interfaces.browser.IBrowserView AFAICS this should be IBrowserPage or IPageForm, not IBrowserView. / /class I don't much like it, though. :-/ I like it ;) This is not perfect. But better than using oldstyle Zope 2 security declarations. I'll change my checkins. Meh - of course, I meant: cmf:addview name=my.type for=Products.CMFCore.interfaces.IFolderish fti=..interfaces.IDexterityFTI class=.add.DefaultAddView permission=cmf.AddPortalContent / Providing customized solutions for specific use cases makes it easier to solve these use cases, but it also makes the framework more complex and less framework-ish. I can't see a need for the directive you propose. But if you also volunteer to maintain the additional code in the long run, I can live with it. 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] GenericSetup 1.5
Hi! Tres Seaver wrote: I would like to get a 1.5 release of GenericSetup out over the holidays. Here is what I have on the roadmap: - Clean up the sphinx docs for the package, incorporating / updating Rob Miller's excellent tutorial on GS (Rob has already blessed the notion). Great! But why didn't you remove handlers.txt and profiles.txt in GenericSetup/doc? AFAICS they are now redundant and outdated. - Make *much* clearer the idea that content export / import should not be treated as part of any normal profile, including adding some extra support for doing that task at the application level. - Tidy up any deprecations when running under Python 2.5 (and maybe even 2.6). +1 Anyone have other stuff they would like to see in the mix (and can help land)? I recently started using UpgradeSteps and would like to improve the Upgrades tab. Especially I'd like to implement useful behavior for steps that have source/destination versions *and* a checker specified. Right now the versions are mostly ignored if a checker exist. I'd like to evaluate the versions first and use the checker as an additional restriction. Also, running a step with checker should not update the current version of the profile. These changes would allow to split upgrades between versions into several task centric steps. That gives users more control over the upgrade process, doing upgrades step by step or skipping specific steps. If people agree that this doesn't require a proposal and discussion first, I could try to implement this in time for your release. 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] CMF add views and browser:page /
Hi Martin! Martin Aspeli wrote: yuppie wrote: How about a new cmf:addview / directive that mimics browser:page /, but registers the (context,request,fti) adapter? I could probably put that together if people think it's a good idea. CMF add views are different because they are looked up by a special traverser, using the additional type info object. You have to be aware of that. No matter if you use adapter / or cmf:addview /. Sure. It is not obvious why you have to use explicit Zope 2 style security for add views and declarative Zope 3 style security for other views. But I'd rather like to see the 'permission' attribute of adapter / implemented for Zope 2 instead of a new cmf:addview / directive. Mmmm... I'm not sure most people would find it natural to think about the add form as an adapter like this. Well. I find it natural to think about browser pages as a special kind of adapters. And since add forms don't fulfill all the special criteria for browser:page /, we have to fall back to the more generic adapter /. Also, Five's browser:page / does quite a lot of stuff that we now can't have for CMF add views: o It allows a template to be registered o It allows an attribute other than __call__ to be used to render the view o It sets up security on attributes, by interface or explicit list o It sets up security on the view class itself Sure. The question is: Do we really need these features for add views? I don't think the adapter permission attribute would be sufficient in any case. In Zope 3, it's tied to a type of low-level security proxy that doesn't really exist in Zope 2. The ClassSecurityInfo stuff only affects restricted python/traversal, whereas Zope 3 security proxies are applied everywhere. AFAICS I didn't register the add views correctly. Provided interface should be IBrowserPage or IPageForm, not IBrowserView. Given that, in the Zope 3 world adapter /'s 'permission' attribute and browser:page /'s 'permission' attribute would do the same: Creating a security checker that protects 'browserDefault', '__call__' and 'publishTraverse' by the specified permission. Or am I missing something? Currently this is not true for Zope 2. While Five implements Zope 2 specific behavior for browser:page /'s 'permission' attribute, the same attribute of adapter / is useless in Zope 2. I can't see a fundamental problem in using the generic adapter directive for registering browser pages. I just see limited support for the adapter directive in Zope 2. As long as these issues are not resolved, I can live with Zope 2 security declarations in add views. 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] Customising types with add views
Martin Aspeli wrote: yuppie wrote: Martin Aspeli wrote: [...] Let's consider a type Alpha that has a custom add form registered as such a (context, request, fti) adapter with name Alpha. fti.factory is Alpha, and there's a corresponding IFactory utility (with name Alpha). Now, let's say I want to create a new type Beta (e.g. by copying the FTI object TTW), based on Alpha. I want this to use Alpha's add form, but construct objects with portal_type Beta. Is this possible? If I set Beta's fti.factory to be something other than Alpha, then it won't find the add view, but if fti.factory is Alpha then the objects constructed will use Alpha's factory. You should be able to register the same add view twice. One registration for the name Alpha and one for the name Beta. Sure. I was thinking more about the case of customising by copying the FTI TTW. I can't quite decide whether this is a problem in real life or not, although it does seem a bit strange that the add view adapter name and the factory utility name have to be the same. Would it make sense to decouple these, e.g. with a new add_view_name property? If people really have that problem we can decouple this later. For now I can't see a need. I suspect it's YAGNI since the add view calls _setPortalTypeName() on the newly created instance as well, so the resulting object will have type Beta, not type Alpha. Oops! I just realized that I didn't read your example correctly. I thought you would *want* to set Beta's fti.factory to something different. As you noticed, using the same factory *and* add view for different portal types is supported. In fact that's the reason why we adapt the type info and can't use normal browser pages. 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] CMF add views and browser:page /
Hi Martin! Martin Aspeli wrote: [...] In CMFDefault, we have some base classes (tied to formlib) and we do manual security with a ClassSecurityInfo and InitializeClass(). This feels like a step backwards to me, at least in Plone, where we encourage people to use browser views with declarative (ZCML) security. It's difficult to explain that add forms are special so that they need to have manual security, explicit docstrings (for better or for worse), and be registered as an adapter /, not a browser:page /. Did we envisage a solution to this? No. How about a new cmf:addview / directive that mimics browser:page /, but registers the (context,request,fti) adapter? I could probably put that together if people think it's a good idea. CMF add views are different because they are looked up by a special traverser, using the additional type info object. You have to be aware of that. No matter if you use adapter / or cmf:addview /. It is not obvious why you have to use explicit Zope 2 style security for add views and declarative Zope 3 style security for other views. But I'd rather like to see the 'permission' attribute of adapter / implemented for Zope 2 instead of a new cmf:addview / directive. 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] Customising types with add views
Hi Martin! Martin Aspeli wrote: [...] Let's consider a type Alpha that has a custom add form registered as such a (context, request, fti) adapter with name Alpha. fti.factory is Alpha, and there's a corresponding IFactory utility (with name Alpha). Now, let's say I want to create a new type Beta (e.g. by copying the FTI object TTW), based on Alpha. I want this to use Alpha's add form, but construct objects with portal_type Beta. Is this possible? If I set Beta's fti.factory to be something other than Alpha, then it won't find the add view, but if fti.factory is Alpha then the objects constructed will use Alpha's factory. You should be able to register the same add view twice. One registration for the name Alpha and one for the name Beta. I can't quite decide whether this is a problem in real life or not, although it does seem a bit strange that the add view adapter name and the factory utility name have to be the same. Would it make sense to decouple these, e.g. with a new add_view_name property? If people really have that problem we can decouple this later. For now I can't see a need. 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] adding 'context' as an alias for 'object' in action expressions
Hi! Laurence Rowe wrote: yuppie wrote: David Glick wrote: Does anyone have an objection to me adding 'context' as an alias for 'object' in the expression context that is built when executing CMF action expressions (in getExprContext in CMFCore/Expression.py)? This would remove one common source of minor confusion for beginning CMF/Plone developers (namely, having to use object in action expressions when you use context everywhere else). -1 There should be one-- and preferably only one --obvious way to do it. 'context' is deprecated for this kind of expressions, CMF uses 'object' everywhere. Supporting 'object' *and* 'context' or switching from 'object' to 'context' will cause even more confusion. Please see this thread http://mail.zope.org/pipermail/zope-cmf/2005-March/021990.html with this result http://mail.zope.org/pipermail/zope-cmf/2005-March/021999.html That thread refers to 'content' rather than 'context'. The links to the thread were not meant as a contribution to the discussion if 'context' is better than 'object'. My point is that this was discussed before and that using 'object' was an explicit decision. (And 'context' was also considered: http://mail.zope.org/pipermail/zope-cmf/2005-March/021957.html ) Page templates have already made 'context' available as an alternative to 'here'. I don't see why 'object' should be treated any differently. There should be one-- and preferably only one --obvious way to do it. The proposal was to *add* an alias. That means two ways to do it. It makes the chance higher that you guess the right name, but it doesn't make things more obvious. And the proposal was to change the expression context for actions. What about CachingPolicyManager and DCWorkflow? 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] adding 'context' as an alias for 'object' in action expressions
David Glick wrote: Does anyone have an objection to me adding 'context' as an alias for 'object' in the expression context that is built when executing CMF action expressions (in getExprContext in CMFCore/Expression.py)? This would remove one common source of minor confusion for beginning CMF/Plone developers (namely, having to use object in action expressions when you use context everywhere else). -1 There should be one-- and preferably only one --obvious way to do it. 'context' is deprecated for this kind of expressions, CMF uses 'object' everywhere. Supporting 'object' *and* 'context' or switching from 'object' to 'context' will cause even more confusion. Please see this thread http://mail.zope.org/pipermail/zope-cmf/2005-March/021990.html with this result http://mail.zope.org/pipermail/zope-cmf/2005-March/021999.html 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] [dev] Should portal_setup be registered as utility?
Dieter Maurer wrote: yuppie wrote at 2008-11-18 12:00 +0100: Dieter Maurer wrote: If they would, local utilities were much nearer to tools and the transition would be facilitated. They would be nearer to tools, but also more distant from zope 3 utilities. I doubt that would really be a win. Then, maybe, Zope 3 utilities are inadequate at many places in to Zope 2 world: e.g. any tool that uses TALES expressions may want to access the (current, of course) request -- especially when they are destined for user interaction (as actions are). I agree. Utilities are inadequate for user interaction. Views should be used instead. We don't need the request for managing TALES expressions inside an utility. The request is only needed if we *use* the expressions, and that should be done in view code, not in utilities. Several tool methods have to be replaced by view code before we can register all tools as utilities. In view of this, one can understand that Plone has problems with the setup_tool utility registration. The setup tool is responsible for managing configuration data. I can't see a need to care about the request in that context. 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] [dev] Should portal_setup be registered as utility?
Hi! CMFDefault registers portal_setup as utility. Some code in CMF depends on that. Plone doesn't doesn't register portal_setup as utility: http://dev.plone.org/plone/changeset/18763 That causes some trouble in Plone: http://dev.plone.org/plone/ticket/7714 The same issue was reported as CMF bug: https://bugs.launchpad.net/zope-cmf/+bug/263525 Due to a misunderstanding the CMF bug was marked as 'Won't Fix'. Questions: Is there a good reason why Plone doesn't register portal_setup as utility? Does the same reason apply to CMFDefault? Do we have to support registered and not registered portal_setup tools? 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] [dev] five.localsitemanager: site manager names
Hi! Trying to clean up site creation in CMF, I noticed this issue: zope.app.component uses a hardcoded '++etc++site' as name, but five.localsitemanager's make_site function computes it like this: name = 'five' path = getattr(obj, 'getPhysicalPath', None) if path is not None and callable(path): name = '/'.join(path()) So the name is location dependent. Moving the site would require updating the name, but there is no event handler that does it. I see 2 possible ways to fix this: 1.) Add an event handler that updates the name. 2.) Use the same hardcoded name as Zope 3. A customized __repr__ method could still show the complete path, at least as long as the active site is set accordingly. Any thoughts? I prefer solution 2. 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] Missing Event Handler for CMFCatalogAware
Charlie Clark wrote: Am 11.11.2008 um 16:52 schrieb yuppie: AFAICT PortalFolder inherits from CMFCatalogAware to make sure it has the same manage_afterAdd, manage_afterClone and manage_beforeDelete methods as other content classes. But these methods are gone, so I guess the dependency is no longer needed. You didn't hear it from me but this is surely abuse of inheritance? Time to call the cops and stand outside our houses in dressing gowns and slippers tutting and looking superior! This is the checkin that added CMFCatalogAware to PortalFolder: http://svn.zope.org/?rev=35114view=rev It explains why and how it was done. Maybe a first step to clean this up would be to split CMFCatalogAware into separate mixins. 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] Missing Event Handler for CMFCatalogAware
Hi Charlie! Charlie Clark wrote: Digging around I've realised that this is because I have folderish objects which inherit from PortalFolder which explicitly deactivates the ICMFCatalogAware methods. Is there any point in implementing ICMFCatalogAware or IWorkflowAware for Folders? What would we break if we removed the dependency? AFAICT PortalFolder inherits from CMFCatalogAware to make sure it has the same manage_afterAdd, manage_afterClone and manage_beforeDelete methods as other content classes. But these methods are gone, so I guess the dependency is no longer needed. There might be some code that expects that *all* content classes implement ICatalogAware, IWorkflowAware and IOpaqueItemManager, but if we add deprecation warnings the other code can be cleaned up. In the long run I'd like to get rid of CMFCatalogAware completely. Its functionality should be moved to adapters and event subscribers. 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] [dev] 'add' actions and views - a proposal
Hi! Martin Aspeli wrote: yuppie wrote: Martin Aspeli wrote: Wichert Akkerman wrote: Why not a ++add++ traverser? Aren't traversed supposed to be used for that kind of thing? Or does a view gives us something here that a traverser doesn't? Namespace traversal adapters are similar to IPublishTraverse solutions. The difference is that the namespace traversal adapter normally returns something containerish from which traversal continues. I think it's intended mostly as a redirect to a different traversal namespace, e.g. in the way that plone.app.portlets has namespaces for portlet managers. I don't think a containerish return value is characteristic for namespace adapters. For example the ++view++ traverser usually doesn't return something containerish. I now implemented an ++add++ traverser in my sandbox and it seems to work fine. Cool. :) Let us know when it's checked in, I'd love to have a look at it! Ok. I checked in all my local changes. AFAICS everything works fine, but tests are still missing. Please note that so far only File has a full add view. All other content types use the fallback add view. I still use the pattern that adapts ITypeInformation as well. Our add views are anyway Zope 2 specific, so I don't think requiring explicit Zope 2 security declarations is unacceptable. All other solutions have also their drawbacks. 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] [dev] 'add' actions and views - a proposal
Hi Martin! Martin Aspeli wrote: yuppie wrote: Proposed CMFDefault changes --- 1.) CMF add views adapt not only container and request, but also the type info object. This way the views can't be accessed directly and have self.fti available. This is quite interesting, and possibly necessary. However, it means that CMF add views are not just views and will need to be registered differently to other views (i.e. you can't just use browser:page / which also means that you won't get the Five security treatment etc). Yes. This causes more problems than it solves. I think I found a much better solution: CMF add views are registered for a special layer called IAddViewLayer. Like any other layer, IAddViewLayer extends IBrowserRequest. And it defines an additional 'ti' attribute for the request. Like before views can't be accessed directly and have self.ti available. (I now use 'ti' instead of 'fti' because we have other type info implementations than FactoryTypeInformation.) 3.) A traversal hook looks up the type info based on the view name. And then returns the corresponding add form: queryMultiAdapter((container, request, fti), name=fti.factory) Why do we need to *both* adapt the FTI and use the factory name as the view name? Because we want to use different views for different content factories *and* pass the type info to the view. This way we don't depend on an environment that sets the ti value later. And all view methods work from the beginning without fallback code for a missing ti. As mentioned above, I now propose to pass in the type info as part of the request object. 6.) An IPublishTraverse adapter is used for IFolderish objects. It tries to resolve names starting with '+' and falls back to DefaultPublishTraverse behavior if no add view is found. This way URLs like http://www.example.org/folder/+PortalType are supported. -1 Or maybe -10 now that I think about it a bit more... I also started with -1, but thinking a bit more about it my vote is +1. This is pretty invasive. It'd make it impossible to have another IPublishTraverse adapter for any IFolderish without either subclassing from the CMFDefault one or breaking all add forms. Shrug. That is how the IPublishTraverse adapter works. There are many use cases for the IPublishTraverse hook and only one available slot. You never can be sure that this hook is free. If you write your own IPublishTraverse adapter, you always have to look at the code base and subclass those adapters you want to use. Rather than invent a pseudo namespace with a naming convention, why not use a proper namespace, i.e. http://www.example.org/folder/@@add/PortalType ? What's the difference between a 'pseudo' namespace and a proper namespace? The 'add' view you propose is a 'pseudo' view. It just exists to be bypassed, not to be returned. This is short, simple and allows alternative implementations if people want to use a different name (e.g. the @@add-deterity-content traverser in Dexterity), and does not require a clunky traverser for all IFolderish. Instead, you register the @@add view for IFolderish and have it implement IPublishTraverse as well. We have a trade-off here: clunky traverser vs. clunky URL. I don't want to have names like '@@add-dexterity-content', '@@add-cmf-content' or '@@resize-plone-image' in my URLs. '@@add' looks a bit more generic, but it isn't. '+PortalType' works with any add view implementation. If you hardcode the portal type, you can register the add view directly for the default skin. If you want to use the CMF traversal or dexterity traversal, you can still support the same URL. Following your proposal, we have '@@addPortalType' for simple add views, '@@add/PortalType' for CMF traversal and '@@add-dexterity-content/PortalType' for dexterity traversal. I don't think that's what IPublishTraverse is made for. Are the IBaseObject traversers used by Archetypes and plone.app.imaging also 'bad'? Or what's the big difference to the adapter I propose? Proposed CMFCore TypesTool changes -- 7.) listActions of the types tool returns add actions for *all* portal types. +1 - this change is already done, right? Yes. Checked in yesterday. 8.) If no add view expression is defined in the type info, a default add view URL is returned. -0 Would it not be better to push this logic higher up, i.e. in the view code that's actually using the add views? Can't follow you here. How should that work? The default for CMFCore is probably not going to be a suitable fallback for Plone, for example, which means we either need to customise/override or ensure that all types always have such an add action. With a default value CMFDefault needs no migration code and copying type infos is easier. But I agree that it might be useful to make it customizable. Maybe we should use a types tool property
Re: [Zope-CMF] [dev] 'add' actions and views - a proposal
Wichert Akkerman wrote: Previously Martin Aspeli wrote: I don't feel particularly strongly either way, so long as there's an actual namespace rather than a naming convention and we avoid an IPublishTraverse adapter for all IFolderish. ++add++PortalType is a bit uglier than /@@add/PortalType IMHO, but it's a transient URL so it doesn't really matter. It makes it more explicit that there is no real @@add 'thing' that is traversed over. I think it's worth finding out why we have +/IAdding being a view and not a namespace traversal adapter, though. It feels that things like ++skin++ or ++vh++ are a bit different to ++add++, though perhaps not. The + naming for IAdding has always been a mystery to me. It feels very out of place considering that it is just about traversing into a add-view namespace. In Zope 3 '+' *is* a real page with content. Maybe that's the reason? Anyway. I like the idea to use a traverser. It's more explicit and if you want different URLs you can hide them behind aliases. 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] [dev] 'add' actions and views - a proposal
Hi! Thanks for all the feedback to my previous mails. I hope I now have a good solution. Context --- Portal types are created TTW by configuring the types tool. If portal types are renamed or copied they still use the same content type and content factory. It should be possible to use the same add view as well. This makes CMF add views special: They have to work with different portal types. That means: - If we want simple URLs, we have to store the portal type name inside the add view name. - We need customized traversal to look up the right view for each portal type and to pass the portal type to the view. Proposed CMFDefault changes --- 1.) CMF add views adapt not only container and request, but also the type info object. This way the views can't be accessed directly and have self.fti available. 2.) By convention corresponding add view factories and content factories have the same name. 3.) A traversal hook looks up the type info based on the view name. And then returns the corresponding add form: queryMultiAdapter((container, request, fti), name=fti.factory) 4.) For portal types without corresponding add form a fallback add form is added that just asks for the content ID. 5.) folder_factories becomes deprecated, add actions are shown in the main_template menu. 6.) An IPublishTraverse adapter is used for IFolderish objects. It tries to resolve names starting with '+' and falls back to DefaultPublishTraverse behavior if no add view is found. This way URLs like http://www.example.org/folder/+PortalType are supported. Proposed CMFCore TypesTool changes -- 7.) listActions of the types tool returns add actions for *all* portal types. 8.) If no add view expression is defined in the type info, a default add view URL is returned. If there are no objections, I'll make the proposed changes on the trunk. @ Jens: When exactly do you want to make the beta release? 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] CMFActionIcons vs. new-style actions
Hi Jens!
Jens Vagelpohl wrote:
This has now landed, in several chunks because it turned out to be
more work and a larger change set than expected, on the CMF trunk.
Silly me thinking most of my work was done when Yuppie thoughtfully
added a icon URL expression property to the new-style actions ;-)
Sorry about that. The original plan was to get rid of old-style actions
completely, but I never finished that task.
Additional work included...
- extend the old-style actions, those you see e.g. on a type
information Actions tab in the ZMI, to also have a field for an icon
URL expression
That might have been the most pragmatic solution, but in the long run we
should not maintain two different Action machineries.
I personally prefer to move all type info Actions to the actions tool. I
can't see a need to specify separate 'view', 'edit' or 'metadata'
Actions for each content type. That just makes it necessary to maintain
a lot of redundant configuration data. In how many places did you have
to set string:${portal_url}/edit_icon.png?
Some Actions like 'download' should only be available for specific
portal types. That makes things a bit more complicated, but can be solved.
If people really want to maintain separate Actions for each type, we
should consider to make type infos containers for new-style Actions.
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] CMFActionIcons vs. new-style actions
Hi Martin!
Martin Aspeli wrote:
yuppie-4 wrote:
Wichert Akkerman wrote:
Previously yuppie wrote:
I personally prefer to move all type info Actions to the actions tool. I
can't see a need to specify separate 'view', 'edit' or 'metadata'
Actions for each content type. That just makes it necessary to maintain
a lot of redundant configuration data. In how many places did you have
to set string:${portal_url}/edit_icon.png?
Per-type edit and view actions are a very important customization point.
We should not make it harder for people to do that. Per-type actions are
very common in Plone, I'ld hate to loose them.
Can you point me to some examples? Looking at the default CMFPlone
profile I couldn't find any. Repeated definitions for 'view', 'edit',
'download', 'external_edit', 'history' or 'references' Actions look
quite redundant to me.
I would be extremely uncomfortable with losing the ability to do:
- Per-type definition of *which* actions are shown in a given category
Sure.
- Per-type definition of *what* those actions go to
As you mention below, method aliases can be used for that.
I think there's a case for saying that there's always a 'view' and an 'edit'
action that go to /view and /edit and you use method aliases to point them
at different templates. However, we need the ability to change permissions,
TALES conditions, labels and so on per-type.
How often do you need that ability? Can we make that a bit harder if we
can get other benefits in return?
Reducing repetition would be good, of course. We certainly have conventions
that apply to most (but not all) types. If there was a way to make per-type
actions optional as overrides/additional items (including the ability to
turn off an action inherited from globals) that may be good.
The solution I have in mind is maintaining a simple set of Action IDs
inside a type info property. All Actions are stored in one place, but
availability is looked up in the type infos.
If you need a different edit action, you create a new one with a new ID.
And add its ID to the type infos that should use it.
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] [dev] add view traversal
Hi! This mail has been lying around for a while because I'm not sure it's the right way to start the discussion. But now I'll give it a try. Maybe the sprinters find some time to discuss this: One result of the Add forms and menus[1] thread was that we'd like to get add views by portal type name. Some custom traversal should look up and return the right view for the specified portal type. I'm currently trying to figure out how to implement that correctly and am struggling with some details: 1.) What should URLs look like? --- Here are same possible URLs for adding a Message to a guest book: http://www.example.org/guestbook/+Message http://www.example.org/guestbook/@@+Message http://www.example.org/guestbook/addMessage.html http://www.example.org/guestbook/+/Message http://www.example.org/guestbook/@@+/Message http://www.example.org/guestbook/+/addMessage.html http://www.example.org/guestbook/+cmf/Message http://www.example.org/guestbook/@@+cmf/Message http://www.example.org/guestbook/+cmf/addMessage.html http://www.example.org/guestbook/add/Message http://www.example.org/guestbook/@@add/Message http://www.example.org/guestbook/add/addMessage.html 2.) Which hook should be used for custom traversal? --- a) for URLs like http://www.example.org/guestbook/+Message In this case we use a special prefix '+' followed by the portal type name. CMF containers don't implement IPublishTraverse, so we can register an IPublishTraverse adapter. If we don't find an add view, we can fall back to DefaultPublishTraverse behavior. Unfortunately the IPublishTraverse hook only works with one adapter. If other packages like plone.app.imaging[2] try to use the same hook, we get a problem. b) for URLs like http://www.example.org/guestbook/+/Message The '+' view already implements IPublishTraverse, so we can't change traversal using an adapter. The only solution I can see is to replace the '+' view by a customized version. c) for URLs like http://www.example.org/guestbook/add/Message If we use our own adding view, we can implement IPublishTraverse inside the view or as adapter. 3.) For which context should we register the add views? --- The add views will depend on special portal type handling done by the traverser. So we register the add views for traverser? Or should all views have a default portal type that is used if we access add views directly? In that case we would register the add view for the container. plone.dexterity[3] uses an @@add-dexterity-content traverser, but I don't think product names like dexterity or cmf should be visible in URLs. Those are implementation details that should be transparent for users. Any feedback is welcome. Cheers, Yuppie [1] http://mail.zope.org/pipermail/zope-cmf/2008-July/027500.html [2] http://dev.plone.org/plone/browser/plone.app.imaging/trunk/plone/app/imaging/traverse.py [3] http://dev.plone.org/plone/browser/plone.dexterity/trunk/plone/dexterity/browser/add.py ___ 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] Formlib based view of folder contents
Charlie Clark wrote: currently sitting with Tres and Jens in Saarbrücken working on a formlib based view of folder_contents and we're hitting some stuff that's been around for ages but might possibly no longer be required. An example of this is the Contents View Filter. Does anybody actually use this? I never used it. But one major function of CMFDefault is to showcase CMF features. And I'm not aware of any other code that demonstrates how to use filtering. If so is it okay to drop the use of the cookie and either use hidden variables as the sorting options do already or possibly dump this information in the session? One of the problems with the current implementation is that the cookie is hard-coded to live until 2020 and will persist from one folder to the next but it's debatable whether the filters you want for one folder you would want for another but not the sort options. Our preference would be to put the filter information in hidden variables. I don't think CMFDefault should rely on sessions. Using hidden variables sounds fine to me. 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] [dev] more add menu changes
Charlie Clark wrote:
Am 07.08.2008 um 12:26 schrieb yuppie:
Proposal 2: main_template
-
CMFDefault menus are implemented in main_template. I propose to add
a new section for 'folder/add' actions.
Hi yuppie,
finally had a bit of time to look at this. First of all thank you very
much for your work on this. It's a great pity your not here at the
DZUG conference to discuss.
I have an extremely basic implementation of this for the CMF:
from Products.CMFCore.utils import getToolByName
tt = getToolByName(context, 'portal_types')
ti = tt.getTypeInfo(context)
poss_types = ti.allowed_content_types
add_forms = []
for t in poss_types:
# get type info for child
nti = tt.getTypeInfo(t)
if nti.add_view_expr != '':
url = nti.add_view_expr_object
add_forms.append({'title':nti.title, 'url':url(context)})
return add_forms
I doubt that works: 'context' and expression context are not the same.
I can't think of any other way to do this other than to call this
expression before returning it to the template. But it's more than
possible I've overlooked something.
Why do you want to bypass the actions machinery?
Something like that should work in main_template:
tal:define=add_forms python: actions.get('folder/add', {});
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] CMF 2.2.0 beta
Hi Jens! Jens Vagelpohl wrote: Is there anything to hold back a CMF 2.2.0 beta at this point? I'd like to finish the add menu changes first. My last proposal[1] is not implemented because Martin convinced me to choose an other solution[2]. Next week I'll have time to write and implement a new proposal. It also would be nice if someone could 'merge' the DEPENDENCIES.txt files into the setup.py files. [3] Cheers, Yuppie [1] http://mail.zope.org/pipermail/zope-cmf/2008-August/027607.html [2] http://mail.zope.org/pipermail/zope-cmf/2008-August/027612.html [3] http://mail.zope.org/pipermail/zope-cmf/2008-April/027282.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] CMF 2.2.0 beta
Jens Vagelpohl wrote: On Sep 12, 2008, at 10:58 , yuppie wrote: It also would be nice if someone could 'merge' the DEPENDENCIES.txt files into the setup.py files. [3] I alread did that two weeks ago. Great. But if all the information is now in setup.py, why didn't you remove the DEPENDENCIES.txt files? 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] [dev] more add menu changes
Hi! We now have to support two ways to add content: 1.) oldstyle (no add view specified) The addable types are listed in folder_factories. After specifying type and ID the object is added. constructContent redirects to the immediate view. 2.) newstyle (add view is specified) The addable types are listed as actions. These actions should show up in a menu. The add action points to a type specific add form. After completion of the form the object is added. The add form redirects to the immediate view. Some parts are still missing: - add a traverser that allows to use pretty URLs and better portal type handling for add views (not part of this proposal) - don't show newstyle types in folder_factories - show add actions in the CMFDefault skin Proposal 1: allowedContentTypes --- This PortalFolder method is used by folder_factories and by folder_contents to decide if the 'New...' button is added. I propose to add a new skip_add_views argument to allowedContentTypes. If true, newstyle types are skipped. Proposal 2: main_template - CMFDefault menus are implemented in main_template. I propose to add a new section for 'folder/add' actions. If there are no objections I'll make these changes on trunk. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] more add menu changes
Hi Martin! Martin Aspeli wrote: yuppie-4 wrote: Some parts are still missing: - add a traverser that allows to use pretty URLs and better portal type handling for add views (not part of this proposal) - don't show newstyle types in folder_factories - show add actions in the CMFDefault skin Proposal 1: allowedContentTypes --- This PortalFolder method is used by folder_factories and by folder_contents to decide if the 'New...' button is added. I propose to add a new skip_add_views argument to allowedContentTypes. If true, newstyle types are skipped. Please let this default to False. Sure. I wonder if it's better to have a separate method that does the skipping. allowedContentTypes may be used by other things already. Plone uses it in a few places, for example. :) I have no strong opinion about this. What would be a good name for a separate method? I don't suppose there's a way to make all FTI's expose actions, and just construct an appropriate fallback URL (e.g. createObject or whatever) if no add view has been specified? That'd mean folder_factories could just loop through the actions. Not sure I understand what you propose. folder_factories is a form that allows to specify type and ID. I don't think we should ask for the ID *before* showing the add view. And if we have no add view, we need folder_factories' ID input field. But this might work: If we also implement the traverser, the traverser could return a default add view that just asks for the ID. In that case we could use actions for newstyle and oldstyle types. That solution would change the add procedure for oldstyle types, but maybe that's better than listing newstyle and oldstyle types in two different places. Any opinions? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Locales in CMFDefault
Hi! Maurits van Rees wrote: In CMFDefault there is the locales/cmf_default.pot file but no .po files. Also, there is no domain mentioned in that pot file - it should be 'cmf_default', like at the bottom of utils.py. And the directory is not registered in zcml, though I guess that does not matter since there are no po files. Are any translations available anywhere that I have missed? Not really. There is one .po file attached here: https://bugs.launchpad.net/zope-cmf/+bug/161407 And I have an incomplete German .po file I could contribute. Is there a wish to add po files for CMFDefault in a central place like PloneTranslations where lots of people can contribute? +1 if someone volunteers to 'own' that project Maybe https://translations.launchpad.net/zope-cmf would be a good place? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: discussion behaviour in CMFDefault
Wichert Akkerman wrote: Currently CMFDefault does allow you to see or even retrieve information from an object which does not have discussion allowed. This means that it is not possible to allow discussions for an object and then stop people from adding more comments while still making the existing comments available. Is there a special reason that getDiscussionFor explicitly tests isDiscussionAllowedFor ? AFAICS talkback methods like createReply don't check isDiscussionAllowedFor. So if you make talkback always available you have to check isDiscussionAllowedFor in other places. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] type infos and 'add' actions - a proposal
Hi! Martin Aspeli wrote: - 'url': requires a new type info property, I propose to use 'url_expr' to keep it in sync with normal Action objects I wonder whether addview_url or something similar would be more appropriate, since the url of a type is somewhat ambiguous. Ok. I changed that to 'add_view_expr'. The '_expr' suffix is used to implement special behavior for expressions. So instead of adding separate 'add' actions we can extend the type info classes, making them implement IAction as well. How about making them adaptable to IAction instead of directly implementing it? That sounds cleaner than trying to bend some of the old properties. Don't think so. IAction just adds one method: getInfoData(). The names I mentioned are keys in the data structure returned by that method, not bent properties. My changes are now checked in on the trunk. So far I didn't add a 'portal_type' variable to the expression context because I don't know an easy way to do that. The action machinery expects that all callable attributes of all actions take the same expression context as argument. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] [dev] type infos and 'add' actions - a proposal
Hi! This is a proposal for implementing one part of what we discussed in this thread: http://mail.zope.org/pipermail/zope-cmf/2008-July/027500.html Using add views instead of folder_factories for creating content makes it necessary to provide some kind of menu items for them. In CMF menu items are usually represented by 'actions'. Type infos already define most data required for actions: - 'id': can be reused - 'title': can be reused; if we want action titles like 'Add File ...' instead of 'File' we can change that in the template - 'description': has already the same purpose as in actions - 'icon': 'content_icon' is a path relative to the site root, but we can use the same icon and compute the required absolute path - 'available': can be computed using allowType of the container - 'allowed': can be computed using isConstructionAllowed Missing are these properties: - 'category': can be hardcoded, e.g. as 'folder/add' - 'url': requires a new type info property, I propose to use 'url_expr' to keep it in sync with normal Action objects - 'visible': can be hardcoded as True So instead of adding separate 'add' actions we can extend the type info classes, making them implement IAction as well. listActions of the types tool would include type infos if they provide IAction *and* have an url specified. As always, feedback is welcome. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Add forms and menus
Hi Martin! Martin Aspeli wrote: CMF trunk uses events instead of _finishConstruction. Ah, nice. Do you think it'd be feasible to backport this, i.e. copy the event handler somewhere in Plone so long as Plone's still using an older version of CMF? Or does the new event handler rely on other changes to CMF as well? The changes in handleContentishEvent are simple. The tricky part is to make sure notifyWorkflowCreated and indexObject aren't called twice if the types tool is used for creating content. How did you? Well. First I declared all existing oldstyle factories broken because they send the events at the wrong moment. And second, I ripped out _finishConstruction. I hope that's acceptable for a new feature release, but nothing I would introduce on a maintenance branch. See http://svn.zope.org/?view=revrev=82763 and http://svn.zope.org/?view=revrev=85506 for details. If you want to backport this to CMF 2.1, I'd try to register the new handler for an interface that's only used by your new content classes. If you don't touch the types tool, you also have to make sure that your new content is never created by the types tool. If we don't want to use a convention, we need a new property. And if we want to be flexible enough to add the portal type name to the query, a TALES expression for the URL wouldn't be overkill. So, a single new property that contains TALES? Called 'addview'? Let's first see how we decide on Robert's proposal. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Add forms and menus
Robert Niederreiter wrote: Your proposal has some advantages. On the other hand this requires to create CMF specific code and patterns in a place where a more generic solution also works. it does not if you call a formfactory inside the traverser, so it's hoohable for CMF, Plone or whatever even with different formlib implementations. like: formfactory = getAdapter(context, IFormFactory, name='factoryNameFromFti') return factory() which handles all the magic in there. just a thought. Writing generic code is just the first step. Pushing this down the stack and making it the default pattern for Zope is much harder. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMFCore.exportimport.properties import encoding
Hi Ricardo!
Ricardo Alves wrote:
I'm having a problem with encoding of properties.xml, and I'm not sure
if its an issue of CMFCore or Plone. Maybe it's not even an issue, but
here it goes:
If the properties.xml file doesn't include any charset declaration, in
CMFCore.exportimport.properties, _importNode relies on
default-zpublisher-encoding (defined at zope.conf) and not in the
context/site charset, like _exportNode does.
So, if we have default-zpublisher-encoding set to 'iso-8859-1' and the
site charset is 'utf-8', property values will be stored encoded as
'iso-8859-1'.
One possible fix, would be to get the context encoding in _importNode,
just like _exportNode:
...
def _importNode(self, node):
Import the object from the DOM node.
+self._encoding = self.context.getProperty('default_charset',
'utf-8')
for child in node.childNodes:
...
I agree that _importNode() should fall back to this encoding if
default_charset is not specified in the import.
Please report the bug to https://bugs.launchpad.net/zope-cmf/ .
But there is another problem: even then, it wouldn't work for Plone. The
'default_charset' property is only available at
portal.portal_properties.site_properties, so
context.getProperty('default_charset') will fail. But, I guess, this is
a Plone problem...
Yes. This is a Plone issue.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Add forms and menus
Hi! Martin Aspeli wrote: Charlie Clark wrote: Am 13.07.2008 um 20:21 schrieb Martin Aspeli: Thus, if CMF hasn't yet picked a form library in a release, then you could try to learn from Plone's mistakes and not jump on a sinking ship. :) CMF 2.1 was released with some formlib based edit forms. I don't think it was a mistake, because at that time z3c.form wasn't available in the Zope 2 world. We're already using zope.formlib in the experimental browser views edit forms. The reference to a sinking ship is totally off-target. My own view is that sometimes it is better to wait for version 2 of a product or library to be released before adoption. Surely Plone has suffered from adopting some stuff too early? *shrug* Do what you please. I'm not particularly wedded to one or the other. But having used both, I'm pretty sure that z3c.form is a better library. In many ways, z3c.form *is* version 2 of formlib. Exactly. z3c.form is a new version of zope.formlib that doesn't care about backwards compatibility. All development is done in z3c.form. Using the picture of a sinking ship: At least the crew has already abandoned the formlib ship. And without crew it will sink sooner or later. It was always a goal of CMF to minimize dependencies. But Zope became less monolithic, so we have to define the Zope dependency ourselves. It's no longer just the Zope 2 distribution, we have to use separately shipped packages like five.localsitemanager as well. And z3c.form is *the* current Zope package for creating forms. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Add forms and menus
Hi Martin! Martin Aspeli wrote: # check preconditions checkObject(container, name, content) I doubt constraints based on __setitem__ and __parent__ work in Zope 2. Well, they do in the sense that if you have them and we have this code, we'll get an exception. They don't work generally, tough, so this may be YAGNI. It was copied from Five's Adding implementation, so I figured it should be kept if someone's relying on it. That's quite hypothetical. If someone figures out how to use this for stuff like the allowType check, it's useful. If not, it is YAGNI. In case of doubt, I prefer to remove code like that and to wait until someone complains. content.id = name container._setObject(name, content) content = container._getOb(name) if fti is not None: fti._finishConstruction(content) CMF trunk uses events instead of _finishConstruction. Ah, nice. Do you think it'd be feasible to backport this, i.e. copy the event handler somewhere in Plone so long as Plone's still using an older version of CMF? Or does the new event handler rely on other changes to CMF as well? The changes in handleContentishEvent are simple. The tricky part is to make sure notifyWorkflowCreated and indexObject aren't called twice if the types tool is used for creating content. BTW: plone.z3cform's AddForm doesn't include a create method, so I can't see your complete create-and-add procedure. You might want to compare your code with the ContentAddFormBase of CMFDefault trunk: http://svn.zope.org/Products.CMFDefault/trunk/Products/CMFDefault/formlib/form.py?rev=86225view=auto We could make this overrideable as well, with another FTI property. I guess I'd rather have a flexible explicit URL than an implicit URL ruled by convention. Agree. So does this mean we want a separate property for the add view name? Should it be a simple string or a TALES thing? Add links are just special 'actions', they should be integrated with CMF's action machinery. Based on the information in the type infos we should be able to create normal IActionInfo objects. (IActionInfo defines the non-persistent wrapper around actions, today we would use adapters to implement this.) If we don't want to use a convention, we need a new property. And if we want to be flexible enough to add the portal type name to the query, a TALES expression for the URL wouldn't be overkill. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Add forms and menus
Daniel Nouri wrote: I just relicensed and moved plone.z3cform to the Zope repository: http://svn.zope.org/plone.z3cform/trunk/ Great! Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Add forms and menus
called add-factory_name and link to that if it's available. The idea is that the factory name is unique and specific to the content type. I sometimes use different factories for one content type, but a 1:1 relationship doesn't seem to be necessary for your proposal. Different portal types that use the same factory would almost by necessity have the same add view. This is the required 1:1 relationship. But if different portal types use the same add view, we have to pass the portal type name to the add view. (addFile currently accepts portal_type as argument to override the default portal type if necessary.) We could make this overrideable as well, with another FTI property. I guess I'd rather have a flexible explicit URL than an implicit URL ruled by convention. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Add forms and menus
Hi Martin! Martin Aspeli wrote: I see that Yuppie has been experimenting with add forms. From what I can tell, he's using a custom formlib base class and registering views as e.g. addFile.html. It also look as if he's registering that view as an action in portal_actions, in the 'folder' category. That's correct. But I have to mention that not all parts of these changes have reached the same stage of maturation. Using 'folder' category Actions is a temporary hack to generate menu items for the new add forms. I'm glad you want to help to find a better solution. Plone currently supports add forms for the IAdding (+) view in a somewhat ugly way (it looks to see if there's a view for IAdding with the same name as the 'factory' set in the FTI of an addable type, and if so, provides a link to it). IAdding can be a bit painful, so we're interested in supporting an approach based on simple views. Good. It's also worth noting that z3c.form (via plone.z3cform, which should be plain CMF compatible, though you may want a different default template) has support for such views in quite a generic way. The CMF version of that looks like this: http://dev.plone.org/plone/browser/plone.z3cform/trunk/plone/z3cform/add.py z3c.form is generally nicer to work with than formlib. Maybe we should discuss this in a different thread. Here a short reply: My code for the AddForm would look quite different, especially for CMF trunk, but in general that's the way to go. Since z3c.form became the standard in the Zope 3 world I'd like to see Zope 2 and CMF moving in the same direction. Unfortunately using plone.z3cform is no option for CMF because it has a different license and repository. *If* Plone wants to donate that code to the Zope Foundation or someone writes something similar (maybe five.z3cform), I'd be happy to help with CMF integration. In any case, I'd like to know why you went down the portal_actions route for rendering the add links. I'm not quite sure I like the idea of having this be persistent configuration, separate to the FTI, as the two would need to be kept in sync, and in sync with the view name registered in ZCML. CMF makes a distinction between portal types and content types. Portal types are persistent wrappers around the non-persistent content types. You can define many different portal types based on one content type. In CMF you add *portal type* instances, so the 'add' links should be persistent as well. The non-persistent add form has to take the portal type name as argument to create the correct portal type. I'm not sure what the right solution is, but I guess extending the type info classes will be the best approach. Also, why not try to use the Zope 3 menu concept? There's even a special add menu directive. Moving away from persistent actions is not on my todo list. And as I tried to explain above, the current portal type concept depends on persistent actions. I'd quite like to find a good approach here that can be used by both Plone and plain CMF, if possible. I hope you find one ;) Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Why do we need types.xml and workflows.xml?
Martin Aspeli wrote: yuppie wrote: I'm not happy with the current file format. But representing containers is a general problem and I want *one* generic solution that works for all use cases. I'm not sure most people think of portal_types as a container per se. Rather, they think I need to register my content type, and for that I need an XML file that describes it. The fact that portal_types is a container for FTI objects is an implementation detail that probably doesn't belong too explicitly in the declarative GenericSetup syntax. For Plone users it might be an implementation detail. But even Plone users should know that importing GS profiles creates persistent objects. Pure CMF doesn't hide the implementation. The configuration data is stored in tools and sub-objects, GS maps them to directories and files. TTW configuration and GS configuration have the same structure, if you are familiar with TTW configuration you know where to find the same settings in a profile. Or the other way round. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Catalog aware folders
Hi! Charlie Clark wrote: just noticed something a bit weird: got my own Folderish object that a minimally customised PortalFolder but it's important that it's in the catalog. Although PortalFolderBase already inherits from CMFCatalogAware I've had to explicitly inherit again from CMFCatalogAware in my class. Yes. The class hierarchy is wired. I'm not sure if it is still necessary to inherit PortalFolderBase from CMFCatalogAware. class PortalFolderBase(DynamicType, CMFCatalogAware, Folder): Base class for portal folder. class PortalFolder(OrderSupport, PortalFolderBase): Implements portal content management, but not UI details. class CatalogFolder(CMFCatalogAware, PortalFolder): Folder that will appear in the catalog I've just checked some of my other sites and folders are not catalogued. Is this a bug? No. By default folders are not content, just structure. SkinnedFolder does what you want. If you use CMF trunk, your code will not be sufficient. handleContentishEvent is registered for IContentish objects, not for default folders. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Why do we need types.xml and workflows.xml?
Hi! Martin Aspeli wrote: The GS handlers for portal_types and portal_workflow both require a single file - types.xml and workflows.xml - that declares the objects, and a directory full of files - types/*.xml and workflows/*.xml - to initialise them. However, in both cases, there is enough information in the per-item files (id, meta_type) to make the types.xml and workflows.xml redundant. Some tools are ordered containers, the types tool might become ordered as well. GS always specifies the order of sub-objects in the container's file. Right now we have a relatively easy rule: Adding, moving or removing sub-objects modifies the container, so these changes *always* have to be specified explicitly in the container's file. 'id' and 'meta_type' in the per-item files are not really used. Would it be an improvement to remove that redundant information from the per-item files? Worse, it's easy to forget, and no warning that there are orphan files. Adding a warning might be an other solution. I'm pretty sure it's an easy fix to make types.xml and workflows.xml optional (or even deprecated, though of course workflows.xml also has bind information that should remain there). All the information required for adding, moving or removing sub-objects is currently stored in the container's file. Additional code and complexity is necessary to extract that information from per-item files. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Why do we need types.xml and workflows.xml?
Hi! Martin Aspeli wrote: yuppie wrote: Martin Aspeli wrote: The GS handlers for portal_types and portal_workflow both require a single file - types.xml and workflows.xml - that declares the objects, and a directory full of files - types/*.xml and workflows/*.xml - to initialise them. However, in both cases, there is enough information in the per-item files (id, meta_type) to make the types.xml and workflows.xml redundant. Some tools are ordered containers, the types tool might become ordered as well. GS always specifies the order of sub-objects in the container's file. To what end? It's not ordered now, and I can't see a good reason to make it ordered. It would be useful to specify the order in 'add' menus by ordering the type infos. I'm pretty sure it's an easy fix to make types.xml and workflows.xml optional (or even deprecated, though of course workflows.xml also has bind information that should remain there). All the information required for adding, moving or removing sub-objects is currently stored in the container's file. Additional code and complexity is necessary to extract that information from per-item files. True, but not very much. See http://dev.plone.org/collective/browser/collective.wtf/trunk/collective/wtf/exportimport.py#L128 for an example. That code uses a hard-coded factory and the first part of the file name is used as 'id'. Right? The types tool can contain many different objects: Several kinds of TypeInfos and scripts for ScriptableTypeInfos. You can't hard-code the factory, you have to parse the file to find out which factory is required. But you can't be sure the file is an XML file of a specific format. The import/export adapter for scripts has a different format. I haven't seen an alternative adapter for TypeInfos, but right now you can plug in a different format (like CSV for workflows) by using a different import/export adapter. In general, repetition like this is counter-productive. I've had to explain this to three people new to Plone recently, and it feels like I'm making excuses rather than a strong case. We could add 10 lines of code and save 100 people from making common mistakes that cause problems of the type why doesn't my workflow show up? with no errors or warning messages. I would probably not deprecate the existing two-file pattern though, just make it optional. I'm not happy with the current file format. But representing containers is a general problem and I want *one* generic solution that works for all use cases. We have .objects files for content and .xml files for configuration. You propose a different pattern, and I doubt it could replace the other two patterns. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Inconstancy with CA traversal
Wichert Akkerman wrote: Previously Dylan Jay wrote: I've observed an unexpected effect that you can override a skin based template or python script with a browser view in a sub folder but not at the portal root. I'm trying to get my head round all the various traversal code in zope/five and would appreciate any tips from someone who knows this code well. For some unknown reason CMF explicitly encoded that behaviour in __bobo_traverse__. It's bitten Plone as well. ??? Only DiscussionItemContainer has a __bobo_traverse__ method. Five was changed a while ago to make sure views don't mask attributes: http://codespeak.net/pipermail/z3-five/2006q1/001186.html Skin methods are attributes of the portal root (see __getattr__ of SkinnableObjectManager), but not of sub folders. Views are looked up after attributes but before acquired attributes. HTH, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] newstyle content creation
Hi Charlie!
Charlie Clark wrote:
Am 25.04.2008 um 09:23 schrieb yuppie:
I simplified the code in ContentAddFormBase.create and moved it to the
add view. 'finishCreate' no longer exists, your add view has to
implement the complete 'create' method. Formlib raises an
NotImplementedError if 'create' is missing.
This requires a few more lines of code in add views for real
IDynamicType content. If you hardcode factory and portal_type in the
view, the code becomes much simpler. And if the __init__ method of
your content type handles unicode and datetime correctly, 'create' can
be a single line.
Agreed. The first five lines are generic and should probably be in
ContentAddFormBase leaving just the adapter stuff to be implemented by
the view itself which is what is was before! _create would be more in
keeping with other formlib methods such as handle_success calling
_handle_success.
Did some more refactoring. If your factory can handle all the input,
ContentAddFormBase's 'create' method should be sufficient. If not, you
need a 'create' method like the one in FileAddView.
It's taken me such a while to get my head around the
ProxyFieldProperty stuff that I've made all my new content stuff work
without it but I can see you've used it elegantly.
You should not use that stuff if you don't need it. Schema adapters
and ProxyFieldProperty are just legacy code for old content types.
I know. But I didn't know at the time and boy did it make me think that
things were going to be harder than they needed! I had to take some time
out at the time and curse the nameless people who hadn't written the
dummies guide to this! Still, it wasn't a bad idea making me think more
about this stuff.
Sorry. Added a small explanation in the module docstring.
Regarding naming: I suppose the easiest thing is to add an id field to
the add form for none file objects.
That's an option if you don't want automatically generated IDs. My
question was how to integrate oldstyle factories that don't have an add
form into an add menu.
It would be nice to have a require
once in the schema value for things like upload fields so that the same
schema can be used for adding and editing.
In my own code I use some modified widgets that support
self.widgets['foo'].required=True to override required=False of the field.
This does, of course, beg the question: when we've moved everything to
browser_views do we start thinking about moving the default classes to
zope.app based stuff? Or do we still depend too heavily on the Zope2
security declarations and other stuff?
First priority for existing content classes is backwards compatibility.
I prefer to keep them as they are and to use adapters to make them work
with Zope3 style code.
I also understand what you mean about making a menu for this stuff.
It would be nice to have some configuration for this so that we don't
have to rely on actions such as AddFile, AddImage, etc. Would that be
something like listing all views that provide a specific interface?
No. The view registrations don't provide enough information and I'd
like to keep this configurable TTW.
We can look up the addable types in the types tool as folder_factories
and Plone do. But in that case we need a way to get the URL of the add
view.
The lookup is pretty much what I do at the moment. I can't think of an
easy way of doing this apart from convention which is pretty much what
you suggest with addFile. I suppose the next thing would be to add
support for the '+' syntax and addMenuItem directive?
The IAdding view ('+' syntax) and Zope 3 menus are special code for the
Zope 3 app ZMI. I don't plan to add support for that.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] newstyle content creation
Hi! Charlie Clark wrote: Okay. Had a quick look your implementation and I think I understand it! 8-) Had trouble with createAndAdd and finishCreate but now I understand them. Shouldn't there be default finishCreate in the ContentAddFormBase so that it's obvious we have to overwrite it? I simplified the code in ContentAddFormBase.create and moved it to the add view. 'finishCreate' no longer exists, your add view has to implement the complete 'create' method. Formlib raises an NotImplementedError if 'create' is missing. This requires a few more lines of code in add views for real IDynamicType content. If you hardcode factory and portal_type in the view, the code becomes much simpler. And if the __init__ method of your content type handles unicode and datetime correctly, 'create' can be a single line. It's taken me such a while to get my head around the ProxyFieldProperty stuff that I've made all my new content stuff work without it but I can see you've used it elegantly. You should not use that stuff if you don't need it. Schema adapters and ProxyFieldProperty are just legacy code for old content types. I also understand what you mean about making a menu for this stuff. It would be nice to have some configuration for this so that we don't have to rely on actions such as AddFile, AddImage, etc. Would that be something like listing all views that provide a specific interface? No. The view registrations don't provide enough information and I'd like to keep this configurable TTW. We can look up the addable types in the types tool as folder_factories and Plone do. But in that case we need a way to get the URL of the add view. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] newstyle content creation
Martin Aspeli wrote: Today I checked in a formlib based add view for File objects[3]. Have you looked at z3c.form at all? There's a package called plone.z3cform that provides Zope 2 integration for this (it shouldn't be Plone specific beyond that). I'm only asking since people seem to be going in this direction. I know. These are the reasons why I chose zope.formlib: - Zope 2 ships with zope.formlib, not with z3c.form - zope.formlib is already used for CMF edit forms - the work done for the zope.formlib based version is not lost if we switch to z3c.form, converting the forms should be easy The checked in add form borrows one pattern from z3c.form: It doesn't depend on IAdding, the view is registered for the container. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] newstyle content creation
Charlie Clark wrote: Am 22.04.2008 um 17:24 schrieb yuppie: Yes. Missing is the integration in the CMFDefault add menu. For now the new 'add_file' action is used for showing the link to 'addFile.html'. I hope to have some time for this (and a new table-free version of main_template.pt) on Friday. Where exactly is the CMFDefault add menu? Sorry, if the question is stupid but I didn't think we could use zope3 menu directives? Sorry for using misleading terms. I was referring to 'folder_factories'. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] newstyle content creation
Hi! Charlie Clark wrote: Am 23.04.2008 um 11:12 schrieb yuppie: Charlie Clark wrote: Am 22.04.2008 um 17:24 schrieb yuppie: Yes. Missing is the integration in the CMFDefault add menu. For now the new 'add_file' action is used for showing the link to 'addFile.html'. I hope to have some time for this (and a new table-free version of main_template.pt) on Friday. Where exactly is the CMFDefault add menu? Sorry, if the question is stupid but I didn't think we could use zope3 menu directives? Sorry for using misleading terms. I was referring to 'folder_factories'. ah, so clicking on add brings up the tried and trusty page for adding objects to folders? Yes. Only then do we get to the appropriate add_view? No. As I said: That part is still missing. 'folder_factories' provides the old add procedure, the new alternative for 'File' content is available as action in the menu. Would it be a good idea to move this to a menu item like object_actions? Got the code for this. Maybe. Does your code use the type infos or additional actions (attached to the type infos or stored in the actions tool) to get the data? Do your actions provide a way to specify the object id (as possible in folder_factories) or how do you choose the ids? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] newstyle content creation
Charlie Clark wrote: Am 22.04.2008 um 14:27 schrieb yuppie: Today I checked in a formlib based add view for File objects[3]. There is a new Add File action available if you use the Experimental CMFDefault Browser Views extension profile. Any feedback is welcome. Not sure if this makes Bug #161664[4] obsolete. This is excellent news! I have been struggling considerably with invokeFactory() on a recent project. Does this mean we can develop add_forms analogue to Zope 3? Yes. Similar code as used for creating File objects should work for any content. But ContentAddFormBase is new and not very well tested, so you might find some bugs. Note that the add view is registered for the container interface, not IAdding. zope.formlib still uses IAdding by default, but z3c.form doesn't. And do I get the goodies just with an svn update? Yes. Missing is the integration in the CMFDefault add menu. For now the new 'add_file' action is used for showing the link to 'addFile.html'. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] GenericSetup and CMF dependencies
Tres Seaver wrote: yuppie wrote: Hanno Schlichting wrote: yuppie wrote: I guess CMF 2.2 will be released before Zope2 or Python requires setuptools, so at least for now it is a GenericSetup/CMF dependency. http://svn.zope.org/CMF/trunk/ still exists and needs to be maintained (or deleted). Who ever added the setuptools dependency should update INSTALL.txt and friends (if we agree to keep CMF trunk and the dependency). I don't have a strong opinion on CMF/trunk. I don't use it, so I don't have a particular interest in keeping it around. Maybe it should be replaced by a buildout, but for now I would keep it. - -1 to managing dependencies in buildout-specific files: they belong in setup.py. I guess you did get me wrong. I was talking about the future of http://svn.zope.org/CMF/trunk/, not about dependency management. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] GenericSetup and CMF dependencies
Hi!
Wichert Akkerman wrote:
Previously yuppie wrote:
Until recently, the Products themselves didn't use setuptools. Revision
85287 (http://svn.zope.org/?rev=85287view=rev) changed that. It is no
longer possible to run CMF without setuptools installed.
Was that intended when setuptools was added to install_requires? We
always tried hard to keep CMF dependencies to a minimum. Will we only
support egg releases for CMF 2.2 and later, making setuptools required
anyway?
The eggified CMF already required setuptools to make sure the Products
namespace is setup correctly.
'declare_namespace' is used with a fallback, so setuptools was not
strictly required:
try:
__import__('pkg_resources').declare_namespace(__name__)
except ImportError:
from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)
Considering that entire python community
appears to be moving to egg, Zope2 is going to be distributed in egg
form (at least there is a strong move in that direction) I think a
dependency on setuptools is not problematic.
I guess CMF 2.2 will be released before Zope2 or Python requires
setuptools, so at least for now it is a GenericSetup/CMF dependency.
http://svn.zope.org/CMF/trunk/ still exists and needs to be maintained
(or deleted). Who ever added the setuptools dependency should update
INSTALL.txt and friends (if we agree to keep CMF trunk and the dependency).
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] GenericSetup and CMF dependencies
Hi Hanno! Hanno Schlichting wrote: yuppie wrote: I guess CMF 2.2 will be released before Zope2 or Python requires setuptools, so at least for now it is a GenericSetup/CMF dependency. http://svn.zope.org/CMF/trunk/ still exists and needs to be maintained (or deleted). Who ever added the setuptools dependency should update INSTALL.txt and friends (if we agree to keep CMF trunk and the dependency). I don't have a strong opinion on CMF/trunk. I don't use it, so I don't have a particular interest in keeping it around. Maybe it should be replaced by a buildout, but for now I would keep it. For me the dependencies noted in setup.py are the canonical place and I would delete the DEPENDENCIES.txt files from all packages on trunk and instead make sure the ones in setup.py are current. If we can agree on that, I can do the work and make sure INSTALL.txt is current as well. I'm still not 100% convinced that making CMF 2.2 depend on setuptools is necessary. But given that you volunteer to do all the related work, I'm fine with it. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] [dev] GenericSetup and CMF dependencies
Hi! Each Product has two lists of dependencies: One in DEPENDENCIES.txt and one in setup.py. They are not in sync. The setup.py files contain only 'setuptools' and 'five.localsitemanager' dependencies: Products.GenericSetup/setup.py: install_requires=[ setuptools, five.localsitemanager = 0.2, # 'Zope = 2.10', ], Products.CMFCore/setup.py: install_requires=[ 'setuptools', 'five.localsitemanager=0.3', ], all other setup.py files: install_requires=[ 'setuptools', ], Until recently, the Products themselves didn't use setuptools. Revision 85287 (http://svn.zope.org/?rev=85287view=rev) changed that. It is no longer possible to run CMF without setuptools installed. Was that intended when setuptools was added to install_requires? We always tried hard to keep CMF dependencies to a minimum. Will we only support egg releases for CMF 2.2 and later, making setuptools required anyway? I'm just asking. If there are good reasons, I'm fine with adding the setuptools dependency. As soon as we have a decision, the relevant files should be updated. Can we get rid of the DEPENDENCIES.txt files and specify *all* dependencies in the setup.py files? Any feedback is welcome. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
