Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CMF Tests Summarizer wrote: > Summary of messages to the cmf-tests list. > Period Sun Aug 16 12:00:00 2009 UTC to Mon Aug 17 12:00:00 2009 UTC. > There were 4 messages: 4 from CMF Tests. > > > Test failures > - > > Subject: FAILED (failures=1) : CMF-trunk Zope-trunk Python-2.6.2 : Linux > From: CMF Tests > Date: Sun Aug 16 21:17:25 EDT 2009 > URL: http://mail.zope.org/pipermail/cmf-tests/2009-August/011888.html This test appears to be due to changes which Alec made in fixing the MailHost product on the Zope trunk. I think these doctests themselves are largely bogus (they are breaking on bits we don't care about), but maybe there is an easy fix? Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKiW0U+gerLs4ltQ4RAtk6AKDI6mYd+M27gyISBD7NBrLZkA2KcACfblHN iE3/LP2oXYzqGQumuE+SqJA= =Srzn -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CMF 2.2 dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKVjnk+gerLs4ltQ4RAtC1AJ9TPlzJYxUkMKoPYza5eer2cW6logCg0d+1 VOAkZ19RQxNmhgZqoVNIPp0= =2qxe -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFCore/trunk/setup.py - made new testing dependency caused by r99878 explicit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yvo Schubbe wrote: > Log message for revision 101588: > - made new testing dependency caused by r99878 explicit > > Changed: > U Products.CMFCore/trunk/setup.py > > -=- > 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! Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKUNLo+gerLs4ltQ4RAiT0AJ955ckMsQ9dfNZOK3ljDJeGv1zIyQCgh4TQ GLrtEmr0DK6Fb0vRn7na974= =ReNy -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CMF 2.2 dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: > Hi! > > > zope.app.component and zope.app.container are no longer part of Zope 2 > trunk, but CMF currently has many imports from these two packages. > > All the code needed by CMF has been moved to new packages (zope.site, > zope.browser, zope.container) that are part of Zope 2 trunk, but they > are not part of Zope 2.11. > > > 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. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKUMss+gerLs4ltQ4RAh+0AJoC8Ud9hs6hV+9UqtPeB4c29EY7UACggAhS cT2csKE9IJ0qSlbgTlOruzQ= =Ydt4 -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Need new release 1.4.5 of GenericSetup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vincent Fretin wrote: > So anybody have the time to do a new release? I just released GS 1.4.5 to PyPI: http://pypi.python.org/pypi/Products.GenericSetup/1.4.5 Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKPSma+gerLs4ltQ4RAhS8AJ9+fl37D+lQ4GE7UrFkYdDi7ebyEQCfSEw4 RQKzNgluVoKqr8ms0vinVWQ= =JBRU -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup 1.5 release plans?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. 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. Trea. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKOWiF+gerLs4ltQ4RAnrBAJ47oQll/Hg7k78f93aYjFlaS2aTlwCgoZB4 5Z+BVuwjYEhYeLWcolrUX78= =qC8J -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Help with tests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Charlie Clark wrote:
> Hi,
>
> I'm having a little trouble with writing the tests for my formlib
> folder contents view replacement. The basic tests (based on yuppie's
> doctests) are fine but incomplete. I'm now integrating batching and am
> getting caught on view permissions for DummyContent objects.
>
> This is the test:
>
> def _make_batch(self):
> from Products.CMFCore.tests.base.dummy import DummyContent
> batch_size = 25
> for i in range(batch_size + 2):
> content_id = "Dummy%s" % i
> content_obj = DummyContent(content_id)
> content_obj.portal_type = "Dummy Content"
> obj = self.folder._setObject(content_id, content_obj)
> content_obj.manage_setLocalRoles('user_foo', ['Owner'])
>
> def test_check_batching(self):
> self._make_batch()
> batch_size = 25
> view = ContentsView(self.folder, TestRequest())
> self.assertEquals(view._getBatchObj().sequence_length,
> batch_size)
> self.assertEquals(view.navigation_next['title'], "NEXT N
> ITEMS")
>
> and this is error:
>
>File "/Users/charlieclark/cmf-svn/CMF.buildout/trunk/src/Zope2/src/
> AccessControl/ZopeGuards.py", line 71, in guarded_getitem
> if getSecurityManager().validate(object, object, None, v):
> Unauthorized: (item 0): You are not allowed to access 'Dummy0' in this
> context
>
> Obviously I don't have the permission to access my newly created
> objects. So how do I go about fixing this for my tests? I can't find a
> comparable example in the rest of the CMF tests? Is it best to fix the
> permissions of the objects so that are viewable be "anonymous" or
> should I assign my view to my user? And while I'm at it, am I creating
> my dummy objects in the right way? I remember Tres saying something
> about this recently.
Do you need to set up a security manager with 'user_foo', grep for
'newSecurityManager' in other CMF tests.
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFKK7uJ+gerLs4ltQ4RAuETAJ4k+2UXnme76ex4th3wvkp5IgqyJgCdE5Us
w4dVMlK3UgdZBMrZlmt7yyQ=
=/E3e
-END PGP SIGNATURE-
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Extending FTI.isConstructionAllowed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: > Wichert Akkerman wrote: >> Previously Tres Seaver wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> Wichert Akkerman wrote: >>>> I have a use case where I need to put additional restrictions on object >>>> creation, in particular I need to restrict the maximum depth of items >>>> inside of a container of a specific type. The ideal place to put such a >>>> restriction seems to be the isConstructionAllowed method on the FTI. >>>> Currently this method is not very extensible, which leads to complicated >>>> code in various FTI types. >>>> >>>> I am considering to add an extension point here, something like this: >>>> >>>> class ITypeConstructionFilter(Interface): >>>> def __init__(fti, container): >>>> """Adapt on the FTI of the object being created and the target >>>> container""" >>>> >>>> def allowed(): >>>> """Check if construction is allowed.""" >>>> >>>> >>>> current checks such as the workflow check that was added in CMF 2.2, or >>>> the type constraint logic Plone has in ATContentTypes could be moved to >>>> such an adapter. The standard isConstructionAllowed method could then >>>> query all registered adapters to check if construction should be possible. >>>> >>>> Does this sound sensible? >>> I'm not sure about querying all adapters: I think it would be clearer >>> to query the one adapter whose name corresponds to the type name of the >>> FTI (the "query all" case leads to tricky / emergent behavior). >> Querying a single adapter makes it very hard to use this as an extension >> point. Being able to have multiple independent validation-hooks is the >> whole point of my suggestion, and being able to only use a single >> adapter would make that impossible. > > I don't *want* multiple third-party products to register this adapter: > I think it belongs to the integrator to set the policy for the site. > "Reusable policy" is an oxymoron. Ugh, following up to myself: If you really *want* to allow every adapter registered anywhere for that interface to play, you can still get that under my scenario, by registering the default (unnamed) adapter to do your dance. That implementation would be:: class PromiscuousConstructionFilter: implements(ITypeConstructionFilter) def __init__(self, (obj, container): self.obj = obj self.container = container def __call__(self): for name, filter in getAdapters((self, container), ITypeConstructionFilter): if name: # skip default if not filter.allowed(): return False The policy choice would then be whether to actually register the "promiscuous" adapter (which would *not* be anabled by default in CMF). Your alternative makes anybody who does not want the feature responsible for suppressing the unwanted filter adapter registrations everywhere, which is unacceptable. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKJViS+gerLs4ltQ4RAuTHAJsGPfSmI2TrhJdbnMvyzDlNt/pbRgCgpxEz jbBCxsR5758+fjM5heSL+5M= =by9h -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Extending FTI.isConstructionAllowed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: > Previously Tres Seaver wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Wichert Akkerman wrote: >>> I have a use case where I need to put additional restrictions on object >>> creation, in particular I need to restrict the maximum depth of items >>> inside of a container of a specific type. The ideal place to put such a >>> restriction seems to be the isConstructionAllowed method on the FTI. >>> Currently this method is not very extensible, which leads to complicated >>> code in various FTI types. >>> >>> I am considering to add an extension point here, something like this: >>> >>> class ITypeConstructionFilter(Interface): >>> def __init__(fti, container): >>> """Adapt on the FTI of the object being created and the target >>> container""" >>> >>> def allowed(): >>> """Check if construction is allowed.""" >>> >>> >>> current checks such as the workflow check that was added in CMF 2.2, or >>> the type constraint logic Plone has in ATContentTypes could be moved to >>> such an adapter. The standard isConstructionAllowed method could then >>> query all registered adapters to check if construction should be possible. >>> >>> Does this sound sensible? >> I'm not sure about querying all adapters: I think it would be clearer >> to query the one adapter whose name corresponds to the type name of the >> FTI (the "query all" case leads to tricky / emergent behavior). > > Querying a single adapter makes it very hard to use this as an extension > point. Being able to have multiple independent validation-hooks is the > whole point of my suggestion, and being able to only use a single > adapter would make that impossible. I don't *want* multiple third-party products to register this adapter: I think it belongs to the integrator to set the policy for the site. "Reusable policy" is an oxymoron. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKJVTi+gerLs4ltQ4RAnT7AJ0aNlB5Vr1MHdSnBMcxrcfb70dIDQCgmAv0 VhcD0BrbHpW1c60aZlCvai0= =haLI -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Extending FTI.isConstructionAllowed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: > I have a use case where I need to put additional restrictions on object > creation, in particular I need to restrict the maximum depth of items > inside of a container of a specific type. The ideal place to put such a > restriction seems to be the isConstructionAllowed method on the FTI. > Currently this method is not very extensible, which leads to complicated > code in various FTI types. > > I am considering to add an extension point here, something like this: > > class ITypeConstructionFilter(Interface): > def __init__(fti, container): > """Adapt on the FTI of the object being created and the target > container""" > > def allowed(): > """Check if construction is allowed.""" > > > current checks such as the workflow check that was added in CMF 2.2, or > the type constraint logic Plone has in ATContentTypes could be moved to > such an adapter. The standard isConstructionAllowed method could then > query all registered adapters to check if construction should be possible. > > Does this sound sensible? I'm not sure about querying all adapters: I think it would be clearer to query the one adapter whose name corresponds to the type name of the FTI (the "query all" case leads to tricky / emergent behavior). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKH+mA+gerLs4ltQ4RAhG7AKDZsLKNRVUHBfLoq/tbGsqU50TVJgCgr3Np 06Ck6T4Xyvru7WKgm8vUjbs= =2I0k -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] 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'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yvo Schubbe 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? Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKEYp0+gerLs4ltQ4RAgxsAJsEPXTCJjcg5Pg+UliO8gVDBmnTXgCgtxiu +Jdm+tV5Ij8g2mlOayqWSjI= =QC0l -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 5 OK, 2 Failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CMF Tests Summarizer wrote: > Test failures > - > > Subject: FAILED (errors=3) : CMF-2.1 Zope-2.10 Python-2.4.6 : Linux > From: CMF Tests > Date: Thu May 7 21:23:45 EDT 2009 > URL: http://mail.zope.org/pipermail/cmf-tests/2009-May/011393.html > > Subject: FAILED (errors=3) : CMF-2.1 Zope-2.11 Python-2.4.6 : Linux > From: CMF Tests > Date: Thu May 7 21:25:48 EDT 2009 > URL: http://mail.zope.org/pipermail/cmf-tests/2009-May/011394.html Both of those broke when I ripped out a string exception yesterday being raised from OFS.CopySupport. I have checked in a fix to the CMFCore test which expected a string. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKBFR7+gerLs4ltQ4RAsc4AJ9cXGKpMHLdmJuFCKAQvAzfdBJKNgCgjsHX lc0WkdBW8Dbhrz4Z8vSnuBc= =HlJk -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 2 OK, 5 Unknown
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: > CMF Tests Summarizer wrote: >> Summary of messages to the cmf-tests list. >> Period Mon Apr 27 12:00:00 2009 UTC to Tue Apr 28 12:00:00 2009 UTC. >> There were 7 messages: 7 from CMF Tests. > > >> Unknown >> --- > >> Subject: UNKNOWN : CMF-trunk Zope-2.10 Python-2.4.6 : Linux >> From: CMF Tests >> Date: Mon Apr 27 21:35:28 EDT 2009 >> URL: http://mail.zope.org/pipermail/cmf-tests/2009-April/011325.html > >> Subject: UNKNOWN : CMF-trunk Zope-2.11 Python-2.4.6 : Linux >> From: CMF Tests >> Date: Mon Apr 27 21:37:29 EDT 2009 >> URL: http://mail.zope.org/pipermail/cmf-tests/2009-April/011326.html > >> Subject: UNKNOWN : CMF-trunk Zope-trunk Python-2.4.6 : Linux >> From: CMF Tests >> Date: Mon Apr 27 21:39:29 EDT 2009 >> URL: http://mail.zope.org/pipermail/cmf-tests/2009-April/011327.html > >> Subject: UNKNOWN : CMF-trunk Zope-trunk Python-2.5.4 : Linux >> From: CMF Tests >> Date: Mon Apr 27 21:41:30 EDT 2009 >> URL: http://mail.zope.org/pipermail/cmf-tests/2009-April/011328.html > >> Subject: UNKNOWN : CMF-trunk Zope-trunk Python-2.6.1 : Linux >> From: CMF Tests >> Date: Mon Apr 27 21:43:30 EDT 2009 >> URL: http://mail.zope.org/pipermail/cmf-tests/2009-April/011329.html > > These tests are breaking because a much newer version of zope.component > (3.7.0) is being installed than the on called out in the Zope 2 index[1] > (3.5.1). That version is older than the one in the Zope 2 > versions.cfg[1] (3.6.0). > > [1] http://download.zope.org/Zope2/index/2.12.0a4/zope.component/ > > [2] http://svn.zope.org/Zope/trunk/versions.cfg?rev=99525&view=auto OK, I have fixed this failure by adding a conditional import of IDefaultViewName from its new location: http://svn.zope.org/Products.CMFCore/trunk/?rev=99559&view=rev Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ9xRG+gerLs4ltQ4RAusiAJ49Xc15jjFbrzWmBftCWZVC753zlQCdEYaV sEy6ICujrjOsXpGK5wR06/E= =9Mub -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 2 OK, 5 Unknown
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CMF Tests Summarizer wrote: > Summary of messages to the cmf-tests list. > Period Mon Apr 27 12:00:00 2009 UTC to Tue Apr 28 12:00:00 2009 UTC. > There were 7 messages: 7 from CMF Tests. > > > Unknown > --- > > Subject: UNKNOWN : CMF-trunk Zope-2.10 Python-2.4.6 : Linux > From: CMF Tests > Date: Mon Apr 27 21:35:28 EDT 2009 > URL: http://mail.zope.org/pipermail/cmf-tests/2009-April/011325.html > > Subject: UNKNOWN : CMF-trunk Zope-2.11 Python-2.4.6 : Linux > From: CMF Tests > Date: Mon Apr 27 21:37:29 EDT 2009 > URL: http://mail.zope.org/pipermail/cmf-tests/2009-April/011326.html > > Subject: UNKNOWN : CMF-trunk Zope-trunk Python-2.4.6 : Linux > From: CMF Tests > Date: Mon Apr 27 21:39:29 EDT 2009 > URL: http://mail.zope.org/pipermail/cmf-tests/2009-April/011327.html > > Subject: UNKNOWN : CMF-trunk Zope-trunk Python-2.5.4 : Linux > From: CMF Tests > Date: Mon Apr 27 21:41:30 EDT 2009 > URL: http://mail.zope.org/pipermail/cmf-tests/2009-April/011328.html > > Subject: UNKNOWN : CMF-trunk Zope-trunk Python-2.6.1 : Linux > From: CMF Tests > Date: Mon Apr 27 21:43:30 EDT 2009 > URL: http://mail.zope.org/pipermail/cmf-tests/2009-April/011329.html These tests are breaking because a much newer version of zope.component (3.7.0) is being installed than the on called out in the Zope 2 index[1] (3.5.1). That version is older than the one in the Zope 2 versions.cfg[1] (3.6.0). [1] http://download.zope.org/Zope2/index/2.12.0a4/zope.component/ [2] http://svn.zope.org/Zope/trunk/versions.cfg?rev=99525&view=auto Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ9wO1+gerLs4ltQ4RAoiMAJ9NoKkZDL9VeSUt7KonGuef+CnP0wCeLsZt G2dJOUUUQ9k2x+jFIt1kzUQ= =55bl -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Proposal: MemberDataFactory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: > Previously Miles wrote: >> We have quite a lot of copy-and-paste code here in order to support >> using a custom MemberData class for members in particular sites. >> >> The reason for this is that the only way to use a different MemberData >> class is to provide a custom wrapUser method. >> >> I'd like to propose that this is changed to use a factory registered >> through the CA to create new MemberData objects, in order that this is >> pluggable without requiring a custom MemberDataTool. > > Can you explain the use case? I suspect you can also solve this with PAS > and a custom user factory PAS plugin. "Member data" is wildly different from "user properties": memberdata is about stuff local to a site, which is not required to have its own PAS. Think of "member data" as being local annotations keyed by user ID, not as being tightly coupled to the user from PAS. (The fact that Plone forces the site to have its own PAS instance blurs this distinction). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJwSSQ+gerLs4ltQ4RAlaLAJ48okhOgktBSaeeyp/yKwWwvewt4QCguhly n0uef4ZPnUcAaJfonjjxzDg= =2vyp -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: > Hi! > > > Tres Seaver wrote: >> Miles wrote: >>> >> Can I suggest the following logic: >>> >> >>> >> 1. if the object already implements the IIndexableObject marker >>> >> interface, no wrapping is required; > > If we don't support 3., we can make 'no wrapping' the default. > >>> >> 2. otherwise, adapt to IIndexableObject to do the wrapping; >>> >> >>> >> 3. if no adapter is registered, fall back to the existing >>> >> IndexableObjectWrapper class for BBB. >>> > >>> > That sounds like what I had in mind, but not for BBB. I think of the >>> > adapter scheme as a way to choose a non-default wrapper, rather than a >>> > quasi-mandatory replacement for it. > > What's the win of providing a default that way? IndexableObjectWrapper > contains policy decisions, Plone e.g. doesn't use it. The current code > on the branch registers an adapter for IContentish, so CMFDefault will > never use that hardcoded default. I think that registration should be in CMFDefault, anyway. Applications which haven't updated to this new model should continue to work (including indexing 'allowedRolesAndUsers'). > The change is in a new feature release. People can't expect full BBB if > they use customized registrations or catalog content that doesn't > implement IContentish. > >>> Ok, well this logic is checked in now on the branch, and tests adjusted >>> accordingly. Without any warnings. >> Thanks, looks good. > > Looks unnecessarily complex to me. But I'm afraid I'm outvoted. Falling back to the current behavior is cheap, both at runtime and in maintenance costs. Why break BBB gratuitously? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJwP/e+gerLs4ltQ4RAmr3AJ9vBrqTWDyDo/DSPGjY00p6XIJbvQCgpTW1 9puaqcux8hIdow0DLsFZ4i4= =VeKx -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miles wrote: > > Hi > > > > >> Can I suggest the following logic: > >> > >> 1. if the object already implements the IIndexableObject marker > >> interface, no wrapping is required; > >> > >> 2. otherwise, adapt to IIndexableObject to do the wrapping; > >> > >> 3. if no adapter is registered, fall back to the existing > >> IndexableObjectWrapper class for BBB. > > > > That sounds like what I had in mind, but not for BBB. I think of the > > adapter scheme as a way to choose a non-default wrapper, rather than a > > quasi-mandatory replacement for it. > > Ok, well this logic is checked in now on the branch, and tests adjusted > accordingly. Without any warnings. Thanks, looks good. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJwOUj+gerLs4ltQ4RAolpAKC0o4oox/IYKe4curmEgKFiLnRjqQCg2kd2 Soip97b3h35ItbJhdjKjxNA= =+baG -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miles wrote: > > Hi, > >>>> - The CatalogTool tests set up the adapter at the moment, as a lot of >>>> the catalog tests require the adapter to work properly. This is done in >>>> the _makeContent method as it applied to most tests that used the dummy >>>> content. However, I think it belongs somewhere else, but I wasn't sure >>>> whether that place was a layer, a setup method or somewhere else. Any >>>> suggestions? >>> 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? >> Agreed. I had expected that the catalog would do a queryAdapter, and >> default to the existing wrapper class if not found. > > Makes sense for BBB - it's possible that someone might be inheriting > from the Catalog but not loading the adapter registrations, in which > case their code would just break. > > Can I suggest the following logic: > > 1. if the object already implements the IIndexableObject marker > interface, no wrapping is required; > > 2. otherwise, adapt to IIndexableObject to do the wrapping; > > 3. if no adapter is registered, fall back to the existing > IndexableObjectWrapper class for BBB. That sounds like what I had in mind, but not for BBB. I think of the adapter scheme as a way to choose a non-default wrapper, rather than a quasi-mandatory replacement for it. > In the case of 3, I would like to issue some deprecation warning or log > message to alert that a registration is required in future. As 2.2.0 is > not yet released, is it possible/desirable to make it a deprecation? I wouldn't add a warning for it, because I wouldn't rip out the fallback. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJwNqF+gerLs4ltQ4RArehAJ9PSt1zNnJFdKJV/dPx096ZP8y8/wCgmYSF CAD9dshczPrdWP4uf6cnpsQ= =/BUg -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: >> - The TraversingEventZCMLLayer now also loads implements.zcml, as the >> correct behaviour of both the catalog and the adapter class is required >> for the folder tests to pass. >> >> - The CatalogTool tests set up the adapter at the moment, as a lot of >> the catalog tests require the adapter to work properly. This is done in >> the _makeContent method as it applied to most tests that used the dummy >> content. However, I think it belongs somewhere else, but I wasn't sure >> whether that place was a layer, a setup method or somewhere else. Any >> suggestions? > > 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? Agreed. I had expected that the catalog would do a queryAdapter, and default to the existing wrapper class if not found. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJv+To+gerLs4ltQ4RAvt/AJ9D75eOsZh7FINca9MJsnTU26998gCghu8C TaiqRzwLe2WDoHIqaD7qGhs= =kd1W -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 2 OK, 3 Failed, 1 Unknown
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CMF Tests Summarizer wrote: > Summary of messages to the cmf-tests list. > Period Thu Mar 12 12:00:00 2009 UTC to Fri Mar 13 12:00:00 2009 UTC. > There were 6 messages: 6 from CMF Tests. > > > Test failures > - > > Subject: FAILED (errors=11) : CMF-trunk Zope-2.10 Python-2.4.6 : Linux > From: CMF Tests > Date: Thu Mar 12 21:55:37 EDT 2009 > URL: http://mail.zope.org/pipermail/cmf-tests/2009-March/011043.html > > Subject: FAILED (errors=11) : CMF-trunk Zope-2.11 Python-2.4.6 : Linux > From: CMF Tests > Date: Thu Mar 12 21:57:38 EDT 2009 > URL: http://mail.zope.org/pipermail/cmf-tests/2009-March/011044.html > > Subject: FAILED (errors=11) : CMF-trunk Zope-trunk Python-2.5.4 : Linux > From: CMF Tests > Date: Thu Mar 12 22:01:42 EDT 2009 > URL: http://mail.zope.org/pipermail/cmf-tests/2009-March/011046.html These failures are my fault: I have fixed them. > Unknown > --- > > Subject: UNKNOWN : CMF-trunk Zope-trunk Python-2.4.6 : Linux > From: CMF Tests > Date: Thu Mar 12 21:59:42 EDT 2009 > URL: http://mail.zope.org/pipermail/cmf-tests/2009-March/011045.html This problem is due to an HTTP timeout on a package index, which broke the buildout. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJulc1+gerLs4ltQ4RAhXMAKCbq35jjCY1wtHwl/dOK8lIi6LXDQCfbotk +g29AvkDJLydj47uYurynu8= =BDAG -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] five.localsitemanager: 1.0 branch dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: > Previously yuppie wrote: >> 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? I would just rip out the version requirement altogether (I did this the other day when testing CMFCore against the Zope2 trunk). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJuP9J+gerLs4ltQ4RAojUAJ9RDMq/LXZGtKsIyEQgj0ACrkDwKgCeMyoV v9KMIrY0j7IlEcQmSVOSSTU= =Gk/8 -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFCore/trunk/Products/CMFCore/tests/test_CatalogTool.py Clean out module-scope imports.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: > 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? 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 Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJtrFn+gerLs4ltQ4RAhOAAKCS/QoCbex5FOE+CevM4oPS0bVU5wCgocg7 bPxq/nV3CaSX/0CFtPvsaOQ= =Wzi8 -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup 1.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: > Previously Tres Seaver wrote: >> Are there open bug reports on such problems? Also, we might not even >> support running on Zope 2.10.x with this release, if it is too painful >> to resolve. > > I posted to this list earlier today. It is just a matter of changing a > few imports, so not painful at all. I'm a little puzzled: you expect to be able to upgrade to a new "major" release of GenericSetup (1.4.x -> 1.5.0), but not to pick up a "minor" update to Zope (2.10.x -> 2.10.latest)? Doesn't make much sense to me: if stability matters that much, then don't figure on upgrading products to new, possibly incompatible versions. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJsDcW+gerLs4ltQ4RAsTNAJ9hTXSYIu9F94z330knz9nnZ+VJCQCg3QzK 0jC9ZPsf7qXPTErdU4PrTc8= =USxM -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup 1.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: > Previously Wichert Akkerman wrote: >> Previously Tres Seaver wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> 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). >>> >>> - 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). >>> >>> Anyone have other stuff they would like to see in the mix (and can help >>> land)? >> I want to extend the upgrade step logic a bit to allow you to call >> single steps from other profiles. Should be a simple change. > > I have commited this. Once the BBB problems with Zope 2.10 are fixed I > have no objections (and would in fact be in favour) of an 1.5 release. Are there open bug reports on such problems? Also, we might not even support running on Zope 2.10.x with this release, if it is too painful to resolve. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJr9MF+gerLs4ltQ4RAn1YAKDEyjNVBYIauNOPGFXAmNXkW2zISgCfadMO 8JISC2q5vlIwnoGH6Al/Vfc= =k7XM -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CMF 2.2 plans?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: > 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. Hmm, I don't recall the issue here. > 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. 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? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrBEE+gerLs4ltQ4RApJJAJ9o8uut5gbE3UtHQWfD7yOQYEVikQCeMcVG HQhtPZ8IdGGAfpoOP8Ywmjs= =ShhR -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: > Previously Charlie Clark wrote: >> Am 25.02.2009 um 16:10 schrieb Wichert Akkerman: >>> The workflow tool is not a factor at all here. The problem is that CMF >>> registers some event handlers that do things like clear workflow >>> status >>> and local roles when you create a copy. >> I realise that but surely the handlers can have a default behaviour >> that can be changed depending on the configuration? > > In my opinion they should not be globally registered at all, but > available for registration in a local site manager. CMFDefault could > then do that registration for its needs. You are in the cleft stick created by the paradox of "reusable configuration" (an oxymoron, even). The other alternative is to *not* the configuration from CMFDefault, but copy and tweak it for your own app. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJpXzP+gerLs4ltQ4RAnfeAKDVHNWHME5cFFuY+r0V3gtQcU7r3gCgrC3N DudQiq3r8xkvq2dbu0kwE6U= =hywa -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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? > > 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. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJnEdu+gerLs4ltQ4RAoMSAKCEyP2CN5EfonXqkZSIGjLfHLqM+wCfYtEC /pYBguVEQhbri7sVoAtbJsM= =AwXA -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup test failures on Python 2.5's tarfile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: > Jens Vagelpohl wrote: >> On Feb 16, 2009, at 19:10 , Tres Seaver wrote: > >>> Anybody have a clue what changed in the Python 2.5 tarfile module >>> which >>> triggers these failures? >> Running against Python 2.5.2 using the same CMF.buildout I see no such >> failure. > > Hmm "'Curiouser and curiouser,' said Alice." I am running 2.5.1: I > will try with 2.5.2. The changelog for Python 2.5.2[1] has quite a large number of references to the 'tarfile' module. One in particular looks like it might be the culprit: - tarfile.py: Fix directory names to have only one trailing slash. [1] http://www.python.org/download/releases/2.5.2/NEWS.txt (Later) OK, after installing 2.5.2, all tests pass cleanly. Somebody really screwed the pooch in there. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJmdA++gerLs4ltQ4RAmaPAKCM9lVMNnP4IbpVTkMfSPKz7e1cQgCgkAXc CUEdtKeVL+ekXqyzmYkYdMI= =Q/od -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup test failures on Python 2.5's tarfile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: > > On Feb 16, 2009, at 19:10 , Tres Seaver wrote: > >> Anybody have a clue what changed in the Python 2.5 tarfile module >> which >> triggers these failures? > > Running against Python 2.5.2 using the same CMF.buildout I see no such > failure. Hmm "'Curiouser and curiouser,' said Alice." I am running 2.5.1: I will try with 2.5.2. >> Ran 113 tests with 2 failures and 3 errors in 0.427 seconds. > > According to your attached screen dump you ran "bin/test - > sProducts.GenericSetup". I'm wondering why you only show 113 tests > being run. I get 459 tests with that command line on my setup. I trimmed off the tests which didnt fail. The total in 456, with 2 failures and 3 errors. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJmcvU+gerLs4ltQ4RAiv5AJ0flH4vfISr3h5mofK8YJERwE5YDgCfbVzB MI5JfRUni20/Lm6rn9zTsW4= =VDjk -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] GenericSetup test failures on Python 2.5's tarfile
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Anybody have a clue what changed in the Python 2.5 tarfile module which
triggers these failures?
> [/home/tseaver/projects/CMF/CMF.buildout-trunk]
> $ bin/test -s Products.GenericSetup
> Running Testing.ZopeTestCase.layer.ZopeLite tests:
> Set up Testing.ZopeTestCase.layer.ZopeLite in 0.091 seconds.
>
>
> Failure in test test_getLastModified_directory
> (Products.GenericSetup.tests.test_context.TarballImportContextTests)
> Traceback (most recent call last):
> File "/home/tseaver/projects/Zope-CVS/lib/python2.5/unittest.py", line 260,
> in run
> testMethod()
> File
> "/home/tseaver/projects/CMF/CMF.buildout-trunk/src/Products.GenericSetup/Products/GenericSetup/tests/test_context.py",
> line 601, in test_getLastModified_directory
> self.assertEqual( ctx.getLastModified( SUBDIR ), WHEN )
> File "/home/tseaver/projects/Zope-CVS/lib/python2.5/unittest.py", line 334,
> in failUnlessEqual
> (msg or '%r != %r' % (first, second))
> AssertionError: None != DateTime('2004/01/01')
>
>
>
> Failure in test test_isDirectory_subdir
> (Products.GenericSetup.tests.test_context.TarballImportContextTests)
> Traceback (most recent call last):
> File "/home/tseaver/projects/Zope-CVS/lib/python2.5/unittest.py", line 260,
> in run
> testMethod()
> File
> "/home/tseaver/projects/CMF/CMF.buildout-trunk/src/Products.GenericSetup/Products/GenericSetup/tests/test_context.py",
> line 643, in test_isDirectory_subdir
> self.assertEqual( ctx.isDirectory( SUBDIR ), True )
> File "/home/tseaver/projects/Zope-CVS/lib/python2.5/unittest.py", line 334,
> in failUnlessEqual
> (msg or '%r != %r' % (first, second))
> AssertionError: None != True
>
>
>
> Error in test test_listDirectory_multiple
> (Products.GenericSetup.tests.test_context.TarballImportContextTests)
> Traceback (most recent call last):
> File "/home/tseaver/projects/Zope-CVS/lib/python2.5/unittest.py", line 260,
> in run
> testMethod()
> File
> "/home/tseaver/projects/CMF/CMF.buildout-trunk/src/Products.GenericSetup/Products/GenericSetup/tests/test_context.py",
> line 717, in test_listDirectory_multiple
> self.assertEqual( len( names ), 2 )
> TypeError: object of type 'NoneType' has no len()
>
>
>
> Error in test test_listDirectory_single
> (Products.GenericSetup.tests.test_context.TarballImportContextTests)
> Traceback (most recent call last):
> File "/home/tseaver/projects/Zope-CVS/lib/python2.5/unittest.py", line 260,
> in run
> testMethod()
> File
> "/home/tseaver/projects/CMF/CMF.buildout-trunk/src/Products.GenericSetup/Products/GenericSetup/tests/test_context.py",
> line 699, in test_listDirectory_single
> self.assertEqual( len( names ), 1 )
> TypeError: object of type 'NoneType' has no len()
>
>
>
> Error in test test_listDirectory_skip
> (Products.GenericSetup.tests.test_context.TarballImportContextTests)
> Traceback (most recent call last):
> File "/home/tseaver/projects/Zope-CVS/lib/python2.5/unittest.py", line 260,
> in run
> testMethod()
> File
> "/home/tseaver/projects/CMF/CMF.buildout-trunk/src/Products.GenericSetup/Products/GenericSetup/tests/test_context.py",
> line 740, in test_listDirectory_skip
> self.assertEqual( len( names ), 1 )
> TypeError: object of type 'NoneType' has no len()
>
> Ran 113 tests with 2 failures and 3 errors in 0.427 seconds.
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJmawT+gerLs4ltQ4RAp+OAKCDQ12U6OhZgGz0o49IiUE0JSW2hgCfVw0V
2aC5puF5Y27LDKTkdUrJyTM=
=xxVI
-END PGP SIGNATURE-
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFDefault/trunk/setup.py - dependency cleanup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: > > On Feb 16, 2009, at 17:44 , Tres Seaver wrote: > >> Can somebody explain the dependency on DCWorkflow's ZCML getting >> loaded? >> This seems like it should be ripped out: no tests should need to get >> actaul DCWrolfow instances configured. Or are we trying to run >> functional tests against a site configured from a profile which uses >> DCWorkflow? > > Well, the use of the DCWorkflow profile is indirect. > CMFDefault.testing defines a functional test layer that instantiates a > portal using the CMFDefault default profile. Without loading the > DCWorkflow profile, workflow creation fails with the traceback below. Thanks, I had just chased that down myself. I have the sense that CMFDefault is probably ripe for a split: all the code which backs persistent objects (content types, the site itself, the tools) should stay, but the part which actually provides the default baseline profile should maybe be split out. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJmaT9+gerLs4ltQ4RAkr1AJ4yo2tW6q9juSZ8qntz2TLVS488IACeJaaN GZXjUslc1Gf/bWkUog4iJek= =gVze -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFDefault/trunk/setup.py - dependency cleanup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yvo Schubbe wrote: > Log message for revision 96580: > - dependency cleanup > > Changed: > U Products.CMFDefault/trunk/setup.py > > -=- > Modified: Products.CMFDefault/trunk/setup.py > === > --- Products.CMFDefault/trunk/setup.py2009-02-16 10:42:54 UTC (rev > 96579) > +++ Products.CMFDefault/trunk/setup.py2009-02-16 10:43:09 UTC (rev > 96580) > @@ -45,14 +45,18 @@ >setup_requires=['eggtestinfo', > ], >install_requires=[ > - #'Zope >= 2.10.4', >'setuptools', > + #'Zope2 >= 2.10.4', >'Products.CMFCore', > - 'Products.DCWorkflow', >'Products.GenericSetup', >], > - tests_require=['zope.testing>=3.7.0', > -], > + tests_require=[ > + 'zope.testing >= 3.7.0', > + 'Products.DCWorkflow', > + ], > + extras_require = dict( > + test = ['Products.DCWorkflow'], > + ), Can somebody explain the dependency on DCWorkflow's ZCML getting loaded? This seems like it should be ripped out: no tests should need to get actaul DCWrolfow instances configured. Or are we trying to run functional tests against a site configured from a profile which uses DCWorkflow? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJmZfZ+gerLs4ltQ4RAhaEAKCwoZOfwjbjfltvdHOdAQ8OvQeFEgCfQDGp V2pNxMBXIYLVWBsaei2/y5k= =Sbzi -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] five.localsitemanager: dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: > Tres Seaver wrote: >> Charlie Clark wrote: >>> Am 12.02.2009 um 14:45 schrieb yuppie: >>>> 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? >>> I'm not that familiar with Buildout but I would have thought that any >>> direct import dependencies should be listed - and zope.location >>> doesn't seem to be (neither are zope.event or zope.site for that >>> matter). OTOH the condition >= seems to be being incorrectly >>> interpreted. If this is a bug then it should be filed. >> The transitive dependencies of another dependency don't need to be >> listed: the problem Yuppie was fixing was a set of over-specific >> dependencies, now redundant in the new, egg-centric world of Zope 2.12. >> I think another fix would be to move the Zope2 import to the top of the >> list, so that its own, more specific dependencies would be installed >> first: however, I don't see much win over Yuppie's fix. > > My main reason for specifying all direct dependencies of any package > (and not just the Zope2 one) is that relying on transitive dependencies > can cause trouble later on. > > For example: > > Package A depends on Zope2 (2.12) > Package A depends on zope.app.foobar > Zope2 2.12 depends on zope.app.foobar > > You could specify that package A only depends on Zope2. > > But what if Zope2 2.13 does no longer depend on zope.app.foobar? > > Suddenly you try to install Package A and import statements for > zope.app.foobar break. > > With zope.app.foobar it is probably easier to see how such a package > could be removed later on (say it has been renamed to zope.foobar or > split into multiple packages) but it really can happen to any package. > > In a package based world, if you specify a dependency on a package, you > can in my opinion only rely on the package contents itself to be there. > You cannot rely on its dependencies to stay around. > > Zope2 the package is no different in this. Chances are that > zope.location will stay a dependency of Zope2 for a long time, but for > other packages it is far less clear. My answer to this is to always > specify all direct dependencies. The point in Yuppies changes is that the already-specified dependencies *broke anyeay* with Zope 2.12, because of details of ordering inside setuptools. Specifing *any* version requirements (even '>=x.y') is impossibly fragile outside the context of a tightly-controlled index (at which point the version requirements are redundant, and should be removed). As I said earlier: five.localsitemanager should just be made part of the Zope2 trunk: it is tightly-coupled to Zope2, and its presence as a separate pacakge is just confusing and error-prone. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJmDoS+gerLs4ltQ4RAlkVAJ0c14H5duToioqUYi6CCoM0PTeGewCgjzJH YlJg6uNLQeqfPxuN4hYleGw= =PcWY -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] five.localsitemanager: dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charlie Clark wrote: > Am 14.02.2009 um 20:33 schrieb Tres Seaver: > >> Given that package's job in life, I strongly doubt that we need to >> worry >> about anybody using it outside of a Zope2 app. In fact, I think it >> might be a good idea just to fold the package back into Zope2 (I don't >> recall why it ever shipped separately). > > If it is Zope2 specific then it should be part of Zope2: it's > monolithic but we love it anyway. > >>> I'm not that familiar with Buildout but I would have thought that any >>> direct import dependencies should be listed - and zope.location >>> doesn't seem to be (neither are zope.event or zope.site for that >>> matter). OTOH the condition >= seems to be being incorrectly >>> interpreted. If this is a bug then it should be filed. >> The transitive dependencies of another dependency don't need to be >> listed: the problem Yuppie was fixing was a set of over-specific >> dependencies, now redundant in the new, egg-centric world of Zope >> 2.12. >> I think another fix would be to move the Zope2 import to the top of >> the >> list, so that its own, more specific dependencies would be installed >> first: however, I don't see much win over Yuppie's fix. > > > Yuppie's suggestion is fine with me and probably the second solution > best solution aside from just making it part of Zope2. > > But that doesn't stop a bug being a bug. Dieter suggests that the bug > is with setuptools which gives it plenty of company. as far as I know. > Life used to be so simple with just distutils ;-) LOFL. Sure, "back in the day...", "You kids get off my lawn!", etc. For all its flaws, setuptools fixes a lot of what is horribly broken in distutils: most of the flaws arise from the choice to stay pseudo-compatible with distutils, and reuse it, rather than starting from scratch. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJl3Bg+gerLs4ltQ4RAnnNAJ9MLRXchbp2T2JEb8Kt6XAQuEu+igCgnZXD TtCtJw2kVgeQUmKO6AwIq0Y= =Kzxx -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] five.localsitemanager: dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charlie Clark wrote: > Am 12.02.2009 um 14:45 schrieb yuppie: > >> 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? > > > Only for someone wishing to use it totally outside of a Zope context. Given that package's job in life, I strongly doubt that we need to worry about anybody using it outside of a Zope2 app. In fact, I think it might be a good idea just to fold the package back into Zope2 (I don't recall why it ever shipped separately). > I'm not that familiar with Buildout but I would have thought that any > direct import dependencies should be listed - and zope.location > doesn't seem to be (neither are zope.event or zope.site for that > matter). OTOH the condition >= seems to be being incorrectly > interpreted. If this is a bug then it should be filed. The transitive dependencies of another dependency don't need to be listed: the problem Yuppie was fixing was a set of over-specific dependencies, now redundant in the new, egg-centric world of Zope 2.12. I think another fix would be to move the Zope2 import to the top of the list, so that its own, more specific dependencies would be installed first: however, I don't see much win over Yuppie's fix. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJlxyD+gerLs4ltQ4RAnMhAKCVNpXav5TpO17EQDJKPeIE/JLC1wCfVzWY maFcuCWJJY09WMDwxsYz4G4= =wJCe -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] five.localsitemanager: dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: > 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? +1. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJlKfT+gerLs4ltQ4RAgZFAJ0ZNyJFpo9WvxO5Vcf9JgXY0blg1QCfUgRL qA7WkCZrozsOzpL1LioB5RE= =grhc -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Accessing skins objects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charlie Clark wrote: > Am 09.02.2009 um 18:53 schrieb Tres Seaver: > >> This is talking directly to Zope (no Varnish / Squid in front?) >> Please >> post the PythonScript, too. > > Yep, this is a local wget talking directly to Zope. > > The PythonScript is: > > request = context.REQUEST > styles = [] > styles.append(getattr(context, > 'content_global.css').index_html(request, request.RESPONSE)) > styles.append(getattr(context, 'default.css').index_html(request, > request.RESPONSE)) > #... lots more file > > return "\n".join(styles) > > Now the profile results: > 1) View > 4499 function calls (4476 primitive calls) in 0.110 CPU seconds > > 2) PythonScript > 12830 function calls (12786 primitive calls) in 0.154 CPU seconds > > The 3:1 ratio is probably down to the way index_html works for the > files. > > So the PythonScript is more CPU intensive but also delivers faster. > Going on what you suggested yesterday I suspect the difference is down > to how the request is written to. I'll see if I can get something > working with that IFilestreamIterator you suggested. You could try changing the view to call 'index_html' instead of '__str__', and see if that helps. If it does, then I think there must be a RAM cache in play somewhere. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJkYLJ+gerLs4ltQ4RAoyoAKDRBVwqzviiNT0W1l28290kE8cx+gCgh6xo HU3bZxYwmO9p44ZXWolrJiY= =NaD1 -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Accessing skins objects
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Charlie Clark wrote:
> Am 09.02.2009 um 16:10 schrieb Tres Seaver:
>
>> Try profiling the two requests and see what looks different.
>
> I thought someone might say that... ;-)
>
> As heavy upstream caching is likely to be used I hope it's not
> necessary to optimise this too much. The main advantage is reducing
> the number of individual requests made by the browser when it first
> sees the site. But I should get more familiar with profiling.
>
> Running locally wget gives rates of around about 50 MB/s with the view
> and around 120 MB/s for a PythonScript.
This is talking directly to Zope (no Varnish / Squid in front?) Please
post the PythonScript, too.
>> The FSFile
>> object *never* stores the bits read from the filesystem, so the more
>> likely case is that your view is hitting some other bottleneck.
>
> oh, what FS things are affected by the debug-mode flag that forces
> them to be reread?, ie. which objects don't reflect underlying file-
> system changes?
Other FS objects may have cached information computed from the file
(e.g., the compiled template bytecode for an FSPageTemplate, or bytecode
for an FSPythonScript). But there is nothing which reads FSFile data
into memory and holds it. both its '__str__' and its 'index_html'
reread the file from dist. However, the object *may* be cached by a
RAMCache or an AcceleratedHTTPCache, if one is configured.
If Globals.DevelopmentMode is enabled, then the call to '_updateFromFS'
in both of those methods ('__str__', 'index_html') removes the object
from the cache on each request.
>> BTW, it might be faster to compute the *filenames* in the memo, and
>> then
>> return an IFilestreamIterator which chunked the response by reading
>> the
>> files one at a time. Running 'cat /path/to/fsidr/*.js' in an
>> os.system() call might be faster, too ;)
>
>
> I quite like the iterator idea.
> BTW. Can I admit at this stage that I
> don't really understand what the memoize method does? 8-)
It caches the result of the method call in the view's instance
dictionary. Be *sure* to use it only for views: using it on a content
objecct would be disastrous.
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJkG2n+gerLs4ltQ4RAm3eAJ0eCpjGwEDE3ovCGxolURMiNwbtnwCgwQ0R
tOugGBjiygq91cV9wJ5gmHQ=
=2qJn
-END PGP SIGNATURE-
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Accessing skins objects
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Charlie Clark wrote:
> Hi,
>
> I've written a very simple view for concactenating resources such as
> CSS or Javascript files to reduce the number of http browser requests:
>
>
> from Products.CMFCore.utils import getToolByName
> from Products.CMFDefault.browser.utils import memoize, ViewBase
>
> class Javascript(ViewBase):
> """Return all Javascript from the skin as a single string"""
>
> folder_name = 'js'
> content_type = 'application/x-javascript'
>
> @memoize
> def contents(self):
> skin_tool = getToolByName(self.context, 'portal_skins')
> layer = skin_tool.getDefaultSkin()
> skin = skin_tool.getSkinByName(layer)
> folder = getattr(skin, self.folder_name)
> obs = [str(ob) for ob in folder.objectValues()
> if ob.meta_type == "Filesystem File"]
> return "\n".join(obs)
>
> def __call__(self):
> data = self.contents()
> self.request.response.setHeader("Content-Type",
> self.content_type)
> self.request.response.setHeader("Content-Length", len(data))
> self.request.response.write(data)
>
> While this works fine, it seems to run considerably slower (about half
> the speed) than a PythonScript that calls the relevant objects
> explicitly via getattr(context, id). I'm a bit surprised at this but
> suspect it may down to whether the file system is actually accessed or
> whether a persistent object is being called. In my browser view it is
> impossible to avoid reading in the file again as this happens the
> __str__ method of the FSFile object.
>
> In the hope of enlightenment.
Try profiling the two requests and see what looks different. The FSFile
object *never* stores the bits read from the filesystem, so the more
likely case is that your view is hitting some other bottleneck.
BTW, it might be faster to compute the *filenames* in the memo, and then
return an IFilestreamIterator which chunked the response by reading the
files one at a time. Running 'cat /path/to/fsidr/*.js' in an
os.system() call might be faster, too ;)
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJkEdT+gerLs4ltQ4RApmBAJ4teYF55sK0pKu6uarUXBelhg6dXwCfcT5P
GVaGJKF4i1KD+JJTWkm1qOA=
=nq9A
-END PGP SIGNATURE-
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Weird catalog behaviour
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charlie Clark wrote: > Am 28.01.2009 um 15:44 schrieb Andreas Jung: > >> Command-line (zopectl debug?): you're anonymous >> ZMI: you're authenticated >> >> The catalog adds additional filters under the hood in order to filter >> out content you are not allowed to see. > > > That could be the explanation - how can I authenticate myself in > zopectl debug? You can also call the 'unrestrictedSearchResults' method from trusted code (e.g., the debugger): it bypasses those checks. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJgML6+gerLs4ltQ4RAtbpAJ4mUe+r+JYPiaKhIS3d0NBtJcZQZgCgiswu 8Q3IN6aFKTQ08aSNXUOF2as= =YqHX -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFDefault/trunk/Products/CMFDefault/__init__.py Move clashing imports into body of initialize().
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: > Hi Tres! > > > Tres Seaver wrote: >> yuppie wrote: >> >>> Tres Seaver wrote: >>>> Log message for revision 94389: >>>> Move clashing imports into body of initialize(). >>>> >>>> Changed: >>>> U Products.CMFDefault/trunk/Products/CMFDefault/__init__.py >>> What are "clashing imports"? Can't they be fixed in an other way? I'd >>> prefer to have less code in initialize(), not more. >> Importing anything at module scope in the __init__ can shadow the >> "proper" import paths. I would rather do *nothing* at import time, and >> then do any necessary imports inside the 'initialize', i.e., as late as >> possible. An alternative would be to import 'initialize' itself from >> another module. > > Well. The initialize() pattern is Zope 2 Products specific. I'm fine > with moving everything that isn't useful outside initialize() into that > function. > > But some imports in __init__ have (also) a different purpose: They make > sure security is initialized correctly. Moving those imports inside > initialize() makes it less predictable when security is initialized. > >>> Running CMF trunk tests with Zope 2.10, I now get random test-module >>> import failures like this one: >>> > [...] >>> Digging a bit deeper, I found a circular import in Zope that causes >>> these failures: >> My bad: I hadn't tested with non-trunk Zopes. We might get away with >> saying that CMF 2.2 requires at least Zope 2.11, but I think they would >> break there too. > > Yes. I see the same issue with Zope 2.11. > > I propose to fix this in Zope 2.10 and 2.11. And to make the latest > Version of Zope 2.10 or 2.11 required for CMF 2.2. Sounds fine. >>> AccessControl.Permission uses ApplicationDefaultPermissions defined in >>> App.class_init and App.class_init imports AccessControl.Permission. >>> >>> AFAICS moving ApplicationDefaultPermissions to AccessControl.Permission >>> would be the best way to fix this. >> Yes, there is a bunch of stuff in App which doesn't belong there. >> Unmasking it (by ripping out the imports from Globals) was a first step >> to moving it into the right location. > > Do you want to change that as part of your Zope refactoring or should I > check in my fix? I think we could put your fix in on the Zope 2.10 and 2.11 branches, as well as on my no_globals_imports branch. I'm not ready to commit to the other cleanups right now. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJWS8t+gerLs4ltQ4RAqivAKDKnh4CHnUT6ztd1uFTMUpBedOgwQCfT1Ou 1tA0QihSVKrUHBvkxR/dPew= =sDtT -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Cleaning up imports, question about odd "feature"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charlie Clark wrote: > Am 27.12.2008 um 20:03 schrieb Jens Vagelpohl: > >> I always thought it was there to continually re-read the filesystem >> representation upon access, so any filesystem changes are reflected >> without restarting the instance. As to the usefulness, I'm not relying >> on it when I do development. I always restart. > > If this is the case then it would be nice to have some way of > preserving that behaviour. We have a few people working almost > exclusively working with templates on Windows systems where restarts > are particularly slow. However, PageTemplates are probably the only > objects it's worth preserving this kind of behaviour for. As Jens noted, this change is for FSProperties and FSSQLMethods only. > On another and only slightly related note: Tres, in September I seem > to remember you saying that the biggest stumbling block for moving to > Python 2.5 and beyond was support for RestrictedPython implements, ie. > PythonScripts. If this is the case, do we need to add deprecating > PythonScripts/untrusted code to the roadmap? I don't have that appetite at the CMF level: I think much of the work has actually been done to ensure that RP works under Python 2.5+ already at the Zope level. >>> from AccessControl import ClassSecurityInfo >>> >>> becomes: >>> >>> from AccessControl.SecurityInfo import ClassSecurityInfo >> +1 > > > I didn't realise this counts as a relative import but I'm all in > favour of spelling things out. That one isn't relative: it is just another "façade" import. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJWRTd+gerLs4ltQ4RAoHsAKCo5zw04ztXiDFGK9kqtc/mgqWesACgohZb rUgUCzvuwrXNmaVGkM9gN4w= =1ZzP -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFDefault/trunk/Products/CMFDefault/__init__.py Move clashing imports into body of initialize().
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: > Tres Seaver wrote: >> Log message for revision 94389: >> Move clashing imports into body of initialize(). >> >> Changed: >> U Products.CMFDefault/trunk/Products/CMFDefault/__init__.py > > What are "clashing imports"? Can't they be fixed in an other way? I'd > prefer to have less code in initialize(), not more. Importing anything at module scope in the __init__ can shadow the "proper" import paths. I would rather do *nothing* at import time, and then do any necessary imports inside the 'initialize', i.e., as late as possible. An alternative would be to import 'initialize' itself from another module. > Maybe related: > > Running CMF trunk tests with Zope 2.10, I now get random test-module > import failures like this one: > >Module: Products.CMFActionIcons.tests.test_exportimport > >Traceback (most recent call last): > File "..\Products\CMFActionIcons\tests\test_exportimport.py", line > 24, in ? >from Products.CMFCore.testing import ExportImportZCMLLayer > File "..\Products\CMFCore\__init__.py", line 18, in ? >import PortalFolder > File "..\Products\CMFCore\PortalFolder.py", line 26, in ? >from App.class_init import default__class_init__ as InitializeClass > File "..\lib\python\App\class_init.py", line 16, in ? >import AccessControl.Permission > File "..\lib\python\AccessControl\Permission.py", line 18, in ? >import string, Products, Globals > File "..\lib\python\Globals\__init__.py", line 23, in ? >import Acquisition, ComputedAttribute, App.PersistentExtra, os > File "..\lib\python\App\PersistentExtra.py", line 24, in ? >from class_init import default__class_init__ >ImportError: cannot import name default__class_init__ > > > Digging a bit deeper, I found a circular import in Zope that causes > these failures: My bad: I hadn't tested with non-trunk Zopes. We might get away with saying that CMF 2.2 requires at least Zope 2.11, but I think they would break there too. > AccessControl.Permission uses ApplicationDefaultPermissions defined in > App.class_init and App.class_init imports AccessControl.Permission. > > AFAICS moving ApplicationDefaultPermissions to AccessControl.Permission > would be the best way to fix this. Yes, there is a bunch of stuff in App which doesn't belong there. Unmasking it (by ripping out the imports from Globals) was a first step to moving it into the right location. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJWQVJ+gerLs4ltQ4RAjCFAJ9iaQEdqXOg51vtEbkVtLdA7ibeogCePSQs b1DvuGnFKL+s9LkLGHDHdNw= =ByOP -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] Cleaning up imports, question about odd "feature"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After spelunking through the maze of imports in the Zope2 core indirected throught the Globals module, I resolved to rip out all such imports (see a separate thread on zope-deve). I also want to clean them out of the CMF trunk, and so have been hunting through code which does 'from Globals import' and 'import Globals'. I have found a couple of oddities: both CMFCore.FSPropertiesObject and CMFCore.FSSQLMethod use Globals.Development mode to decide whether or not to give their class an '__of__' method. I don't recall the rationale, but it has been around *forever*, AFAICT. I would like to rip it out, and just make the '__of__' method there always, unless somebody has a good argument for the current status. I also plan to make all the currently relative imports absolute, since relative imports break under later versions of Python, and I am making some of them more precise: e.g.: from AccessControl import ClassSecurityInfo becomes: from AccessControl.SecurityInfo import ClassSecurityInfo This is largely in aid of improving the dependency analysis of the parts of the Zope2 core, but I think the practice is better, anyway. Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJVne1+gerLs4ltQ4RAiTeAJoDTy4CkmD3nJu5UDx2EPPR2FQYNgCfYpqm mJnaA/TX1ZTcOm8Qzq6JMYw= =T1st -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMFCatalogAware.dispatchToOpaqueItems madness
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres Seaver wrote:
> Matt Hamilton wrote:
>> I really don't understand this code, so maybe I'm missing something here, but
>> anyone know wtf the opaqueItem code does in CMFCore.CMFCatalogAware?!
>
> It allows propagating IObjectEvents to nested objects not findable via
> the normal "content items" interface: the one example in the CMF is the
> 'talkback' attribute which holds DiscussionItems for an object.
>
>> Why does the opaqueItems method iterate through *every* attribute in the
>> root of
>> the site causing all objects (including, at least in plone) all sub-objects
>> of
>> folders to be woken up too):
>
>> for name in self_base.__dict__.keys():
>> obj = getattr(self, name)
>> if ICallableOpaqueItem.providedBy(obj) \
>> or z2ICallableOpaqueItem.isImplementedBy(obj):
>> items.append((obj.getId(), obj))
>
>> If it is looking for opaque items (I still don't know what these really are)
>> then why does it look in content objects too?!
>
> The 'opaqueItems' method in CMFCatalogAware is called only by the
> 'opaqueIds' and 'opaqueValues' methods in the same class. The
> 'opaqueIds' method is never called in stock CMF at all. The
> 'opaqueValues' method is called by the event subscriber which dispatches
> IObjectEvents.
>
>> How about the changes below?
>
>> objectids = dict([(x,1) for x in self.objectIds()])
>>
>
>> for name in self_base.__dict__.keys():
>> if name not in objectids:
>>
>
>> obj = getattr(self, name)
>> if ICallableOpaqueItem.providedBy(obj) \
>> or z2ICallableOpaqueItem.isImplementedBy(obj):
>> items.append((obj.getId(), obj))
>
>> (that was probably all wrapped to hell)
>
>> Basically, I've got a production site which loads up several tens of
>> thousands
>> of objects from the ZODB just to display the front page. Madness.
>
> AFAIK, that stuff should have no impact on rendering the front page of
> your site: the event handler should only be triggered on IObjectEvents
> emitted for an object, which will typically only be on writes. You
> wouldn't be doing a write-on-read for every rendering of the homepage,
> would you? If so, you have way worse problems than this bit of code.
OK, my bad here: the *real* problem is that the event handler is
registered promiscuously for IObjectEvent, which turns out to get fired
a *lot*: BeforeTraversal event is the one which is affecting you.
The *only* events of real interest for opaque subobjects are the "added"
/ "cloned" / "removed" events, which already have their own event
handler ('handleOpaqueItemEvent'). The BeforeTraversal event should not
be propagaged to subitems at all.
The attached patch registers that handler for only the objects it should
properly care about. Can you verify that it makes your pain abate?
In any case, we need to review *all* of the event handlers registered
for IObjectEvent by the CMF.
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJTLvP+gerLs4ltQ4RAnnNAJ4sqG5LmmABuBWtNOA72O5FT5smTACdH/8Z
oUc8kMVUPVvt1wIhIH0h4OA=
=FkC7
-END PGP SIGNATURE-
Index: CMFCore/event.zcml
===
--- CMFCore/event.zcml (revision 93091)
+++ CMFCore/event.zcml (working copy)
@@ -27,11 +27,29 @@
+
+
+
+
+
+ ___
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] CMFCatalogAware.dispatchToOpaqueItems madness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Hamilton wrote: > I really don't understand this code, so maybe I'm missing something here, but > anyone know wtf the opaqueItem code does in CMFCore.CMFCatalogAware?! It allows propagating IObjectEvents to nested objects not findable via the normal "content items" interface: the one example in the CMF is the 'talkback' attribute which holds DiscussionItems for an object. > Why does the opaqueItems method iterate through *every* attribute in the root > of > the site causing all objects (including, at least in plone) all sub-objects of > folders to be woken up too): > > for name in self_base.__dict__.keys(): > obj = getattr(self, name) > if ICallableOpaqueItem.providedBy(obj) \ > or z2ICallableOpaqueItem.isImplementedBy(obj): > items.append((obj.getId(), obj)) > > If it is looking for opaque items (I still don't know what these really are) > then why does it look in content objects too?! The 'opaqueItems' method in CMFCatalogAware is called only by the 'opaqueIds' and 'opaqueValues' methods in the same class. The 'opaqueIds' method is never called in stock CMF at all. The 'opaqueValues' method is called by the event subscriber which dispatches IObjectEvents. > How about the changes below? > > objectids = dict([(x,1) for x in self.objectIds()]) > > > for name in self_base.__dict__.keys(): > if name not in objectids: > > > obj = getattr(self, name) > if ICallableOpaqueItem.providedBy(obj) \ > or z2ICallableOpaqueItem.isImplementedBy(obj): > items.append((obj.getId(), obj)) > > (that was probably all wrapped to hell) > > Basically, I've got a production site which loads up several tens of thousands > of objects from the ZODB just to display the front page. Madness. AFAIK, that stuff should have no impact on rendering the front page of your site: the event handler should only be triggered on IObjectEvents emitted for an object, which will typically only be on writes. You wouldn't be doing a write-on-read for every rendering of the homepage, would you? If so, you have way worse problems than this bit of code. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJTLZZ+gerLs4ltQ4RAqNzAJwL2O6RpIkyKxTBKoGWQHlEnf4CaQCgngOG GrgKYfmdvTC/Jlz4oxuQ40s= =66GV -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup 1.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: > 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. I certainly plan to review all the docs: ideally, we would have a combination of explanatory, tutorial, and reference docs. >> - 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. Sounds OK to me: note that I have never yet used UpgradeSteps myself. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJQYyw+gerLs4ltQ4RAmdMAKCHDz3T9GEgmvH50D35ngzXuU5EngCfdjlO F3weQ5zXtbOnJ8GLjRtCUn4= =xUzm -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] GenericSetup 1.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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). - 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). Anyone have other stuff they would like to see in the mix (and can help land)? Tres. - -- ======= Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJQUtL+gerLs4ltQ4RAoDIAJ9HV0NtsTLj/HHxJRcmjeaRPuCI7ACfTQCF 9AF0Pk2jMOdmMTpvgb2ejME= =u2g+ -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] adding 'context' as an alias for 'object' in action expressions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
yuppie wrote:
> 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.
'context' is the canonical name for the object through which a script or
templated was acquired (its aq_parent, in fact); 'here' is a
long-deprecated alias for 'context'. 'context' is like the 'self'
binding of a normal Python method.
Action expressions aren't scripts / templates, and don't have many of
the stock names ('context', 'container', 'template', 'script',
'traverse_subpath', 'namespace', 'subpath', 'options', 'modules',
'root') which scripts and templates offer; instead, they offer names
which are useful in writing action URLs (e.g., 'object_url',
'folder_url', 'portal', 'user_id', etc.) Their 'self' / 'context' would
logically be the ActionInformation object, rather than the "target" for
which the URL / condition is being computed.
> And the proposal was to change the expression context for actions. What
> about CachingPolicyManager and DCWorkflow?
Exactly.
- -1 to the change from me. Writing TALES expressions involves knowing
what the appropriate set of names are for the given usage.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJNAeP+gerLs4ltQ4RArqDAJwMckHvg3WN4DG4tpECX47sfxedGgCg2SPB
qO8mWcKPawW7rPgRow89E3A=
=9PP6
-END PGP SIGNATURE-
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF write performance as poor as Plone?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ross Patterson wrote: > Tres Seaver <[EMAIL PROTECTED]> writes: > >> Ross Patterson wrote: >>> Tres Seaver <[EMAIL PROTECTED]> writes: >>> >>>> Andreas Jung wrote: >>>>> On 23.11.2008 11:57 Uhr, Charlie Clark wrote: >>>>>> Am 23.11.2008 um 09:24 schrieb Andreas Jung: >>>>>> >>>>>>> This issue is independent of the client-side. ab2 and cmf/plone were >>>>>>> running on the same (fast) machine. >>>>>> Is this really content that is suited for the ZODB? >>>>> I am talking of the standard content-types that are available in CMF and >>>>> Plone like Document, News etc. >>>> Are you trying to proceess feed content, one document per request? You >>>> should be batching up that content, to get better amortization of the >>>> indexing overhead. >>>> >>>> You should also be checking for conflict errors: they would result in a >>>> *large* performance hit. >>> Quick question. How much of the write concurrency problem comes from >>> the fact that the ZPublisher retries the entire *request* on >>> WriteConflict instead of just trying to committing the transaction >>> again? >> It can't retry the commit: the point is that the conflict can't be >> resolved using the values read from the database at the start of the >> transaction. We have to redo the whole request, re-reading any objects >> in the context of a new transaction; otherwise, we would be back to >> "last write wins", which is a lose. > > Not really what I meant, sorry for being unclear. I meant how much of > the write performance problem comes from the overhead of redoing the > whole request, rendering templates and such? I'm just wondering if > anyone has quantified that. I doubt anyone has done so: the results would likely be highly dependent on the specific application. Back in the day, the render-time penalty was one of the reasons I disliked self-posting forms (for updates): I preferred the "update-and-redirect" model, both to avoid rendering during / after the update, and also to avoid screwing up the browser cache with POST requests. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJKbJZ+gerLs4ltQ4RAr3fAKCbL7zElLcQ+ay8J3vl3EvUEwX0wQCfaEPY y12fwCwskKLPZy/a0hVrbvU= =gBMJ -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF write performance as poor as Plone?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ross Patterson wrote: > Tres Seaver <[EMAIL PROTECTED]> writes: > >> Andreas Jung wrote: >>> On 23.11.2008 11:57 Uhr, Charlie Clark wrote: >>>> Am 23.11.2008 um 09:24 schrieb Andreas Jung: >>>> >>>>> This issue is independent of the client-side. ab2 and cmf/plone were >>>>> running on the same (fast) machine. >>>> Is this really content that is suited for the ZODB? >>> >>> I am talking of the standard content-types that are available in CMF and >>> Plone like Document, News etc. >> Are you trying to proceess feed content, one document per request? You >> should be batching up that content, to get better amortization of the >> indexing overhead. >> >> You should also be checking for conflict errors: they would result in a >> *large* performance hit. > > Quick question. How much of the write concurrency problem comes from > the fact that the ZPublisher retries the entire *request* on > WriteConflict instead of just trying to committing the transaction > again? It can't retry the commit: the point is that the conflict can't be resolved using the values read from the database at the start of the transaction. We have to redo the whole request, re-reading any objects in the context of a new transaction; otherwise, we would be back to "last write wins", which is a lose. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJKaxt+gerLs4ltQ4RApTVAKDHRJBiEBOqedIh8bh27d7VJMMozQCfacFs jhNWzVm+L5XWHuK2XxNYlR4= =Xgr3 -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF write performance as poor as Plone?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Jung wrote: > On 23.11.2008 11:57 Uhr, Charlie Clark wrote: >> Am 23.11.2008 um 09:24 schrieb Andreas Jung: >> >>> This issue is independent of the client-side. ab2 and cmf/plone were >>> running on the same (fast) machine. >> >> Is this really content that is suited for the ZODB? > > > I am talking of the standard content-types that are available in CMF and > Plone like Document, News etc. Are you trying to proceess feed content, one document per request? You should be batching up that content, to get better amortization of the indexing overhead. You should also be checking for conflict errors: they would result in a *large* performance hit. Tres. - -- ======= Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJKVZL+gerLs4ltQ4RAtfYAJ4y11dcMlEFLJYKxcRCvI+qoWM3zgCg0Sh2 0CvciY+vn6F+XLC8eedAirs= =bmyq -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Missing Event Handler for CMFCatalogAware
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charlie Clark wrote: > Am 12.11.2008 um 11:53 schrieb yuppie: > >> This is the checkin that added CMFCatalogAware to PortalFolder: >> http://svn.zope.org/?rev=35114&view=rev > > Wow, that's some time ago. > >> It explains why and how it was done. Maybe a first step to clean >> this up would be to split CMFCatalogAware into separate mixins. Or take the responsibility out of the class altogether via event subscriptions. > I'm probably missing something but nothing related to IDiscussable > seems to be in either PortalFolder or CMFCatalogAware or is that the > OpaqueItem stuff? Yes: getting the 'talkback' object's items (the comments) catalogued was the point of the checkin. > You're probably right to suggest that this should be a two-step > change: clean-up CMFCatalogAware; remove it from PortalFolder (it can > stay in SkinnedFolder). If we made the bit about finding the opaque subitems part of the event subscriber, then we could remove the base class from PortalFolder directly. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJGtWn+gerLs4ltQ4RAgmxAJ9Oe57ZkVkRueZ4cU42Ku39Pzw0BACfRSwC XjlE1vpczfaMzGlbj1Gsi28= =MmON -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Pure CSS for main template
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charlie Clark wrote: > Am 06.10.2008 um 02:00 schrieb Jens Vagelpohl: > >> Please make sure you stick to one functionality/change per branch to >> make it easier for others to make a diff and understand all the >> changes. I thought you wanted to use the branch for the >> folder_contents work only ;-) > > oops, sorry! It's just I'd been planning to work on this for about a > year and yesterday was a good time to start. Should I create a > separate branch just for this? > >>> The idea is not to do >>> a redesign but to implement the existing one using CSS now that >>> pretty >>> much all of the browsers in use have at least adequate support. >>> Customers will hopefully still want to have a different design but it >>> should be easier to do. >> CMFDefault represents a simple sample application for the CMF. It >> doesn't have to be pretty by itself, but any changes should have these >> goals: >> >> - make it easier for people to customize the look-and-feel using CSS >> only, or... >> >> - make it easier to take the current main_template as a guideline >> for a new main_template by making it as simple and understandable as >> possible. > > I hope to achieve both of those. > >>> I'm using an "em" based elastic approach where the layout will "grow" >>> with the chosen text size. I know that most browsers have now caught >>> up with Opera and offer proper zooming but there are still lots of >>> IE6 >>> installs out there. I'm working on a baseline of 1024 x 768. Does >>> anyone have objections to this? >> I'd be opposed to any template that uses fixed widths and which does >> not degrade gracefully with less or more width. > > > hm, the current layout is fixed-width. The new one is not per se fixed- > width is driven by the size of the font that a user has. The argument > about growing and shrinking gracefully is important but it is also > important to maintain usability and particularly readability: having a > site expand to fit 100% can mean either extremely long lines or ugly > gaps between columns or conversely columns with line-breaks every > word. The following article covers the main issues concisely: > http://www.htmldog.com/articles/elasticdesign/ > > What I am to do is to maintain the current design but make it much > easier to adapt through CSS, ie. swap between font-size based and > percentages. So good documentation of how the layout works is essential. +1. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI6fv7+gerLs4ltQ4RAhMVAJ45Q/F8bULeypNSh4xtOs8i6fxFHACgmWG+ hvH/zoRSbG9AeLbajEpA3GU= =T1ks -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] using zope.dublincore in CMFCore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: > Currently CMFCore and zope.dublincore duplicate some of the DC > interfaces. zope.dublincore even has an ICMFDublinCore interface > explicitly dublicing CMFCore's version. > > Are there any objections to making the CMFCore interfaces derived > classes from zope.dublincore, or possibly even using those directly > where possible? - -0 unless we come up with convincing evidence that the Z3 version is actually being maintained by somebody who cares about it: Actually, after looking at it, -1 unless it is getting some love *and* we can avoid entangling ourselves with its policy-laden configure.zcml. Tres. - -- ======= Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI2RTV+gerLs4ltQ4RAqc+AJ9EfR/RcnCGxi8h+QDBD0+P2oxGsQCgnSzb I6WuWmqGs7u0IBKCG8OFBtk= =H/H7 -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMFActionIcons vs. new-style actions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
yuppie wrote:
> 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.
We could just use the aliases for that: essentially, they would be the
list of "valid" object actions for the object.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFI0m5Y+gerLs4ltQ4RAu2RAKDCKAuSHdnkIC+5qjptL5slo0byrgCfVkSw
omCTYtxKVO0MHF3b3RMdVWU=
=EvH7
-END PGP SIGNATURE-
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMFActionIcons vs. new-style actions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: > > On Sep 13, 2008, at 15:28 , Jens Vagelpohl wrote: > >> Question: Wouldn't it make sense to enable the new action icons >> functionality in the various templates to show icons if an expression >> for an icon is provided, and completely retire the CMFActionIcons >> product? > > 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 ;-) > > 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 > > - extend the DCWorkflow Transition and Worklist classes, which store > the information for their own action directly on the class, to have an > icon URL expression field > > - add a portal setting, also available through the "Reconfigure > portal" CMF screen, to switch the icons on or off globally. > > - change the basic main_template in CMFDefault/skins/zpt_generic to > look for the global icon flag and icon data from the actions > > - fix up some existing CMFActionIcons icons and search for a whole > bunch of additional icons > > I'm not the greatest artist in the world, if anyone dislikes a > particular icon please feel free to replace it with something that > makes sense to a normal user. Just make sure it has a transparent > background. Great! Thanks for the work! Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI0jsi+gerLs4ltQ4RAihDAJ0WUf/AStk+1CuBerC1LwslScPIOQCgs034 Ivd/7S7wWrdbkq105hFaVg4= =LOcM -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] add view traversal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: > 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. Here's my take: o -1 to using IAdding at all. If we use a URL like /container/+/typename, then the traverser could just use the next name after '+' to look up the adding view directly and return it. o +0 on 'container/+/typename'. o +1 on 'container/@@add/typename' o -1 on 'container/add/typname', or any URL token could conflict with "real" object IDs. o -0 on the '.html' suffic. o +0 on 'container/+typename': I don't think this will clash with anything in Z3: we just have to supply a traverser which does what I outlined above for 'container/+/typename'. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIzQiQ+gerLs4ltQ4RAo4WAKCcVH2ceg4yvs8FmAwWbCsrhBHTmwCgi7eO fGNT58nb9hZNn4RPJjiEPMQ= =rZJY -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Bug in FSPythonScript?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roché Compaan wrote: > In CMFCore.FSPythonScript.py around line 170 in the _exec method, a > volatile attribute is checked to see if a script has been compiled > properly. The lifetime of volatile attributes cannot be guaranteed > right, so I would assume that this code is not being careful enough. > This is the code I'm talking about: > > # Prepare the function. > f = self._v_f > if f is None: > # The script has errors. > __traceback_supplement__ = ( > FSPythonScriptTracebackSupplement, self, 0) > raise RuntimeError, '%s has errors.' % self._filepath > > I have a few Plone sites that work perfectly 99% of the time, but under > heavy load they raise RuntimeErrors on scripts at precisely this point > in the code. The only explanation seems to be that the volatile > attribute has lost its state. When I "customise" the scripts to force a > recompile it works again. > > Seems like a bug? I've never seen the behavior you report, but inspection suggests that an extra check would not hurt. E.g., before the 'if f is None' above, adding: if f is None: self._readFile(True) f = self._v_f should do the trick. If you can generate a patch for this, which includes a test (calling 'script._p_deactivate()' should mimic the behavior you are seing), I would be glad to merge it (assuming you don't have SVN privileges). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIwFDZ+gerLs4ltQ4RAnpvAKCV3e3C9TPOQiygwY/TtHn4e2DiawCgidlU DZakIRreq4bJejN8RgWbF9Y= =+jUJ -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Eggified CMF 2.1.1 now available
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wichert Akkerman wrote:
> Previously Jens Vagelpohl wrote:
>> On Aug 3, 2008, at 18:19 , Tres Seaver wrote:
>>
>>> I created "satellite" versions of the 2.1.1 eggs for the remaining CMF
>>> products this morning:
>>>
>>> - CMFDefault
>>> - CMFTopic
>>> - CMFActionIcons
>>> - CMFCalendar
>>> - CMFUid
>>> - DCWorkflow
>>>
>>> Source distributions for the 2.1.1 versions are now available on PyPI.
>> With there being no clear roadmap for 2.2 releases yet, would there be
>> any desire to move the 2.1 branch over to "new style" separate
>> products which would make it easier to release them as eggs? I would
>> have time to do this during a sprint later this month.
+0. Making new eggs from the monolithic checkout / satellites is not
going to be any harder than the following:
$ svn cp $ZSVN/Products.CMFDefault/tags/2.1.{1,2}
$ svn co $ZSVN/Products.CMFDefault/tags/2.1.2 CMFDefault-2.1.2
$ cd CMFDefault-2.1.2
$ vim setup.py # change version
$ svn propedit svn:externals Products # point to new monolith tag
$ svn commit
I don't really object to breaking the monolith up, however (replacing
the 'svn:externals' with real copies): most of the effort is going to
be in teasing apart changelog entries.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIoGzB+gerLs4ltQ4RAks+AKDTklxkF9O3l2p1FcsPqCMOr2NduQCdGN72
3ivYmZCyBFPtRIB1JKZe+uM=
=oNku
-END PGP SIGNATURE-
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] Re: Generic Setup metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Niederreiter wrote: > https://bugs.launchpad.net/zope-cmf/+bug/255301 Thanks. Fixes committed to 1.3 branch, 1.4 branch, and trunk. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIme3b+gerLs4ltQ4RArdRAJ9ewiaHE/cbYQCJgjGz1U1puK99SgCgwVEv CcIf2Tg3FB+fIc8RmEH5UsQ= =SLPC -END PGP SIGNATURE- ___ 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] Eggified CMF 2.1.1 now available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I created "satellite" versions of the 2.1.1 eggs for the remaining CMF products this morning: - CMFDefault - CMFTopic - CMFActionIcons - CMFCalendar - CMFUid - DCWorkflow Source distributions for the 2.1.1 versions are now available on PyPI. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIldqF+gerLs4ltQ4RArHvAJwJdHslGSI20crfqKe5WRjYEwtWFwCgxOZz MI1fj2+LRnR5Orxc6puv6jk= =yUkn -END PGP SIGNATURE- ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: > 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. +1. Seems a simple, straighforward extension, with zero BBB problems. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIhJgu+gerLs4ltQ4RAmZpAKCzp8t3m5Xf/NAq+ShK8tQwULR5LACgjhU+ oBdD84fizqzDGOmUFR5d9wI= =rcl2 -END PGP SIGNATURE- ___ 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: SVN: plone.z3cform/trunk/ Relicense and move plone.z3cform into Zope repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Nouri wrote: > Log message for revision 88331: > Relicense and move plone.z3cform into Zope repository Thanks very much, Daniel! Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIe29M+gerLs4ltQ4RAlXHAKCAxsPmf7rpELLGzXiQ/v4PKjtpnwCfaxJq T4w6hWeZFj1JAPwtpX8VsdI= =kRKC -END PGP SIGNATURE- ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: > Hi folks, > > 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. > > 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. > > 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. > > 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. Putting the policy in the typeinfo objects seems like a much saner place to keep this stuff than embedding it in a component registry. > Also, why not try to use the Zope 3 menu concept? There's even a special > "add menu" directive. The Z3 menu stuff seems to me bound up with the needs of the never-gonna-use-it Z3MI: it is overcomplicated for little purpose, and puts too much policy into "emergent" behavior (ordering of component lookups, for instance). > I'd quite like to find a good approach here that can be used by both > Plone and plain CMF, if possible. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIegPw+gerLs4ltQ4RAhheAKCQdKEg+O/y4OM42zYJQ5vHNJSRngCfagdO rUEaTSE/XFT6sw7sUTUgrQ8= =L3iv -END PGP SIGNATURE- ___ 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?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: > Tres Seaver wrote: > >> One point of the types.xml file is that the type name may *not* map >> intuitively onto the name of the XML file (people seem determined to >> embed spaces in object names, for instance). > > Sure. So now we rely on a not entirely obvious convention (space becomes > underscore) and/or redundant information in the per-type file itself. > >> It is also not a given >> that one knows unambiguously how to parse any give file in the types or >> workflows directories. > > Why not? > >> I strongly prefer the pattern that the tools state is stored in a common >> file, with per-object customization stored in separate files: "explicit >> is better than implicit". > > I don't think it's implicit to say that if we have a file in types/*.xml > with an id and a meta_type, then that object is created in portal_types > - with that id and meta_type - if it doesn't exist. > >> The redundant information is actually what >> Yuppie specified: the ID and metatype in the XML files. Dropping that >> information would be OK with me. > > Sure, that reduces redundancy, but it still means that the information > needed to install a type resides in two places, not once. > > It's not entirely non-redundant, though. The id of the thing in > types.xml and the filename have to match (with the space-to-underscore > mapping). > >> Note that both the workflow and the types tools *are* containers for >> arbitrary objects: there are cases in the wild, for instance, which >> deploy non-DCWorkflow objects as workflow definitiions, and which have >> non-standard type info objects. Using heuristic rules makes it harder >> to support such combinations. > > I'm not sure I understand why it's harder. I'm not really talking about > a heuristic, I don't think. Rather, I think the algorithm could be: > > - list all files in types/*.xml > - read id > - if it doesn't exist in portal_types: > -- read meta_type > -- create object of this type > - else: > -- fetch object with this id > - populate with type info > > As a bonus, we no longer depend on the file name matching the id 1:1. > > The assumption here is that types/*.xml is reserved for the standard > property-based type import/export handler. If I had a different type of > FTI with a different parser, I'd need to pick a different directory. > > I don't think that's any less reasonable than to say that types.xml (or > propertiestool.xml or whatever) is specific to the default types > import/export handler. > > Is there any documentation anywhere that explains what types.xml is > needed for and how it relates to types/*.xml? I've tried to explain to > people why we need both, and I can't come up with a compelling argument, > even after reading this thread. :-/ types.xml is the absolute requirement: it specifies what types the tool knows about, including those for which there may be no XML file at all in types/. *If* the metatype in types.xml causes a type object to be created which has a handler adapter registered for it, and that handler chooses, it may then read and parse any number of arbitrary files from the profile. The stock handlers for FactoryTypeInformation and ScriptableTypeInformation happen to read a single XML file, whose name is derived from the ID of the type. Likewise, workflows.xml is an absolute requirement. Non-DCWorkflows, for instance, may not have a corresponding subdirectory or definition.xml file (they might be implemented entirely via imperative logic). The handlers for DCWorkflows are responsible for finding an parsing the files in the subdirectory, including script files where they exist. The pattern is exactly the same for containers: the container's handler knows about what its objects are, and how to create them. The handlers for the individual objects can use zero or more additional files to configure the objects after they have been created and seated into the container. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIaFXT+gerLs4ltQ4RAjNLAJ4zvhgbfUtjGKfHUzC/rY5GvHnY9QCgijXm QX5tQtaYmAgRykdsFxOF0Cc= =zkH9 -END PGP SIGNATURE- ___ 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?
at 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. > >> 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. > > Mmmm I'm not sure I agree. Unless you happen to be intimately > familiar with the implementation of TypesTool and WorkflowTool and other > things, then these are not "the same" really. The use case is just to > register types and workflow definitions. Each of those has a custom > format anyway. > > In general, I think warning signals should go off when we require people > to type the same thing in more than one place or ensure that names > "match" across multiple files and file names. It's far too easy to make > mistakes, it's too easy to forget to change one during refactoring, and > it's hard to explain and document. The DRY (Don't Repeat Yourself) > principle that Grok has adopted is a great rule to live by. > > I can see that there may be edge cases (e.g. ordering - but even then > I'd rather there was an explicit directive to set the order) where we > can't make a sensible, unambiguous inference. For those, we should keep > the two-file format as an option. But I am pretty sure that no-one would > complain if they didn't have to maintain a types.xml or put workflow > definition lines in workflows.xml (obviously, bindings should stay there). One point of the types.xml file is that the type name may *not* map intuitively onto the name of the XML file (people seem determined to embed spaces in object names, for instance). It is also not a given that one knows unambiguously how to parse any give file in the types or workflows directories. I strongly prefer the pattern that the tools state is stored in a common file, with per-object customization stored in separate files: "explicit is better than implicit". The redundant information is actually what Yuppie specified: the ID and metatype in the XML files. Dropping that information would be OK with me. Note that both the workflow and the types tools *are* containers for arbitrary objects: there are cases in the wild, for instance, which deploy non-DCWorkflow objects as workflow definitiions, and which have non-standard type info objects. Using heuristic rules makes it harder to support such combinations. So, -1 to removing / deprecating types.xml and workflows.xml. +0 to removing the redundant / ignored attributes in the corresponding XML files for types and workflows. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIZ9hR+gerLs4ltQ4RAoewAJ96CC/sLjkqoAefA0b6Nyog6NptogCgpOIt yQLOHbzXzHdX0J9uScuzEc4= =xxgK -END PGP SIGNATURE- ___ 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: five.intid and DirectoryView
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Pieters wrote: > On Fri, Jun 27, 2008 at 6:53 PM, Ross Patterson <[EMAIL PROTECTED]> wrote: >> "Martijn Pieters" <[EMAIL PROTECTED]> writes: >>> But the code never does that. When cloning a file-based FSObject, a >>> new instance is created and that is added to the ZODB. Noone else >>> should do this either. >> zope.app.keyreference does. The persistence machinery doesn't add an >> object to a connection until commit. As such, an IPersistent and >> IObjectAdded event handler, such as the one in zope.app.intid, that >> needs the object to have a connection needs to add the object to a >> connection. Sounds like a bug in zope.app.intid to me: it shouldn't be forcing objects to have connections. > Why is the IObjectAdded event fired at all? Perhaps that's the bug here. > >> Shouldn't anything that implements IPersistent be able to be added to a >> connection? Wouldn't that be considered part of providing the >> interface? Where else is an object that provides IPersistent stored in >> global state? > > I assume it was easier at the time to use just one class. Perhaps this > should be reconsidered now. However, just providing the IPersistence > interface does not mean the object expects to be added to a connection > arbitrarily. Exactly. Nobody is supposed to add objects to a connection except their already-persisted containers. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIZlfe+gerLs4ltQ4RAoGOAJ954hDazoOKVj7TZKJQX84wB0LRUwCgox23 rjY5Q3Xjhu+eDcVnmmzXdjs= =pF+8 -END PGP SIGNATURE- ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Laurence Rowe wrote: > Laurence Rowe wrote: > >> To fix this we need to add a __bobo__traverse__ method to Skinnable that >> looks up objects in the order: >> >> 1. getattr(aq_base(obj), name), but excluding skin objects >> >> 2. views >> >> 3. getattr(aq_base(obj), name), including skin objects >> >> 4. getattr(obj, name) > > Hmm. It looks as if the __bobo_traverse__ method will require access to > the `restricted` argument to unrestrictedTraverse. I can't see any way > to access this other than: > > sys._getframe(1).f_locals['restricted'] > > Which is more than a little ugly. I don't get it: why isn't OFS.Traversable's check sufficient? __bobo_traverse__ has a bad enough (insane, actually) contract, without adding security checking to it. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIZldK+gerLs4ltQ4RAqvWAJ4zkDSAUzHLIfUqPtnCqCM1wTkHowCgwVs4 6zMF1gUxD7qVZ4y/i8dSHy4= =vy5T -END PGP SIGNATURE- ___ 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: License file question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: > Previously Maurits van Rees wrote: >> Wichert Akkerman, on 2008-05-29: >>> Previously Maurits van Rees wrote: >>>> Wichert Akkerman, on 2008-05-29: >>>>> Previously Maurits van Rees wrote: >>>>>> Wichert Akkerman, on 2008-05-29: >>>>>>> Previously Philipp von Weitershausen wrote: >>>>>>>>> But personally I like having it inside the "main" >>>>>>>>> folder, so in your example above it would be >>>>>>>>> incf.applications/incf/applications/HISTORY.txt >>>>>>>> There's some benefit to that because it'll be part of the egg. >>>>>>> You probably want to use a MANIFEST.in anyway and that can easily be >>>>>>> used to include everything in doc/ or other places. >>>>>> A 'python setup.py sdist' will include the docs directory, as long as >>>>>> it is in subversion (and has at least one file in it). >>>>> And when someone installs from that sdist and there is no MANIFEST.in >>>>> you suddenly end up with installs which are missing data files, zcml >>>>> files or other things. >>>> Is there a difference in that regard between easy installing an sdist >>>> or a bdist_egg? I would think/hope that the end result is the same. >>> Yes. If you make the bdist_egg from a svn checkout it includes all files >>> that are in subversion. If you make an egg from something else like a >>> sdist or a svn export that does not happen (since the svn information is >>> not available). >> Without a MANIFEST.in, the egg resulting from an sdist that is >> easy_installed is the same as a bdist_egg, right? Indeed when I try >> that for plone.portlet.static this is the case. So having a >> MANIFEST.in makes no real difference in that regard. > > I'm not sure what you mean. The basic algorihm is: > > - MANIFEST is used to determine what is installed, or > - subversion workingcopy information is used to determine what is installed, > or > - a default ruleset is used > > This algorithm is used at the moment a 'binary installation' is made, > which is either when you build an egg using setup.py bdist_egg or when > you install an egg from source (ie from a sdist or an unpacked tree). setuptools-generated sdist tarballs made from SVN checkouts get all the correct files in them when made into eggs / installed via setuptools, using the metadata in the .egg-info directory (SOURCES.txt, in particular). I think the only issue is for folks who would like to install your packages without having setuptools present. Voluntarily using bare distutils is already so masochistic that I don't feel much pity for the added pain. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIPvyA+gerLs4ltQ4RArTOAJ41EZT9T5oCXhlOOetfheckYEzS9gCghto7 ZXOQYIjFxkfJzugcLN7Gb+Y= =vZQp -END PGP SIGNATURE- ___ 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: Multiple GS profiles per product
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: > Hi. > > Maurits van Rees wrote: >> This is on Plone 3.0 with CMFQuickInstaller 2.0.4. > > I think you are on the wrong list here. QuickInstaller is a part of > Plone and not CMF and should be discussed on plone-dev. I'll give some > responses anyways ;) > >> Question 1: can I influence which profile is picked here? Should we >> add some code to the QuickInstaller.getInstallProfile(s) methods to >> for instance prefer a profile with a name like "productname:default"? > > Picking the first profile from the arbitrarily sorted list of profiles > is obviously a shortcoming of QI. The main problem here is that QI uses > the product name as a primary key for all its operations and thus can > only really handle one installation record for one product. The whole > use of extension profiles as installation procedures is a bit of a hack. > What should really happen and which I'll do for Plone 4.0 is to remove > the support for Extensions/Install.py and give up the one-to-one > relationship between products and installation records. What happens in > the end is that you apply configurations to a site - that can be as many > as you want with extension profiles. I just don't see a way on how to > move forward with this without a clear cut. > >> Now, I tested with eXtremeManagement 1.5.2, the latest stable release, >> in case anyone wants to try it out (remember to add a Poi 1.1 bundle >> too). That release also has Extensions/(App)Install.py files. I >> moved those out of the way and restarted. > > Why did you remove Extensions/Install.py? This one is supposed to take > precedence over extensions profiles. In your case having one, which > installs the GS profile you want internally should work just fine. Perhaps that supports QI better, but killing off *all* impoerative installation / configuration is a worthy goal (and one which has been neglected for far too long). >> Question 2: I am used to having a profiles directory in a product and >> a subdirectory inside it named 'default'. eXtremeManagement is the >> only product I know that has a second profile next to it. Are others >> using more than one profile? Well, CMFPlone does a few things here. > > Multiple profiles are common. I think I made the profiles/default thingy > the default value, when you don't provide one in ZCML, but that's all > the magic there is and should be. > >> Question 3: Should we encourage programmers to only use one profile, >> presumably simply in a directory named 'profile' by default? > > No. :) > >> In the case of eXtremeManagement, the day is saved because it still >> has an Extensions/Install.py. That is the installer that is actually >> executed and it has some code to run the correct profile, including a >> dependency. The only hickup so far is that with the newer QI the name >> of the other profile is listed instead of the default profile. > > That is a bug. I think someone added this code of taking the title from > the profile, shortly before the final and I missed to review it > properly. We should just revert those changes. If you have an > Extensions/Install.py nothing should be read from the profile database. > > Can you add a ticket for this last issue? I'm assuming that you mean against QI? Because I see nothing which needs changing in GS here. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIMMa++gerLs4ltQ4RApPZAJ95rSHFd4LWPKFwwPlKxWqNOqSkHQCgslKQ FdM1ddp9IkRE4jA9a30sP7o= =OAuv -END PGP SIGNATURE- ___ 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: [GenericSetup] "easy_install" reports "SyntaxError"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dieter Maurer wrote: > "easy_install"ing the current PyPI version of "Products.GenericSetup" (1.4.0) > reports: > > File > "/home/dieter/z211/z11python/lib/python2.4/site-packages/Products.GenericSetup-1.4.0-py2.4.egg/Products/GenericSetup/doc/SampleSite/profiles/default/siteroot/bar.py", > line 22 > return printed > SyntaxError: 'return' outside function That is a harmless but unavoidable error message: the distutils insistes on trying to compile all *.py files, even those which are not in any package (such as FSPythonScript implementations). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIMMZD+gerLs4ltQ4RAgcjAKDaRgy+3vILSU4AnD1HtlLSrSZV3QCgyCwv BWSsIS0Wx4Iv4Bt89Ygqo54= =0Ixq -END PGP SIGNATURE- ___ 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: Multiple GS profiles per product
re. Yes, I use multiple profiles. > Question 3: Should we encourage programmers to only use one profile, > presumably simply in a directory named 'profile' by default? No. The name 'default' should *definitely* not be majyk. > In the case of eXtremeManagement, the day is saved because it still > has an Extensions/Install.py. That is the installer that is actually > executed and it has some code to run the correct profile, including a > dependency. The only hickup so far is that with the newer QI the name > of the other profile is listed instead of the default profile. > > Meanwhile on trunk (and on the 1.6rc5 I released on the cheese shop > last night) I have removed the upgrade profile as I do not like the > side effects of having two profiles. > > > Hm, hiding profiles by using > Products.CMFQuickInstallerTool.interfaces.INonInstallable could be an > option too, now that I think of it. Should work. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFILcXV+gerLs4ltQ4RAjNCAJwOucCo9ReYq3IzCufEy66tHR6q+gCgz7zI Fa1hgTbGR1rN99/F4HRCUfk= =Q0j0 -END PGP SIGNATURE- ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: > 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. - -1 to managing dependencies in buildout-specific files: they belong in setup.py. >> 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. Given that setuptools is the only mechanism which *enforces* dependencies, spelling them in setup.py is not likely to cause any difficulties. I'm averse to packaging future versions of CMF in any form other than a setuptools-using sdist (no binaries, just the tarballs as generated by setuptools). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIDf8M+gerLs4ltQ4RAkjDAJ9FyZIueiZ6XNprX5wO5/XbN0Vx5ACeNys3 7K8x+E4dgL0oa8cBRO72QKo= =GYIm -END PGP SIGNATURE- ___ 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: GenericSetup 1.4 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: > On Mar 7, 2008, at 17:28 , Hanno Schlichting wrote: > >> The CMF trunk currently points to the five.lsm trunk, which doesn't >> have a version information inside it, as it only uses a part of the >> actual package. The version information is in the root setup.py, >> whereas CMF only pulls in the src/five/localsitemanager part of it. > > Other packages I know get around this problem by putting version > infomation into a proper version.txt file inside the actual code > folder and then reading it out to get at the value inside the toplevel > setup.py. If there's no specific reason why this is bad I'd suggest > that here as well. > > >> Why did we do the above at all? Because we didn't want to require >> anyone to install a package for the CMF 2.1 line on top of >> extracting the tarball into the Products folder. For CMF trunk I >> personally think it is OK, to state a proper dependency in setup.py >> for both CMF and GenericSetup now and remove the five.lsm inclusion >> hack from CMFCore. > > The dependency should be in setup.py and DEPENDENCIES.txt inside > CMFCore, it already exists there, I looked. I'm in favor of removing > the hack on the CMFCore trunk. I added the dependency in GenericSetup-trunk's setup.py and DEPENDENCIES.txt as well (committed this morning). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH0YEN+gerLs4ltQ4RAim7AKDdFIkOcLglbHf2DiL7Dksoi/Yf4QCgoTa9 sSr2u24j3s+JIjNnTeT1suc= =SGVc -END PGP SIGNATURE- ___ 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: GenericSetup 1.4 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: > Jens Vagelpohl wrote: >> There's an egg with version 0.3 on the cheeseshop, is that an acceptable >> version? I simply linked in what I had here from the current CMFCore >> trunk, but that external is against the five.localsitemanager trunk and >> the package itself contains no version information whatsoever >> (documentation foul!). > > The CMF 2.1 branch uses the five.lsm 0.3 tag, which is identical to the > trunk, except that trunk states it is going to be version 0.4. > > On PyPi there are both an egg as well as a source distribution for the > 0.3 release. > > The CMF trunk currently points to the five.lsm trunk, which doesn't have > a version information inside it, as it only uses a part of the actual > package. The version information is in the root setup.py, whereas CMF > only pulls in the src/five/localsitemanager part of it. > > Why did we do the above at all? Because we didn't want to require anyone > to install a package for the CMF 2.1 line on top of extracting the > tarball into the Products folder. For CMF trunk I personally think it is > OK, to state a proper dependency in setup.py for both CMF and > GenericSetup now and remove the five.lsm inclusion hack from CMFCore. +1. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH0YDY+gerLs4ltQ4RAqsCAJ44QyrLAeMlrEIyf0Iiw4Gszw6i/wCfRF7T z0ZhK+jTRjKCuuFm1GQgrNQ= =B/Vv -END PGP SIGNATURE- ___ 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: GenericSetup 1.4 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: > On Mar 7, 2008, at 13:26 , yuppie wrote: > >> Looks like five.localsitemanager is missing in your setup. Yuppie > > That's it, great catch! I got bitten by the same issue a couple of weeks ago, and dropped the ball on getting the tests runnable via 'setup.py test'. > So what do we do with this apparently undeclared dependency? It's not > mentioned in the top setup.py or in any text documentation in the > package such as in DEPENDENCIES.txt. Where does this need to go? > > There's an egg with version 0.3 on the cheeseshop, is that an > acceptable version? I simply linked in what I had here from the > current CMFCore trunk, but that external is against the > five.localsitemanager trunk and the package itself contains no version > information whatsoever (documentation foul!). Installing the cheeseshop version makes the tests pass. The cheeseshop should have a source distribution, rather than an egg, for that package, however. Tres. - -- ======= Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH0T8S+gerLs4ltQ4RAtjyAKCwNJhUhUkFscZK7yId92RkJSmjowCfcdCP nbktWxMVCsoyamGn6t2pnPA= =Kxtz -END PGP SIGNATURE- ___ 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: GenericSetup 1.4 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: > The improvements GenericSetup 1.4/trunk has over the 1.3 series are a > big part of Plone 3.1. With that moving towards it first alpha release > this Friday it would be practical if there was a GenericSetup 1.4 beta > release by then as well. For what it's worth I have been using it in > several projects recently and it looks solid to me. +1 to creating a beta (including making a 1.4 branch and a 1.4.0b1 tag). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHyzTF+gerLs4ltQ4RAjx2AKC9ktMQWOUc6MKy+7J43o83eNn8CQCePkyZ Jsr+0iHSc/grmzvIRt3U1yg= =b+wD -END PGP SIGNATURE- ___ 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: SVN: Products.GenericSetup/branches/1.3/Products/GenericSetup/ Merge 84270 from trunk: During object manager imports do not throw an
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: > Tres Seaver wrote: >> Marits, the new test you wrote here is failing when run on the Zope 2.11 >> branch or the trunk[1]: can you please diagnose why, and remediate? >> >> [1] http://mail.zope.org/pipermail/cmf-tests/2008-February/008099.html > > Fixed: http://svn.zope.org/?rev=84353&view=rev > > Cheers, Yuppie Thanks for the fix. I guess I'm worried at seeing more "integration-style" tests folded into the product in place of unit tests, but perhaps that is inevitable here. Tres. - -- ======= Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHxcpS+gerLs4ltQ4RAuoNAKCsu+JNEjFo8A8gxwl4Pdm7f74uOACfYBdS KWX3aEJOY/qCZE3Cfse1lHU= =pbCl -END PGP SIGNATURE- ___ 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: SVN: Products.GenericSetup/branches/1.3/Products/GenericSetup/ Merge 84270 from trunk: During object manager imports do not throw an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Maurits van Rees wrote:
> Log message for revision 84271:
> Merge 84270 from trunk: During object manager imports do not throw an
> error when trying to remove an object that was already removed.
> +class ObjectManagerHelpersTests(unittest.TestCase):
> +
> +def _getTargetClass(self):
> +from Products.GenericSetup.utils import ObjectManagerHelpers
> +
> +return ObjectManagerHelpers
> +
> +def _makeOne(self, *args, **kw):
> +from Products.GenericSetup.utils import NodeAdapterBase
> +
> +class Foo(self._getTargetClass(), NodeAdapterBase):
> +
> +pass
> +
> +return Foo(*args, **kw)
> +
> +def setUp(self):
> +from OFS.ObjectManager import ObjectManager
> +
> +obj = ObjectManager('obj')
> +self.helpers = self._makeOne(obj, DummySetupEnviron())
> +
> +def test__initObjects(self):
> +obj = self.helpers.context
> +self.failIf('history' in obj.objectIds())
> +
> +# Add object
> +node = parseString(_ADD_IMPORT).documentElement
> +self.helpers._initObjects(node)
> +self.failUnless('history' in obj.objectIds())
> +
> +# Remove it again
> +node = parseString(_REMOVE_IMPORT).documentElement
> +self.helpers._initObjects(node)
> +self.failIf('history' in obj.objectIds())
> +
> +# Removing it a second time should not throw an
> +# AttributeError.
> +node = parseString(_REMOVE_IMPORT).documentElement
> +self.helpers._initObjects(node)
> +self.failIf('history' in obj.objectIds())
> +
> +
Marits, the new test you wrote here is failing when run on the Zope 2.11
branch or the trunk[1]: can you please diagnose why, and remediate?
[1] http://mail.zope.org/pipermail/cmf-tests/2008-February/008099.html
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHxbxm+gerLs4ltQ4RAiWmAKDLO1x0Ei1bwQ0XgNBd6lQ4i63SJACgsiim
vMtCQ80/yVt+hP47iwtIQAU=
=rOoi
-END PGP SIGNATURE-
___
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: HTML cleanup?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Charlie Clark wrote:
> Hi,
>
> while taking a break from getting to grips with the newer Zope/CMF
> concepts I'd like to spend some time on stuff I'm more comfortable
> with: namely HTML and TAL! I know there are few people who actually
> get to grips directly with CMF but still it might be an idea to tidy
> up the default look a bit. I'm not thinking of anything radical, just
> dropping the table based layout and using CSS in skins/generic/
> main_template, et al. as this would make it a lot easier to adapt
> CMFDefault. Thoughts?
+1. I would still find that usefull. I think the normal main_template
is actually in 'skins/zpt_generic', though ('generic' is the old DTML
version).
Tres.
- --
=======
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHsfkn+gerLs4ltQ4RAm6/AJ91YmJfFrzo7XsT0H7F+ArX/TMhHgCfVYFz
KtRli/nGDI5L3N558tpJ2a8=
=ZQHh
-END PGP SIGNATURE-
___
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: Alternative base profiles
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Charlie Clark wrote:
> Dear all,
>
> at a snail's pace I'm approaching an understanding of the CMF!
> Actually, that's not entirely true, but coming from the ZMI world I'm
> still learning quite how much there is to learn!
>
> How do I go about creating a different base as opposed to an extension
> profile? eg. A site which only allows Documents and Images
> I've sussed that
>
>name="charlie"
>title="Charlies Site"
>description="Profile for a default CMFSite."
>provides="Products.GenericSetup.interfaces.EXTENSION"
>for="Products.CMFCore.interfaces.ISiteRoot"
>/>
>
> needs the provides directive removing and genericsetup XML files need
> creating in the profiles/charlie folder and I can create a site like
> this *but* I'm missing something fairly crucial
A baseline profile is registered as providing a different interface:
provides="Products.GenericSetup.interfaces.BASE"
The best way to get such a beast is to export the "all steps" tarball
from a working site and unpack in in your profiles directory.
> as I get the following error when I try and look at the site:
> "You have not created any users in this Zope instance. In order to log
> in and manage this Zope instance, you'll need to add an adminstrative
> user account"
>
> NB. this is only for this site - the Zope Instance is fine as are any
> sites based on CMFDefault. Apart from the Members folder created by
> the setuphandlers.py script I can't see any difference between the two
> sites and there profiles although there obviously is.
I can't discern from here what would cause that.
> Also: does in
> a browser view template refer to
> Products.CMFDefault.skin.five_template ? As a bridge between CMF skins
> and browser views?
Per $ZOPE210Products/Five/skin/configure.zcml, sort of: that is the
only registration in effect for that name in Zope2. The view class,
Products.Five.skin.standardmacros.StandardMacros, has a '__getitem__'
which actually looks for the name ('page' in this case) in any one of
three templates: 'five_template', 'widget_macros', and 'form_macros'.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHrGSU+gerLs4ltQ4RAt0WAJ9kNSnZwOltWq9Ld68bagdqdxpnvgCdE8Fc
HHIvlx/9R/qRmATgjTn2iQY=
=tNd7
-END PGP SIGNATURE-
___
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: GenericSetup trunk: failing tests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: > Previously Tres Seaver wrote: >> This is same set of failurs as in my "normal" sandbox using the head of >> the 2.10 branch. What other stuff is installed in the environment where >> your tests were running? > > CMF trunk. To be exact I'm using this buildout: > http://svn.plone.org/svn/plone/cmfout/trunk GenericSetup has grown an undocumented dependency on five.localsitemanager: in particular, the 'cmfout' bulidout explicitly wires that egg into the path. CMFCore ships with its *own* copy of file:lsm, which it jams onto the path if it isn't already importable (blech!) I will work on making 'setup.py test' work in an isolated virtualenv tomorrow. Tres. - -- ======= Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHqkkf+gerLs4ltQ4RAg2pAJ9XffoW7U8x548UMJ/x2bauH5CUQACfSLTr Ni7hWGzbafSCjfRLniT+8dc= =T6bS -END PGP SIGNATURE- ___ 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: GenericSetup trunk: failing tests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wichert Akkerman wrote:
> Previously Tres Seaver wrote:
>>
>> I get the follwing failures:
>>
>>
>>
>> and 11 more just like it. Does anybody have a clue what is wrong? This
>> is with a fresh checkout, in an instance which has no other products
>> installed.
>
> Seems to work for me using Zope 2.10.4:
>
> [snow;..l/instances/cmfout]-143> bin/instance test -s Products.GenericSetup
> Running tests at level 1
> Installing GenericSetup ... done (0.011s)
> Running unit tests:
> Running:
> .
> Ran 193 tests with 0 failures and 0 errors in 0.979 seconds.
> Running Products.GenericSetup.testing.ExportImportZCMLLayer tests:
> Set up Products.GenericSetup.testing.ExportImportZCMLLayer in 0.932 seconds.
> Running:
> ..
> Ran 186 tests with 0 failures and 0 errors in 1.505 seconds.
> Tearing down left over layers:
> Tear down Products.GenericSetup.testing.ExportImportZCMLLayer in 0.001
> seconds.
> Total: 379 tests, 0 failures, 0 errors
>
> Did something change in the Zope 2.10 branch?
Hmm, I'm not sure how you built your instance. Here is what I did to
try to reproduce against 2.10.4:
$ cd /tmp
$ wget http://www.zope.org/Products/Zope/2.10.4/Zope-2.10.4-final.tgz
$ tar xzf Zope-2.10.4-final.tgz
$ cd Zope-2.10.4
$ ./configure --with-python=/path/to/python --prefix=/tmp/z2104
...
$ make && make install
...
$ cd ../z2104
$ bin/mkzopeinstance.py -d /tmp/inst -u admin:123
...
$ cd ../tmp/inst/Products
$ svn co $ZSVN/Products.GenericSetup/trunk/Proudcts/GenericSetup
...
$ cd ..
$ bin/zopect test -s Products.GenericSetup
...
Running unit tests:
Running:
...
Ran 193 tests with 0 failures and 0 errors in 0.993 seconds.
Running Products.GenericSetup.testing.ExportImportZCMLLayer tests:
Set up Products.GenericSetup.testing.ExportImportZCMLLayer in \
0.513 seconds.
Running:
...
Error in test test_createSnapshot_default \
(Products.GenericSetup.tests.test_tool.SetupToolTests)
Traceback (most recent call last):
...
File "/tmp/z2104/lib/python/Testing/ZopeTestCase/profiler.py", \
line 98, in __call__
testMethod()
File "/tmp/inst/Products/GenericSetup/tests/test_tool.py", \
line 697, in test_createSnapshot_default
result = tool.createSnapshot( 'default' )
File "/tmp/inst/Products/GenericSetup/tool.py", line 443, \
in createSnapshot
messages[step_id] = handler(context)
File "/tmp/inst/Products/GenericSetup/components.py", line 257, \
in exportComponentRegistry
sm = getSiteManager(context.getSite())
File "/tmp/z2104/lib/python/zope/component/_api.py", line 48, \
in getSiteManager
raise ComponentLookupError(*error.args)
ComponentLookupError: ('Could not adapt', , \
)
http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHqiYn+gerLs4ltQ4RAjjmAJ46MrsWal4fVdSkFXUa6D7kF6FkpwCcDgDM
6k6MpLiUBxNGpmwAFW74fi8=
=6NBo
-END PGP SIGNATURE-
___
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: change ownership on Zope objects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marie Robichon wrote: > One of the administrators of our Plone site has changed services. Given > that our user authentication is via LDAP and that this person has write > access to some parts of our site I now want to change the ownership of > the pages he created in order to remove his write access. > > What method is used to display the owner information in the manage_owner > window? I have written a script that queries the catalog and returns > the Creator and owner_info() but this information is different again to > the owner that is displayed in the manage_owner window. > > Thanks in advance for your help The 'manage_owner' tab is only really important for "executable" content (PythonScripts, DTMLMethods, PageTemplates) which live in the ZODB. "Normal" content doesn't check or depend on that feature. You should be fine with using Plone's "Sharing" tab to adjust the "content" ownership for the former user's files. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHqggj+gerLs4ltQ4RAp6JAKDM/wxmpdJl9e6hV2/ehdUdeBRZxQCfZwCn kZZ4gXsWL8J48lThQ8g05kU= =xbNQ -END PGP SIGNATURE- ___ 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] GenericSetup trunk: failing tests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I get the follwing failures:
Error in test test_createSnapshot_default
(Products.GenericSetup.tests.test_tool.SetupToolTests)
Traceback (most recent call last):
File
"/home/tseaver/projects/Zope-CVS/Zope-2.10-branch/lib/python/Testing/ZopeTestCase/profiler.py",
line 98, in __call__
testMethod()
File
"/home/tseaver/projects/Zope-CVS/pastest/Products/GenericSetup/tests/test_tool.py",
line 697, in test_createSnapshot_default
result = tool.createSnapshot( 'default' )
File
"/home/tseaver/projects/Zope-CVS/pastest/Products/GenericSetup/tool.py",
line 443, in createSnapshot
messages[step_id] = handler(context)
File
"/home/tseaver/projects/Zope-CVS/pastest/Products/GenericSetup/components.py",
line 257, in exportComponentRegistry
sm = getSiteManager(context.getSite())
File
"/home/tseaver/projects/Zope-CVS/Zope-2.10-branch/lib/python/zope/component/_api.py",
line 48, in getSiteManager
raise ComponentLookupError(*error.args)
ComponentLookupError: ('Could not adapt', ,
)
and 11 more just like it. Does anybody have a clue what is wrong? This
is with a fresh checkout, in an instance which has no other products
installed.
BTW, Can we get tests for standalone GS added to the CMF daily summary?
Tres.
- --
=======
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHqgVU+gerLs4ltQ4RAgDQAJ9cFxn53r14nFZ0fM8hjPIO2YJIZgCgh6cc
Bu8YriMLpoM/Z2h6qKr2Stw=
=Y/Wb
-END PGP SIGNATURE-
___
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: GenericSetup "rolemap" importer does not register new permissions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Damien Baty (ML) wrote: > Hello, > > Le 27/12/07 9:49, Wichert Akkerman a écrit : >> Previously Damien Baty (ML) wrote: >>> [...] >>> >>> For the record, I have proposed a patch that let us automatically >>> register a permission if the profile explicitly asks for it, with >>> something like: >>> >>> ... >>> >> register="True"> >>> >>> ... >>> >>> https://bugs.launchpad.net/zope-cmf/+bug/178810 >> -1 >> >> I think it's the wrong place to register permissions. Permissions are >> something both code and application configuration (ie zcml) relies >> on. That suggests that registering permissions in a GS profile is too >> late in the game. >> >> To me it makes a lot more sense to register permissions and their >> default roles in zcml. > >Good point. But... how do you do that, then? :) There is a 'grant' > directive in Zope 3 defined in 'zope.app.securitypolicy', but this > package is not part of Zope 2.10 (nor Zope 2.11). Is there something > else I can use in Zope 2 to define permission/roles mappings? The application is responsible for defining permissions and using them to protect objects / methods. Five enables using the stock zope.security stuff to define permissions in ZCML, and to associate them with interfaces / attributes. See: - $ZOPE_HOME/lib/python/Products/Five/permissions.zcml - $ZOPE_HOME/lib/python/zope/security/meta.zcml - $ZOPE_HOME/lib/python/zope/app/security/meta.zcml GenericSetup is responsible for capturing the "placeful" mapping of permissions to roles (as set on the ZMI "security" tab). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHfP9x+gerLs4ltQ4RAskWAJ4gypOESDt+QnTogbgB12ANFJoFcQCeLp2G t6tJ5J9VlrAPgbs/uaf+PTs= =AMkn -END PGP SIGNATURE- ___ 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: Eggified CMF - was Re: CMF 2.1.1 release
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hanno Schlichting wrote:
> Tres Seaver wrote:
>> Jens Vagelpohl wrote:
>>> On Dec 29, 2007, at 18:28 , Hanno Schlichting wrote:
>>>> For the small number of CMF parts I'm +1 for individual eggs.
>
> I understood both comments as positive votes and have done the dirty
> work of moving CMF trunk into separate parts now.
Great, thanks very much! I know from experience how tedious / painful
that kind of work is.
> I haven't moved the
> 2.1 branches yet as it was done for CMFCore.
>
>>> I like your argument where we could use this as an opportunity to move
>>> packages like CMFUid out of the bundle/egg/tarball/whatever that
>>> people get when they get the CMF. I wouldn't mind having a division
>>> where you have...
>>> - CMFCore (the foundation which may be used by itself to develop
>>> other kinds of portal software)
>>> - CMFDefault + DCWorkflow + (maybe) CMFTopic (a "finished" sample
>>> for a CMFCore-based portal software bundle)
>>> - CMFUid (optional add-on)
>>> - CMFCalendar (optional add-on)
>>> - CMFActionIcons (optional add-on)
>
> I haven't updated the install_requires of the individual eggs yet. But
> if you for example "easy_install CMFCalendar" you should get a working
> system including its depdendencies which probably includes the rest of
> CMF as well. The same goes for the other options, so installing
> CMFDefault will pull in DCWorkflow and CMFTopic will probably include
> both CMFDefault and DCWorkflow. Careful dependency analysis is needed
> here, though.
I know of several kinds of dependencies:
- Non-conditional imports of the target product in "mainline"
code. These must be represented in 'install_requires' code.
- Conditional imports in mainline code. I'm not quite sure how
to deal with these, but am template to treat them the same for
now as the "harder" imports.
- Imports which occur only in test code. These should be captured
in 'tests_require'.
- Implicit imports in ZCML (via dotted names). For now, we should
capture thses as 'install_requires'. In the long term, I am tempted
to make them part of an "extra" (yes, I know Jim hates them, but the
only other choice is to multiply packages). E.g.:
extras_require={'zcml': []}
- Implicit imports in GS profile code. I think these have to be
extras, as well. Again, the other choice would be to move the
profiles out into separate eggs (which might be cleaner).
-
>> If we go ahead and break each product out into its own egg, we can
>> create one or more "meta eggs" which stitch them back together. E.g.,
>> the meta egg could have:
>>
>> install_requires=['Products.GenericSetup',
>> 'Products.CMFCore'
>> 'Products.CMFDefault',
>> 'Products.CMFTopic',
>> 'Products.DWorkflow',
>>],
>> extras_require={'uid': ['Products.CMFUid'],
>> 'calendar': ['Products.CMFCalendar'],
>> 'actionicons': ['Products.CMFActionIcons'],
>> 'kitchensink': ['Products.CMFUid',
>> 'Products.CMFCalendar',
>> 'Products.CMFActionIcons',
>> ],
>> }
>
> Sounds good - except for the kitchensink name ;)
Heh. That is a "give them something to change" gambit pawn. ;)
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHeBV9+gerLs4ltQ4RAuIMAKDcR1i9nZXWPjGZ9cWxDyJL992xowCcDH8s
V0eIWbZEA5cpX0MofvP9ouY=
=XcKL
-END PGP SIGNATURE-
___
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: CMF 2.1.1 release
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jens Vagelpohl wrote:
> On Dec 29, 2007, at 18:28 , Hanno Schlichting wrote:
>> What's the status of moving all the other parts into separate
>> projects /
>> folders?
>>
>> FWIW there hasn't been a final vote on the one-meta-egg vs. individual
>> eggs question.
>>
>> For the small number of CMF parts I'm +1 for individual eggs.
>
> Yes, this is an open question. Products.CMFCore has been prepared so
> it could be published as its own egg. But there hasn't been a decision
> whether to set up individual eggs for each CMF package or just one big
> egg or a combination of the two solutions.
>
> I like your argument where we could use this as an opportunity to move
> packages like CMFUid out of the bundle/egg/tarball/whatever that
> people get when they get the CMF. I wouldn't mind having a division
> where you have...
>
> - CMFCore (the foundation which may be used by itself to develop
> other kinds of portal software)
>
> - CMFDefault + DCWorkflow + (maybe) CMFTopic (a "finished" sample
> for a CMFCore-based portal software bundle)
>
> - CMFUid (optional add-on)
>
> - CMFCalendar (optional add-on)
>
> - CMFActionIcons (optional add-on)
If we go ahead and break each product out into its own egg, we can
create one or more "meta eggs" which stitch them back together. E.g.,
the meta egg could have:
install_requires=['Products.GenericSetup',
'Products.CMFCore'
'Products.CMFDefault',
'Products.CMFTopic',
'Products.DWorkflow',
],
extras_require={'uid': ['Products.CMFUid'],
'calendar': ['Products.CMFCalendar'],
'actionicons': ['Products.CMFActionIcons'],
'kitchensink': ['Products.CMFUid',
'Products.CMFCalendar',
'Products.CMFActionIcons',
],
}
People who want the traditional "all-in-one" could then depend on or
easy_install 'CMF[kitchensink]'.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHdpJA+gerLs4ltQ4RAjhZAKCsMkj8enr0nkbbHrX9I4W5QLjQbwCfcAC8
2BfwKyQ7aKathV6mRTSR76c=
=W5jC
-END PGP SIGNATURE-
___
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: CMF 2.1.1 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: > Jens Vagelpohl wrote: >> By the way, I have attempted to upload the new GS 1.3.3 to the cheese >> shop, but even though I have a login it told me I am not allowed to do >> so. This is the first time I am uploading anything, and looking through >> the scant documentation linked from the scheese shop pages I couldn't >> find any help. >> >> Who knows why I am getting a 403 error message and how can I get around >> it? I tried to execute the following in the toplevel >> Products.GenericSetup folder, where the setup.py file is: >> >> /path/to/python setup.py register > > You get that because you are not authorized ;) > > Looking at the page it says: Package Index Owner: tseaver > > So right now only Tres is allowed to upload or change that package. The > Cheese Shop has a simple permission model with an Owner and Maintainer > role and only knows about people and not groups. > > The maintainer role can only manage releases and files, while the Owner > can add new users or delete the whole package from the cheese shop. > > For GenericSetup Tres should probably add at least you as a second > Owner. He needs your Cheese Shop login name for that. Permission > handling is done through the web interface only. > > For most packages I uploaded to the cheese shop I have given a couple of > people usually directly an Owner role. I've now added Jens as 'Owner' on GS, PAS, and PR. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHdm7c+gerLs4ltQ4RAiCHAKCp08UMsBxo7yP9fibDLC/jC9GinQCfaU/W PuNIQtL+4Pw5KC3z4a+1ObE= =nk4X -END PGP SIGNATURE- ___ 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: Properties tab for files missing in ZMI - CMF
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: > I have reproduced the problem: the attached patch should fix it. > Please report the problem to the CMF launchpad: > > https://launchpad.net/zope-cmf/+filebug > > If it works for you, go ahead and attach the patch (made against the 2.1 > branch). Hmm, I could swear I attached that file. Tres. - -- ======= Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHdTtC+gerLs4ltQ4RAi4sAJ9HiqzGDsj1+T3z63FS9wLGRTxpCQCdH35a +1NieQ9HBdzwZ10y0tiUkJU= =tRzv -END PGP SIGNATURE- Index: CMFDefault/File.py === --- CMFDefault/File.py (revision 81532) +++ CMFDefault/File.py (working copy) @@ -76,6 +76,19 @@ # can span ZODB objects. self._getOb(id).manage_upload(file) +# +# Fix up PortalContent's over-generalization (OFS.Image.File has +# a *method* 'manage_edit', which is supposed to be POSTed to from its +# template, 'manage_editForm'. +# +manage_options = [] +for mapping in PortalContent.manage_options: +mapping = mapping.copy() +if mapping['label'] == 'Edit': +mapping['action'] = 'manage_editForm' +manage_options.append(mapping) +manage_options.extend(Cacheable.manage_options) +manage_options = tuple(manage_options) class File(PortalContent, OFS.Image.File, DefaultDublinCoreImpl): @@ -90,9 +103,7 @@ effective_date = expiration_date = None icon = PortalContent.icon -manage_options = ( PortalContent.manage_options - + Cacheable.manage_options - ) +manage_options = manage_options security = ClassSecurityInfo() Index: CMFDefault/Image.py === --- CMFDefault/Image.py (revision 81532) +++ CMFDefault/Image.py (working copy) @@ -75,6 +75,21 @@ self._getOb(id).manage_upload(file) +# +# Fix up PortalContent's over-generalization (OFS.Image.File has +# a *method* 'manage_edit', which is supposed to be POSTed to from its +# template, 'manage_editForm'. +# +manage_options = [] +for mapping in PortalContent.manage_options: +mapping = mapping.copy() +if mapping['label'] == 'Edit': +mapping['action'] = 'manage_editForm' +manage_options.append(mapping) +manage_options.extend(Cacheable.manage_options) +manage_options = tuple(manage_options) + + class Image(PortalContent, OFS.Image.Image, DefaultDublinCoreImpl): """A Portal-managed Image. @@ -88,9 +103,7 @@ effective_date = expiration_date = None icon = PortalContent.icon -manage_options = ( PortalContent.manage_options - + Cacheable.manage_options - ) +manage_options = manage_options security = ClassSecurityInfo() ___ 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: Properties tab for files missing in ZMI - CMF
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 roel wrote: > Hello there, > > first of all, I hereby present to all of you my best wishes for 2008. > > That said, I have problems accessing the properties of file objects (pdf, > images, ... ) added to a CMF site. All I get is the 'Dublin Core' page. When I > hit the 'Edit' tab, I get errors like: > > Traceback (innermost last): > Module ZPublisher.Publish, line 119, in publish > Module ZPublisher.mapply, line 83, in mapply > Module ZPublisher.Publish, line 47, in missing_name > Module ZPublisher.HTTPResponse, line 694, in badRequestError > > There seems to be missing (meta)data, but I have no (direct) way to edit these > entries. > I got to the point where I can access these properties by creating a custom > url out of the location-url/filename/manage_propertiesForm and pasting this in > a browser. > > In the early days (Zope 2.5.1 & CMF 1.3) there was a 'Properties' tab when > accessing a file object in a CMF site trough the ZMI. We've recently installed > Zope 2.10.4 & CMF 2.1.0. When I create a file object outside a CMF site, the > 'Properties' tab is displayed as I'm used to ... > > How can I (re)enable the 'Properties' tab for files in CMF 2.1.0? I have reproduced the problem: the attached patch should fix it. Please report the problem to the CMF launchpad: https://launchpad.net/zope-cmf/+filebug If it works for you, go ahead and attach the patch (made against the 2.1 branch). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHdSh8+gerLs4ltQ4RAjCMAKCAh6OkaW522fTVg/k2mQq2CjLAhACfcxTD 6FE1dFjEbFvPFa0P2wV9rts= =Kt59 -END PGP SIGNATURE- ___ 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: using global steps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: > yuppie wrote: >> GenericSetup trunk has global step registries. I propose to use the new >> ZCML directive for registering all GenericSetup and CMF import and >> export steps globally. And to remove the import_steps.xml and >> export_steps.xml files from the profiles shipped with CMF. >> >> This also requires to add a flag file for the 'various' step. >> >> I already started implementing this. If there are no objections, I'll >> soon check in my changes. > > Done. > > Not sure what to do with the 'content' steps: The 'content' export step > is the only one I would not like to run by default. A content snapshot > might be quite expensive. Worse, an import is potentially destructive. I am now of the opinion that content import / export should be treated as a separate application, not built into the profile. > For now the 'content' steps still must be registered locally or in > custom ZCML. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHbVLF+gerLs4ltQ4RAqKWAKCUD/EcpzrssBj+16aOELEdr6ECbACgvDtV Qcus85UPVTKl9aZ1mPmASDw= =5p1T -END PGP SIGNATURE- ___ 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: profile version and metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: > Hi! > > > Tres Seaver wrote: >> yuppie wrote: >>>>>> Previously yuppie wrote: >>>>>>> Running the trunk unit tests triggers warnings like this one: >>>>>>> "UserWarning: Version for profile Products.GenericSetup:default taken >>>>>>> from version.txt. This is deprecated behaviour: please specify the >>>>>>> version in metadata.xml." > [...] >>> In most cases this deprecation warning is false alarm because the >>> deprecated behavior is not really used. A note in CHANGES.txt might be >>> more useful than this deprecation warning. >> I've checked in changes which make this warning go away when running >> tests, through a combination of 'warnings.fiterwarnings' and adding a >> version to a metwadata.xml file. > > Thanks! But unfortunately this isn't just a GenericSetup testing issue. > The same warnings show up on Zope startup and in CMF tests: > http://mail.zope.org/pipermail/cmf-tests/2007-December/007342.html > > The only way to get rid of these warnings is a) adding a metadata.xml > file with specified version to *each* profile or b) removing the > warnings completely. > > Since metadata.xml files are not required I vote for b). +1. As an alternative, we could log the warning at "blather" level, which should be suppressed during "normal" startup / testing. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHaBUN+gerLs4ltQ4RAjSZAKCjMIB0RKzHXbzrj6ESFvDGjdYUWQCgsovC spzt2V+2waPZr57cwSBfeqA= =AWKB -END PGP SIGNATURE- ___ 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: profile version and metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: > Wichert Akkerman wrote: >> Previously yuppie wrote: >>> Wichert Akkerman wrote: >>>> Previously yuppie wrote: >>>>> Running the trunk unit tests triggers warnings like this one: >>>>> "UserWarning: Version for profile Products.GenericSetup:default taken >>>> >from version.txt. This is deprecated behaviour: please specify the >>>>> version in metadata.xml." >>>>> >>>>> I like the fact that using version.txt for the profile version is >>>>> deprecated. But you now get always a deprecation warning if no >>>>> metadata.xml exists in the profile. Is that intended? Is specifying a >>>>> version now required? >>>> It isn't required - it is fine if a profile has no version. What I did >>>> is add a deprecation warning when the profile metadata did not specify >>>> a version and the version was read from a version.txt file. If you have >>>> no version.txt you will not see the deprecation warning. >>> But if you *have* a version.txt file the only way to get rid of the >>> deprecation warnings is to add a version in metadata.xml. Right? That's >>> annoying because there is nothing wrong about having a version.txt file >>> and no metadata.xml file. >> Indeed, and I agree it is annoying. We should make a decision on when we >> will remove that version.txt fallback logic and add that to the >> deprecation warning. > > In most cases this deprecation warning is false alarm because the > deprecated behavior is not really used. A note in CHANGES.txt might be > more useful than this deprecation warning. I've checked in changes which make this warning go away when running tests, through a combination of 'warnings.fiterwarnings' and adding a version to a metwadata.xml file. There is another warning which shows up, due to the presence of the 'version' parameter when invoking import step registry. I believe that this deprecation is done in error, because removing all the 'version' arguments causes tests to fail: if the version argument matters, in which case we can't deprecate it. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHWu+7+gerLs4ltQ4RAo28AKDLg9EkusjNWfePkjASQwAXx93QkQCfbPt6 L6IIWhXj3V+2CVwuivHQ2fU= =c3OH -END PGP SIGNATURE- ___ 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: GenericSetup dependency support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: > I did some work on a wichert-dependencies branch for GenericSetup today. > It works quite simple: runAllImportStepsFromProfile will now look for > required contexts in the profile metadata. Any found dependencies will > be imported before the current code is imported. There is a new option > ignore_dependencies which can be used to disable this behaviour. > > I would appreciate some more eyes on these changes before merging this. The changes look good to me, although I'm not sure I understand the use case. BTW, why does Plone 3 still not display alternate BASE profiles registered for IPloneSite: it shows EXTENSION profiles just fine. Tres. - -- ======= Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHRaGt+gerLs4ltQ4RAm2GAJ47AkdObIRJsMCKlrK+hgz7cT96iwCgtVUV F+E6R0OfJGvU7s8/ADSE++o= =nRgG -END PGP SIGNATURE- ___ 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: GenericSetup can loose the base profile
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wichert Akkerman wrote:
> We are seeing a very interesting problem with the current profile
> handling in GenericSetup. This is the scenario:
>
> - we load a profile using runAllImportStepsFromProfile
> - one of the import steps installs a product using CMFQuickInstaller
> - this product loads another GenericSetup profile, but does a
> getImportContextID() and setImportContext() to make sure GS context
> is not destroyed during the process.
>
> what happens is that runAllImportStepsFromProfile does not set
> _import_context_id on the setup tool, so we get the default value: an
> empty string. setImportContext() checks if the context id starts with
> profile- and if not assumes we are setting the base profile. Result:
> the base profile has disappeared.
>
> What surprised me was that apparently "" *is* a valid profile id:
> _getImportContext assumes that anything that does not start with
> profile- is a snapshot profile. But it will also destroy the context
> id in that scenario:
>
> # else snapshot
> context_id = context_id[len('snapshot-'):]
>
> I modified that code to explicitly check for
> context_id.startswith("snapshot-") (see patch below) but that broke a
> number of tests which were using an context id of "" to get an empty
> snapshot context. As far as I can see nobody does that outside of the
> tests so there should no risk of unexpected breakage anywhere.
>
> Does anyone have a good reason not to make this change?
+1. It looks like your branch checkin did something funny with
'www/sutImportSteps.zpt' (deleted, readded? I'm not sure). Anyway,
except for not knowing what that change meant, I'm fine with merging
your branch to the 2.1 branch and the trunk.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHQdRJ+gerLs4ltQ4RAuUEAKCDv6NxvVFRLxiQDDl5XonFjTYWegCfRnM2
mXXuCSPZfQXwT25GzsIVevs=
=REs5
-END PGP SIGNATURE-
___
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: eggification status?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: > Hi! > > > Right now there are two versions of CMFCore and GenericSetup: > > Products.GenericSetup and GenericSetup > Products.CMFCore and CMFCore > > wichert is currently working on GenericSetup/trunk, tseaver stitched > today the 6 weeks old Products.GenericSetup/trunk/Products/GenericSetup > into CMF/trunk/ and > Products.GenericSetup/tags/1.3.2/Products/GenericSetup into > CMF/branches/2.1/ > > Products.CMFCore seems not to be used - changes still go into CMF/*/CMFCore > > Can we please have *one* location for each product? Ouch, sorry about that. I forgot I hadn't merged the change to use 'Products.GenericSetup' already. I'd rather that we moved to use 'Products.GenericSetup' and 'Products.CMFCore' everywhere, and leave the older stuff just pulling in from externals. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHL3Kn+gerLs4ltQ4RAi3FAKDK3drswCLhMZWLq2t9UIZH04mW0wCfTcTS RiXAV5CttE7W1CqRasmqegw= =ZsE9 -END PGP SIGNATURE- ___ 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: Accessing the "context"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: > Previously Charlie Clark wrote: >> Am 30.10.2007 um 17:40 schrieb Wichert Akkerman: >> >>> __init__ is indeed the wrong place: when the instance is created it is >>> not placed in an acquisition context yet. >> That would indeed explain things!!! Is it okay to call a method which >> does this from __init__ ? > > No, since the acquisition context is only created when the object is > insert into the hierarchy somewhere (sloppy terminology here, I know). Minor nit: the acquisition wrappers are transient objects, created when the object is retrieved from the container (typically via the container's __getattr__). So, the typical pattern for a factory which needs to do something with context is: def foo_factory(container, name): foo = Foo(name) container._setObject(name, foo) wrapped = container._getOb(foo) # now we have context > And that can only happen after the instance has been fully created. > > As an example: > >obj = Object() ># obj has no acquisition context >folder.obj = obj ># folder.obj will have an acquisition context Right, but the original 'obj' doesn't magically get a context: you need to re-fecth it (via 'foo.obj'). > In other words: in __init__ and everything you call from __init__ the > instance will not have an aq context. The context does not magically > appear. Yup. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHJ2ux+gerLs4ltQ4RAuWTAKDIhq+jyK7l7icmYax3HxxvZWmb2gCfU6dl vmEUq8YkT+RFbxzUFet7Ybk= =v4zr -END PGP SIGNATURE- ___ 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: Move CMF collector to Launchpad (redux)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: > Hi guys, > > Now that the Zope and Zope3 collectors have been migrated > successfully onto Launchpad, and there seems to be a good routine in > place to preserve history and ensure automatic redirects, I wanted to > bring up the question again. Should we move the CMF collector to > Launchpad? > > I personally had one remaining issue, namely the fact that my main > browser (OmniWeb) could not display Launchpad at all due to a CSS bug > in OW itself. All that has been fixed, and the Launchpad team has > been very cooperative and responsive. So my own vote at this point is > +1: > > - one less thing to maintain ourselves > > - apparently there's a new zope.org push, and not having to deal > with collectors will make life easier for the people involved > > - it will be easier to create relationships between Zope and CMF > bug reports (I am making an assumption here, haven't tried it) > > Can we have a show of hands, so to speak? - -0: I don't like the mails launchpad sends[1], but I can live with it if it makes a zope.org cleanup simpler. [1] Note that sending *all* history (not attachments, but the full transcript) has been working well for us for longer than launchpad or Canonical has existed; I would think we could register a per-project mail generation template, or something, Having to click back through to get the transcript makes it that much more likely I will ignore an issue. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHIlfC+gerLs4ltQ4RAmVYAKCJKbVyN8UdpITHUMbDYY/dC/KARwCfYrCL ja1T6WjwmJoCS9xsCfm9/Vs= =zIDc -END PGP SIGNATURE- ___ 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
