Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 17, 2009, at 17:52 , Hanno Schlichting wrote: > If you get the permission to backport these changes to 2.12 (or be > bold enough to just do it, since they seem to make sense) you could > back out this one change, so the 2.12 would keep the slightly more > backwards compatible notion. Since this is just a cosmetic change and it takes 5 seconds to change the test there's no reason at all to only apply part of the changes to 2.12, provided they get applied to begin with (which I hope). Backwards-compatibility is great, but let's not overdo it. If anyone relies on those headers being specifically base64 the application is broken by design. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkqJh/wACgkQRAx5nvEhZLISQwCeMXmymNDcGK60VX23RqUKABP4 fzAAnREAD45iDftlOw0FtztZ+x/bXRqY =pOCB -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: 3 OK, 1 Failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 17, 2009, at 16:45 , Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > >> 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? These failures have been brought up in a zope-dev thread about the MailHost changes, they are related to a switch from base64 to quoted- printable encoding for some headers. There has not been any final determination if this change is OK. Alec has promised to fix the tests once this has been decided. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkqJb5gACgkQRAx5nvEhZLJsrgCfUcacJyJ0eLJFcpRqM1puvpq1 GHYAoInsi2odl1VtOcHSTuqsbr57I/Ff =qphC -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 2.1] opaque items calls make performance issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 9, 2009, at 21:03 , Charlie Clark wrote: > From my previous answer to this which I forgot to send to the list > as well > - can we change the list settings so that answers go to it by default? No. See http://www.unicom.com/pw/reply-to-harmful.html for some information why it's not a god idea. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkp/zJoACgkQRAx5nvEhZLLplgCgpF3DLflX2kALxSSd2zRlmMaX 4gYAn2ZRkUgjUH2UQUFyhaf2JngB3aDk =dLSA -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 On Jul 6, 2009, at 12:58 , yuppie wrote: >> WA! Let's not codify the mistake: we should be ripping that >> dependency out by the roots! > > I don't think that change made things worse. > > +1 for removing that dependency in setup.py *and* the test +1 (although I looked at it once and it did not seem quick or easy to do it) jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkpR6AgACgkQRAx5nvEhZLIxbwCffqvY+kC2vUpqmzwg9tg6u8LT eFMAniUjepd2M2x6n2NUaP53Aq5l4zAZ =1jcw -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 On Jul 5, 2009, at 16:47 , Tres Seaver wrote: > 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. +1 jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkpR59AACgkQRAx5nvEhZLLI/ACcCB4O1aYDNkKX+U3ATfEoKHwB aGEAn3WkORu+WRft5W1YmDa1HB9ogLkR =PSdH -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] Rename form
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 18, 2009, at 13:35 , Charlie Clark wrote: > Renaming via > folders is presumably a continuation of the way things are done in > the ZMI > which is, of course, how we generally do things in file systems. > Nothing > wrong with keeping it around even if I think the more content-centric > (egid, what a neologism!) approach would be to work with the object > itself. To get this finished I would just stick with the current folder-based behavior. Renaming an object from the object itself can always be added on later. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkpMjqYACgkQRAx5nvEhZLLGdwCfQbUFkpfd3CC5WelZ1YDZ4OgH G9cAnRI8ZsjVeK/KggQPt4tWaQ+JMR/8 =LEtT -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] CMFDefault browser view and tests confusion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 24, 2009, at 14:20 , Charlie Clark wrote: > I'm responsible for part of the mess - I replicated the doctests for > new_folder and then set up unit tests to replace to doctests for > consistency with other modules and for completion. The mess will be > cleared up for 2.2 when new_folder.py formlib view will replace > folder.py. I have gone ahead and cleaned up the tests modules myself. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkob2EYACgkQRAx5nvEhZLIvtACghuO9apdIXtJm0tNzG5XBGTJW OVkAoJhbYQUH9Wb6+Es8Grf1JhtO8XKn =hlJU -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] Zope dependency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 26, 2009, at 11:20 , Hanno Schlichting wrote: > Why doesn't that generate test failures? We are running nightly tests > testing CMF trunk with Zope 2.10, 2.11 and 2.12. OK, I found the problem. It was actually my fault. With the refactoring mania going on I specified the INameChooser interface in a ZCML declaration from its new location and did not realize it was moved there just recently. Now the tests pass again on Zope 2.10.8 and Zope 2.11.3 Sorry for the confusion! However, I'd still like to bring up the question of officially supported Zope releases for CMF 2.2.x. Speaking for me personally, I develop CMF trunk against Zope trunk (there's that nifty CMF.buildout package that makes this easy), and it's becoming a greater and greater effort to ensure backwards compatibility for all kinds of combinations. So, what do we want to support? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkobuj4ACgkQRAx5nvEhZLJrywCgrKplXVtTqJZtS2r0uSSRywpz 198AnRijrq2DCNJF9grH6gBZhTD+ZH6b =4kmx -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] Zope dependency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 26, 2009, at 11:20 , Hanno Schlichting wrote: >> I'm guessing you are not aware that there already is a hard >> dependency >> in CMFDefault. In essence, I would not be setting a new policy, I >> would document the current situation. > > Why doesn't that generate test failures? We are running nightly tests > testing CMF trunk with Zope 2.10, 2.11 and 2.12. I'm looking into it right now. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkobtncACgkQRAx5nvEhZLKKtACfQuUQx57Ko8bwo+kiqhkk107Y e2QAoLmRXsAztL4Nyifd2QM9hGUkJzWC =L2tV -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] Zope dependency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 26, 2009, at 10:21 , Wichert Akkerman wrote: > Previously Jens Vagelpohl wrote: >> The CMF eggs, even on trunk, still advertise compatibility with Zope >> 2.10. I believe we had agreed to target Zope 2.12 with trunk - please >> correct me if that's wrong. If we do want Zope 2.12 I would like to >> go >> through before the first CMF 2.2 beta and do the following: >> >> - adjust all setup.py files to show the Zope2 egg as dependency, >> which will imply the "Zope2 >= 2.12dev" dependency >> >> - go through and delete all BBB code for Zope versions earlier than >> 2.12 >> >> If anyone thinks that's a bad idea please speak up. > > I think we are targetting Plone 4 at CMF 2.2 and Zope 2.11 at the > moment, so that would be bad for us. I'm guessing you are not aware that there already is a hard dependency in CMFDefault. In essence, I would not be setting a new policy, I would document the current situation. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkobruQACgkQRAx5nvEhZLJadACfa9oLhpOAluaPN4QNqGf8UW26 4V8AmwSNnABEZwAQwpq1XddErphVHW0o =o1v4 -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] Zope dependency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, The CMF eggs, even on trunk, still advertise compatibility with Zope 2.10. I believe we had agreed to target Zope 2.12 with trunk - please correct me if that's wrong. If we do want Zope 2.12 I would like to go through before the first CMF 2.2 beta and do the following: - adjust all setup.py files to show the Zope2 egg as dependency, which will imply the "Zope2 >= 2.12dev" dependency - go through and delete all BBB code for Zope versions earlier than 2.12 If anyone thinks that's a bad idea please speak up. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkobpg4ACgkQRAx5nvEhZLKKIwCdGBLac6apm+3jsvl4lNWFeDd0 ijQAnA3E19/PztkNszVbOJmGiFycCXCA =PMMx -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] CMFDefault browser view and tests confusion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just fixed an issue that made it impossible to add content to a CMFBTreeFolder and noticed that the module CMFDefault.browser and the tests scattered therein are a real mess right now. Looking at the various folder modules (folder.py, new_folder.py) and test files (folder.txt, folder_utest.txt, tests/test_folder.py, tests/ folder_utest.txt) it is not clear to me what's used under what circumstances, and what's tested. Matter of fact, the doctest files inside browser/ are not used at all right now because the folder browser/tests clobbers the browser/tests.py module. Is there a way this could be cleaned up before 2.2? Thanks! jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkoZJWgACgkQRAx5nvEhZLL1IwCghn01s/jDrxY57in/MNQNdPSm yBQAn1CAgKVZBeHWJNEU+FVh4yS4LsDp =klr4 -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] Allow TAL in DCWorkflow Worklist catalog match configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Here's the (probably last) Dieter-inspired feature addition. I have created a patch that allows administrators to either use the current formatted string values for worklist catalog variable matches, or qualified (meaning prefixed by e.g. python:, string:, etc) TAL expressions. This change allows greater granularity and control over worklists. It is backwards compatible and does not require any changes to persistent data in current worklist configurations. Please take a look at the Launchpad entry I created[1], it contains the patch file to quickly see the necessary changes. If you see a good reason to not merge the changes, please speak up, either here or via Launchpad issue comment. If no one speaks up, I will merge the change during the last week of May. Thanks! jens [1] https://bugs.launchpad.net/zope-cmf/+bug/378292 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkoSnIkACgkQRAx5nvEhZLJcQACeLqen6gxdR7psixfO3kLrjtUH wF4AnRtcJ7skLOEDyXtjC9J/vDHDYMva =rFFc -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] Improve encoding/charset detection for FSPageTemplate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Continuing the Dieter-inspired fixes, I have created a patch to improve the encoding/charset detection for FSPageTemplate objects, and replace the current hard-coded Latin-15 fallback with a mechanism used by the current ZopePageTemplate code. It uses a list of preferred encodings, which can be added to by using an environment variable. Please take a look at the Launchpad entry I created[1], it contains the patch file to quickly see the necessary changes. If you see a good reason to not merge the changes, please speak up, either here or via Launchpad issue comment. If no one speaks up, I will merge the change during the last week of May. Thanks! jens [1] https://bugs.launchpad.net/zope-cmf/+bug/322263 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkoP2FwACgkQRAx5nvEhZLLGeACeOC67PfF6Hxocg6tJhr+WLGe4 9r0Anj2MMVB67XeHTsS8ViLwtTt51FN5 =vgvz -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] Making it easier to replace MemberData implementation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, A second code change from Dieter's extensions for the Haufe publishing company deals with replacing the hardcoded MemberData wrapper inside MemberDataTool.wrapUser. Right now it is necessary to patch the class or provide your own tool to change the chosen MemberData class. I haven't chosen his particular implementation to reach that goal, but one that IMHO fits better with the direction we're going, by using a named factory utility. If no suitable utility is registered, the implementation falls back to the hardcoded MemberData class. Please take a look at the Launchpad entry I created[1], it contains a short description, links to the SVN branch(es) and patch file(s) to quickly see the necessary changes. If you see a good reason to not merge the changes, please speak up, either here or via Launchpad issue comment. If no one speaks up, I will merge the change during the last week of May. Thanks! jens [1] https://bugs.launchpad.net/zope-cmf/+bug/377208 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkoOgDkACgkQRAx5nvEhZLI/2ACfcraK3QByplgQdF1x5aI2sQ/k 8c4AnRo/SOdaY9WMx0gr7skXiGh2fyGw =4eSF -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] Actions growing link target attributes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I am currently going through the CMF code Dieter Maurer wrote during his time at the Haufe publishing company, extracting and preparing for release those extensions that I believe are useful for the wider community. The first chunk of code enables the administrator to set the value of the link target for an action, which can then be used to fill the link tag "target" attribute during rendering. Please take a look at the Launchpad entry I created[1], it contains a short description, links to the SVN branch(es) and patch file(s) to quickly see the necessary changes. If you see a good reason to not merge the changes, please speak up, either here or via Launchpad issue comment. If no one speaks up, I will merge the change during the last week of May. Please note: Concerns such as "but we should do the whole actions machinery differently" are valid, but not an obstacle to merging. Thanks! jens [1] https://bugs.launchpad.net/zope-cmf/+bug/376951 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkoNfN0ACgkQRAx5nvEhZLIlBACgutt9y6IEd6YtMbzbwxiWAutA yk0AnA653WrKOC2uRcEZdZXCVNM+AyJr =qm99 -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] which CMF for zope2.12
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 24, 2009, at 11:54 , Michael Haubenwallner wrote: > Just easy_installed the new Zope2.12.a4 release and Products.CMFCore > (2.1.2) > > There is a traceback at startup > http://gbe.d2m.at/Pastebin/35 > > Which CMF releases will work with Z2.12? SVN trunk should work. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAknxlaIACgkQRAx5nvEhZLJm6QCfbnKUiSGZ2B7IjCh/HfXcYPM6 Zk4Anj13rUBGzsGmQevYqv+uXsQMSrJ8 =65PB -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] IIndexableObjectWrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 5, 2009, at 12:14 , Martin Aspeli wrote: > Hi, > > Plone 3.3's IIndexableObjectWrapper implementation (in plone.indexer) > has a method _getWrappedObject(), to return the object that was > wrapped > by the indexable object wrapper. It is (or rather, will be) used by > TextIndexNG3, which needs to access the raw object during indexing. > > Any objections to pushing this down into CMFCore's definition of that > interface? A method name starting with an underscore is presumably a "private" method with restricted use by the internal implementation. I would at least rename it to something without underscore before putting it into the interface. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAknYlZsACgkQRAx5nvEhZLJJ+wCdET6ALpOqhnySeR2kmMPTa71H Vq8AoKxcUx7HfQPgv5CQh8kLWghU+n/6 =L3qs -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 On Mar 19, 2009, at 12:50 , Wichert Akkerman wrote: > Previously Jens Vagelpohl wrote: >> One use case I have: I need a different Member Data object (and thus >> the whole overridden tool) for Products.CMFLDAP in order to have >> custom overridden methods on those MemberData objects that call non- >> standard methods on the user folder. > > Personally I would rather find a way to get rid of the Member Data > object and rely PAS to provide all the required features. Is there > a reason, other than not wanting to add a dependency on PAS, to use a > Member Data object? There's also the fact that I want to do it the way it's done in the CMF, which means by way of a member data object. Should the CMF itself get rid of that construct I'll adjust my software as well. I believe I'd have to write more custom code in my software if I tried to do it through PAS alone. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAknCOg4ACgkQRAx5nvEhZLJk8wCdGm10hfWACj+dVRaEy0xm5FJt 85EAoLSmZkOFLFmp6YBkbAuKRYgYQwhY =uTbE -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 On Mar 18, 2009, at 16:12 , 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. One use case I have: I need a different Member Data object (and thus the whole overridden tool) for Products.CMFLDAP in order to have custom overridden methods on those MemberData objects that call non- standard methods on the user folder. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAknBEW8ACgkQRAx5nvEhZLJdXgCdF7XYKGyVQ1pTyPlLckpdXy2Z 0hIAn2loLaw6WY9CyiLAa+hqwu8V6QMI =15IO -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 On Mar 18, 2009, at 16:23 , Miles wrote: > Hi, > > 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. > > Any thoughts? Not really thoughts, but definitely +1 from me as well. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAknBD3IACgkQRAx5nvEhZLIPtQCfR+DD1to7o2Cdufow6uM/q41b ziUAn2KvcP/Qp3+wRbuHWpl723PACrI4 =5YNp -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 On Mar 10, 2009, at 14:21 , Martin Aspeli wrote: > The actual feature discussion happens on the medium-traffic > framework-team list, which you can join. In fact, it'd be great if you > did, as we'd appreciate your input, but I realise it may not be > something you want to spend a lot of time on. I'll join, sure. Joining does not imply activity beyond reading ;-) If there was a narrow-scoped announce-type list that contains announcements like PLIPs or important development decisions that may be of interest to the CMF developers as well then it would be useful to pipe it into this list. That's one reason I asked. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkm2bQkACgkQRAx5nvEhZLKP4wCeK5mW5+r4Ie0s1sghrz20zqWG gDgAnjQelFAI2qdpRiZMCog+JpCIGW0s =JEV8 -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 On Mar 10, 2009, at 11:08 , Martin Aspeli wrote: > I think we all agree on this. In retrospect, it would've been a better > idea to push for plone.indexer to be a part of CMF. However, I > implemented it driven by Plone's release cycle and feature proposal > process, which is why it ended up as it did. *I* want this feature for > Plone, but it'd be even better if others could benefit. IMHO the release cycle argument doesn't wash. We've always had CMF releases in preparation for important Plone releases, and I'm happy to continue that. > Of course, it's not too late for that. If the license issue can be > overcome (and I'm pretty sure that it will by April/May), then CMF can > depend on plone.indexer if it so wants, and I'm willing to help make > that possible if it means changing plone.indexer or helping with the > CMF > level implementation. Thanks, I appreciate that. Generally, I think now that the ZF has cleared up the remaining issues about code ownership etc. we finally have two entities, the ZF and the Plone Foundation, that are the perfect platform for "official" issues like code donations, or for coordinating other cooperation issues. I can't judge how the Plone Foundation acts within the Plone community, but as far as the Zope Foundation goes, Martijn has been doing a lot of work to make it more relevant and an important player in the actual software development process. > In the future, it may be that we can meet in the middle on this. When > the PLIP process kicks off, it'd be good if the CMF developers had a > look in as well. We should probably be better at announcing the > various > deadlines and proposals on this list, but if you guys see something > that > you feel would be a good fit further down, it doesn't hurt to raise > that, lest the developer hasn't thought about it. Is there any kind of low-traffic announcement list for things like PLIPs? I'm not subscribed to any Plone list because of (for me at least) signal to noise ratio fears. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkm2PwIACgkQRAx5nvEhZLJs8QCfYsGqkD63R9+isOhA0nXzeWy+ IgoAoJ8xfUzIMdGmlOSXUEreYgF7ErI+ =owJ7 -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 On Mar 10, 2009, at 10:01 , Wichert Akkerman wrote: > Previously Jens Vagelpohl wrote: >> In general, commercial adoption of a software stack is made easier if >> it is not accompanied by a whole soup of different licenses. The >> fewer >> licenses, the better. I'm sure that issue is on your radar already. > > It is, which is why the ZPL has already been rejected as an option: it > is pretty much equivalent to the BSD license, which is much more > widely > accepted. If they are equivalent, why not dual-license? > The debate is currently focusing on GPL versus BSD license. Any > opinions > on a choice between those two would be very welcome. The discussion has been rehashed in several places, but given a choice between pretty much anything and the GPL I'd vote "-1" on the GPL. >> As you know, all code you'd like pushed down the stack into the CMF >> or >> Zope must be licensed under the ZPL. That's also a prerequisite for >> being stored in the Zope Foundation repositories (a.k.a. >> svn.zope.org). > > I do not think the Plone Foundation board is willing to consider > donating some of its intellectual property to the Zope Foundation. I > am > already happy they are willing to consider selective relicensing. To me this really sounds like the rift has widened, by a whole lot. It reads like "we're happy to base our stuff on yours, but we really don't want to give back". I'm sure it's not meant that way, but it reads like that. > But that does not need to be a problem: reusable packages such as > plone.indexer can be used by CMF even if they are not covered by the > ZPL > or managed in svn.zope.org, as long as there is the license is > acceptable. That's not the issue I was trying to address. I was specifically talking about putting functionality in the most appropriate part of the stack, meaning moving it further towards the core. If there are bits and pieces that make more sense in the CMF then saying "well, just install our package" may satisfy users, but developers will continue wasting time maintaining different implementations. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkm2NA8ACgkQRAx5nvEhZLLy0wCfehi6WBVBHEcwJZXORFpM2tx4 aD4Anip87gouzSsnK/o4jI57ibOjt3YS =dvw+ -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 On Mar 10, 2009, at 09:14 , Raphael Ritz wrote: > Opinions anyone? (ideally including a reasoning beyond > "I want ZPL because that's what Zope itself uses") ;-) In general, commercial adoption of a software stack is made easier if it is not accompanied by a whole soup of different licenses. The fewer licenses, the better. I'm sure that issue is on your radar already. As you know, all code you'd like pushed down the stack into the CMF or Zope must be licensed under the ZPL. That's also a prerequisite for being stored in the Zope Foundation repositories (a.k.a. svn.zope.org). In the end I hope that whatever decision is being made does not serve to widen the distance between the Plone community and the rest of the Zope universe. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkm2JqkACgkQRAx5nvEhZLJNMACeJvlVOK8y1hxx5dkyP1pmwP/M fqAAoJXXclf5a7Gy0tDiAhH5db0oCJLU =mIFf -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 On Mar 10, 2009, at 03:33 , Martin Aspeli wrote: > There are some discussions about licensing going on with the Plone > Foundation, but chances are good that it can be licensed in such a way > that CMF could adopt it you want. IMHO the licensing issue is of general interest beyond this one software bit. If there are any changes to Plone licensing I'm sure people on this list would be happy if you or someone else could provide some summary, if and when something is being changed :-) jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkm2GO0ACgkQRAx5nvEhZLJs9gCgo69+c0mzg4rIjDSO+h2DEUM1 H90AoIEzoTI2kkYlTq/dX483KZFsFBnc =8P7y -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 On Mar 9, 2009, at 22:47 , Wichert Akkerman wrote: > Previously Jens Vagelpohl wrote: >> On Mar 9, 2009, at 21:09 , Miles wrote: >> >>> Can anyone tell me if it is possible to register an adapter to >>> provide a >>> different IndexableObjectWrapper class from the stock CMF one? >>> >> You already noticed that the wrapper is instantiated directly, so >> that's what's going on. No magic, no component architecture. >> >> Whether that is good or bad or should be changed is a different >> issue. > > Martin Aspeli implemented an adapter based index wrapper for Plone > 3.3. It's nice to see that Plone has it, but that doesn't help anyone working off the CMF itself. I wish there was more communication to determine where improvements fit best. Not knowing how Plone implemented it I would make a guess this one small item would have been better off in the CMF itself. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkm1lR8ACgkQRAx5nvEhZLJJvQCgnWpvHGu9TUCWOI5kmOzhRWAv X8kAnAvVgxARYBlafyTF9FbosZZgO2Nn =b1rx -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 On Mar 9, 2009, at 21:09 , Miles wrote: > Can anyone tell me if it is possible to register an adapter to > provide a > different IndexableObjectWrapper class from the stock CMF one? > There's > some sort of framework code that hints that it ought to enable this, > but > I can't see how! > > The code still seems to instantiate the wrapper directly using the > class, rather than looking it up via the component architecture. > > Can anyone explain what's going on? I've drawn a blank from googling > for examples. You already noticed that the wrapper is instantiated directly, so that's what's going on. No magic, no component architecture. Whether that is good or bad or should be changed is a different issue. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkm1igUACgkQRAx5nvEhZLLXDgCgkfCiB2OLW/G2LxT1JVBOtGJJ b3gAniLMUd22poUykxudnvXA5ibaK2hO =GZpO -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 On Mar 2, 2009, at 11:30 , Hanno Schlichting wrote: > yuppie wrote: >> 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. > > My mail had: "I have one small todo item on my list regarding the > changes to content type icons." > > I'm referring to the same thing here. Without any release date planned > whatsoever, it wasn't high on my list so far ;) Apparently having CMF betas is high on your list, so this todo should be one step higher, obviously :-P jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmrtecACgkQRAx5nvEhZLIwagCfQzSum38mhGRzZ3s4i/ezWYx1 U+sAoKi8ck73HR1XhgUawXwBVheLEFf1 =YocE -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 On Mar 1, 2009, at 10:50 , Martin Aspeli wrote: > Jens Vagelpohl wrote: >> >> On Mar 1, 2009, at 04:01 , Martin Aspeli wrote: >> >>> Jens Vagelpohl wrote: >>> >>>> Are there _specific_ dependencies on unreleased code that would >>>> require new eggs? Let's identify which specific eggs are needed and >>>> concentrate on those first. >>> >>> - Add the add view expression to the FTI type >>> - Add the related code to the TypesTool >>> - The ++add++ traverser > > I think they're all in Products.CMFCore. 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? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmqW1cACgkQRAx5nvEhZLJMWQCfSfa7FBFAOJwFGEpiE/9XOlGS +cQAn2/fJfq8wsYR+s/diM/B1I9y6Kpo =KYeW -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 On Mar 1, 2009, at 04:01 , Martin Aspeli wrote: > Jens Vagelpohl wrote: > >> Are there _specific_ dependencies on unreleased code that would >> require new eggs? Let's identify which specific eggs are needed and >> concentrate on those first. > > I am currently relying on backports/monkey patches for the add form > stuff in code that may be part of Plone 4 at some point. It'd be > nice to > be able to avoid those. The patches are: > > - Add the add view expression to the FTI type > - Add the related code to the TypesTool > - The ++add++ traverser Which eggs is that? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmqPuAACgkQRAx5nvEhZLIgEwCgl7OeRG93NPgrcuZpqN6pLboN X50AoKYhvdrL2hAiHikk0sn5JTwjucsI =3YqV -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 On Feb 28, 2009, at 13:55 , Hanno Schlichting wrote: > It should be no surprise, that I'd like to have official support for > Zope 2.12 for CMF 2.2 as well ;) Nightly tests are running fine for > all > I can see. As Zope 2.12 is not likely to be released before Summer, > would that be a reasonable timeframe to aim for a CMF 2.2 final > release > as well? Counterquestion: With Zope2 eggified, who can show me a buildout.cfg snippet that would result in a buildout with an instance prepared, like I get with the current combination of plone.recipe.zope2install to get Zope and then plone.recipe.zope2[instance|zeoserver] to get an instance built? > P.S. I would appreciate some kind of first alpha or beta release > soonish, so we can start releasing Plone 4 preview releases based on > this... Are there _specific_ dependencies on unreleased code that would require new eggs? Let's identify which specific eggs are needed and concentrate on those first. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmpUMAACgkQRAx5nvEhZLIirACgt679iRicsHRTYZAB2jC28acl e3wAn03vA6tpQ7dXRxIjh5UnRxFxo7b2 =ywqx -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 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. > 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. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmZwRYACgkQRAx5nvEhZLKq/QCfVdhoy897JiJmUu26gMrAo+qm vacAn1AvPBmYLCfhGYj+VxSNdfzJgG2I =/nfE -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
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.
jens
Set up Products.CMFDefault.testing.FunctionalLayer Traceback (most
recent call last):
File "/usr/local/py24/CMF.buildout-trunk/eggs/zope.testing-3.7.1-
py2.4.egg/zope/testing/testrunner/runner.py", line 360, in run_layer
setup_layer(options, layer, setup_layers)
File "/usr/local/py24/CMF.buildout-trunk/eggs/zope.testing-3.7.1-
py2.4.egg/zope/testing/testrunner/runner.py", line 536, in setup_layer
layer.setUp()
File "/usr/local/py24/CMF.buildout-trunk/src/Products.CMFDefault/
Products/CMFDefault/testing.py", line 41, in setUp
snapshot=False)
File "/usr/local/py24/CMF.buildout-trunk/src/Products.CMFDefault/
Products/CMFDefault/factory.py", line 63, in addConfiguredSite
setup_tool.runAllImportStepsFromProfile('profile-%s' % profile_id)
File "/usr/local/py24/CMF.buildout-trunk/src/Products.GenericSetup/
Products/GenericSetup/tool.py", line 327, in
runAllImportStepsFromProfile
ignore_dependencies=ignore_dependencies)
File "/usr/local/py24/CMF.buildout-trunk/src/Products.GenericSetup/
Products/GenericSetup/tool.py", line 1082, in _runImportStepsFromContext
message = self._doRunImportStep(step, context)
File "/usr/local/py24/CMF.buildout-trunk/src/Products.GenericSetup/
Products/GenericSetup/tool.py", line 996, in _doRunImportStep
return handler(context)
File "/usr/local/py24/CMF.buildout-trunk/src/Products.CMFCore/
Products/CMFCore/exportimport/workflow.py", line 126, in
importWorkflowTool
importObjects(tool, '', context)
File "/usr/local/py24/CMF.buildout-trunk/src/Products.GenericSetup/
Products/GenericSetup/utils.py", line 821, in importObjects
importer.body = body
File "/usr/local/py24/CMF.buildout-trunk/src/Products.GenericSetup/
Products/GenericSetup/utils.py", line 505, in _importBody
self._importNode(dom.documentElement)
File "/usr/local/py24/CMF.buildout-trunk/src/Products.CMFCore/
Products/CMFCore/exportimport/workflow.py", line 63, in _importNode
self._initObjects(node)
File "/usr/local/py24/CMF.buildout-trunk/src/Products.GenericSetup/
Products/GenericSetup/utils.py", line 566, in _initObjects
raise ValueError("unknown meta_type '%s'" % meta_type)
ValueError: unknown meta_type 'Workflow'
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkmZo08ACgkQRAx5nvEhZLJw/gCgtRL31njX0iG5oOAxs9Q51qre
OcAAn0Ra7YOYiCwpSRRHAi7z5e4wrUlz
=DfYB
-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] [Checkins] SVN: Products.CMFCalendar/trunk/setup.py - dependency cleanup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 16, 2009, at 13:50 , Charlie Clark wrote: > Am 16.02.2009 um 13:08 schrieb Jens Vagelpohl: > >> I'm wondering, ist it necessary to declare a dependency where we know >> that it is a required dependency for another dependency we already >> declare? Specifically, if CMFDefault is declared as dependency, is it >> necessary to also declare CMFCore because we know CMFDefault already >> declares it? > > > hm, do we always *know* that? > > Unless dealing with known behemoths aka Zope2, I'd go with explicit is > better than implicit and expect declarations for any import statement. Yes, that's a good point. > Then again I'm still not convinced that the CMF itself isn't a mini- > behemoth to be eaten tail, toenails and all. It depends on how you look at the dependencies. If you mean installation dependencies then I think there's been great progress disentangling the different packages. If you mean "I don't need Y for installing X, but really, X is not all that useful without Y" that's a different issue. But that's off-topic for this thread ;-) jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmZYjAACgkQRAx5nvEhZLIEmACeNPlN1ngSkfzSzyhu3Lr3WJ70 eRAAoIzMXWda+p7qTvzPPdBwreubx+3B =ZH9k -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] [Checkins] SVN: Products.CMFCalendar/trunk/setup.py - dependency cleanup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 16, 2009, at 13:29 , yuppie wrote: > Jens Vagelpohl wrote: >> I'm wondering, ist it necessary to declare a dependency where we know >> that it is a required dependency for another dependency we already >> declare? Specifically, if CMFDefault is declared as dependency, is it >> necessary to also declare CMFCore because we know CMFDefault already >> declares it? > > No. But as Hanno pointed out yesterday, it is good practice to specify > all *direct* dependencies: > http://mail.zope.org/pipermail/zope-dev/2009-February/034582.html > > The Zope2 package is an exception because it represents the Zope 2 > platform and ships with a KGS. So direct dependencies on packages > Zope2 > also depends on should not be specified if Zope2 is specified as > dependency. > > I thought that was consensus, but if you don't agree I'm fine with > further discussions. No, don't get me wrong, I did not signal any disagreement or agreement ;-) I was just wondering if there was a new set of "best practices" that I missed. I did not draw the line between the other discussion and your checkins at all, it did not strike me as related. Does anyone else have a specific opinion for this case, disregarding the five.localsitemanager discussion? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmZYK4ACgkQRAx5nvEhZLLq8wCeJEfA4DXKzauYg4Cl9qK2X83v WpkAoLX7504n+vjQI9ntqxgKhr1tfBHX =phKB -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] [Checkins] SVN: Products.CMFCalendar/trunk/setup.py - dependency cleanup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm wondering, ist it necessary to declare a dependency where we know that it is a required dependency for another dependency we already declare? Specifically, if CMFDefault is declared as dependency, is it necessary to also declare CMFCore because we know CMFDefault already declares it? jens On Feb 16, 2009, at 11:42 , Yvo Schubbe wrote: > Log message for revision 96579: > - dependency cleanup > > Changed: > U Products.CMFCalendar/trunk/setup.py > > -=- > Modified: Products.CMFCalendar/trunk/setup.py > === > --- Products.CMFCalendar/trunk/setup.py 2009-02-16 10:11:44 UTC (rev > 96578) > +++ Products.CMFCalendar/trunk/setup.py 2009-02-16 10:42:54 UTC (rev > 96579) > @@ -45,14 +45,19 @@ > setup_requires=['eggtestinfo', > ], > install_requires=[ > - #'Zope >= 2.10.4', > 'setuptools', > + #'Zope2 >= 2.10.4', > + 'Products.CMFCore', > 'Products.CMFDefault', > - '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'], > + ), > test_loader='zope.testing.testrunner.eggsupport:SkipLayers', > test_suite='Products.%s.tests' % NAME, > entry_points=""" > > ___ > Checkins mailing list > check...@zope.org > http://mail.zope.org/mailman/listinfo/checkins -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmZVzUACgkQRAx5nvEhZLJ4OACggumqB1uszZgWL1Xs5qCMKDNY 2woAoKpVaHIuUnNhCjaoHyX35qpZcsHB =6ViM -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] Running functional tests in a buildout environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 12, 2009, at 22:10 , Jens Vagelpohl wrote: > On Jan 12, 2009, at 20:28 , Charlie Clark wrote: > >> Thanks for the explanation. Using --package-path doesn't seem to help >> me. But moving tests.py to the tests folder and renaming it to >> test_folder does what I want. Would it be okay to do this? > > If you are saying that you had both a "tests" folder and a module > "test.py" in the same place then the answer is probably "don't do > that". I meant "tests" folder and "tests.py" module, of course. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAklrssMACgkQRAx5nvEhZLLZEwCgg+5p2fq+W/uL2IDfWwbhbYi9 P1gAoLG9HgF9k40JlznlExbFiRhWfPkx =EPcp -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] Running functional tests in a buildout environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 12, 2009, at 20:28 , Charlie Clark wrote: > Thanks for the explanation. Using --package-path doesn't seem to help > me. But moving tests.py to the tests folder and renaming it to > test_folder does what I want. Would it be okay to do this? If you are saying that you had both a "tests" folder and a module "test.py" in the same place then the answer is probably "don't do that". jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAklrsa8ACgkQRAx5nvEhZLJvGQCgvBpaPL9tOeOSP7kAfIOFM1pM KT4AoKRxAcZhbx5n5V9i/lJrI7CxxapS =Mohe -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 On Dec 29, 2008, at 15:18 , Charlie Clark wrote: >> 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. They have (and retain) that behavior. Tres was specifically mentioning FSProperties.py and FSZSQLMethod.py, which implement the re-reading in a somewhat awkward way using __of__. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAklY5p0ACgkQRAx5nvEhZLJqGACfcpAUoT6GpN8sIiim/ATXTILX OooAnir4vTeDRKznITzk3I+yIUMxEk3y =cOhV -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 On Dec 27, 2008, at 19:45 , Tres Seaver wrote: > 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 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. > 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 +1 jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAklWfAsACgkQRAx5nvEhZLKF6gCfbAiOvshC/jieG8+4UmTsyYH7 AR8An2DsvoQ9ELqaRRG2LQPGFXOoIk+k =9Md6 -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 On Dec 11, 2008, at 18:18 , Tres Seaver wrote: > Anyone have other stuff they would like to see in the mix (and can > help > land)? Having just implemented GS handlers for a PAS plugin and the LDAPUserFolder I came across the fact that two separate handler types are used "in the wild", the (older?) IFilesystemExporter/Importer and the (newer?) BodyAdapterBase-derived handlers. There's one unfortunate incompatibility: If someone has implemented a IFilesystemExporter- based exporter that walks the content tree, such as the PluggableAuthService exporter, it will only pick up other IFilesystemExporter-based export adapters, but not BodyAdapterBase- type exporters. I'd like to see that ability, unless there's a specific reason why it isn't there. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAklKepwACgkQRAx5nvEhZLKDQACgqEtv27nJC+sIXi8sIuCYivCs AfEAoKIwQZpM6x4+uuMQMJyRCAjY4nZC =tT2F -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] Adapterizing CMFCore.WorkflowTool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 21, 2008, at 13:17 , Sasha Vincic wrote: > Laurence Rowe wrote: >> I have made the changes on a branch: >> http://svn.zope.org/Products.CMFCore/branches/adapterize-wfstatus-wfhistory >> > > What is the status of this branch and acceptans of this into trunk? Since no one has worked on it for 9 months I'd say the status is "abandoned". There's also no tests, which is bad. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkmxPMACgkQRAx5nvEhZLIk2gCgpczzl2m4mzYgdKHsWvWs2etS 7j4AnivccyNRp+2YXihdloU5InPnKsxl =llt1 -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] Should portal_setup be registered as utility?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 16, 2008, at 22:30 , Wichert Akkerman wrote: > Previously yuppie wrote: >> I don't like to remove CMF's portal_setup registration *if* CMF >> itself >> is not affected by this issue. > > Imho registering portal_setup as a utility as long as any CMF tool > uses > self.REQUEST is problematic since it makes it impossible for > import/export steps to use such tools. I suggest we *look* at the current CMF situation before acting on the assumption that non-utility tools are used in (and break) CMF import/ export steps. It's been working fine so far. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkgmSsACgkQRAx5nvEhZLJxSACeJmQUFUNTjayJYLsSRIAolcpz RZwAnjEu4F9Lc6IbTsklEkXpbKgHPfkI =6vSX -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] Should portal_setup be registered as utility?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 16, 2008, at 18:11 , yuppie wrote: > I don't like to remove CMF's portal_setup registration *if* CMF itself > is not affected by this issue. +1 jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkgiUwACgkQRAx5nvEhZLIhEQCdEkuvKVD02TAwCbK0zfPAWqcK RYUAmgLCUroC7XUanE7wxnTNG/sii6MS =nO8h -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] Debugging GenericSetup?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 18, 2008, at 10:12 , Andreas Jung wrote: > Hi there, > > I am currently working on an extension profile for a Plone content- > type with two content-types. Right now I am in the situation where > the content-type isn't added to portal_types although the > configuration under types/MyType.xml and types.xml are obviously > there and correct. I am under the impression that GS is silently > ignoring bugs instead of raising them. Is there no other way for > hunting down such an issue like using pdb? pdb is what I would use. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkj5m04ACgkQRAx5nvEhZLKGiACgjYluoXhw/+iWK8DNJaoWeL/p lU0An0/od9ulbcHLrzgtU+d6simigbR5 =/BFa -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] MembershipTool: Using traversal to look up the Members folder?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 11, 2008, at 08:16 , Dieter Maurer wrote: > Jens Vagelpohl wrote at 2008-10-8 14:57 +0200: >> ... >> As far as the feature itself is concerned, I've never seen a >> situation >> where this is useful or needed. > > As so often -- we need it :-) > Our "MembershipTool" instance is (together with the portal) > in a read only mounted storage > while the "Members" folder obviously has to be in a read/write mounted > storage. As so often, you have never mentioned that this is useful or needed ;-) Seriously, I know you may have some use cases that few of use will ever see or need, but if there's no feedback at all then it's not possible to consider them. If you have a fully-tested patch I'll be happy to look at it. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjwU94ACgkQRAx5nvEhZLLofgCffohn0jgS9+X8yT2WbQSCc7Rd 24kAoJv42TfniCfuh+YEtg7mUb41g0QG =9YRS -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] portal_fiveactions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 10, 2008, at 10:30 , Jens Vagelpohl wrote: > If there are no objections I'll basically revert and remove the > original checkin in time for CMF 2.2.0: > > http://svn.zope.org/?rev=38594&view=rev Small clarification: I'll revert the CMFCore changes from that revision that are not used by anything other than the FiveActionsTool. The CMFDefault changes are of a different nature and are used. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjvGRIACgkQRAx5nvEhZLLewgCdETXggzj8qQXAgaoo79o0fPrN nkAAn0Qf+ulf0xQqdAOBZcxpMioGzVJw =/nty -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] portal_fiveactions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 6, 2008, at 10:59 , Lennart Regebro wrote: > On Sun, Oct 5, 2008 at 11:32, Hanno Schlichting > <[EMAIL PROTECTED]> wrote: >> But no matter what the code does, nobody is using it. I think it's an >> artifact from the early "Zope 3 everywhere"-days. > > Yeah, the idea was to show Zope3 actions in CMF menus. Nobody seems to > want that anymore. :) If there are no objections I'll basically revert and remove the original checkin in time for CMF 2.2.0: http://svn.zope.org/?rev=38594&view=rev jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjvEo8ACgkQRAx5nvEhZLKEDACgqHQ9Ojw2hZfH9rIMWe1yND5s xpwAoJgCBF+Ewr9Yz5jog5RUp17JyKhI =/Uhl -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] MembershipTool: Using traversal to look up the Members folder?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 8, 2008, at 13:36 , Raphael Ritz wrote: > Hi, > > today I'm facing the situation where I want to support a Members > folder > (rare these days) but this folder should be deeper down in the site > (very rare; for me this is the first time ever). > > Currently, CMF(Default - and Plone for that matter) does not support > this OOTB because CMFDefault's MembershipTool uses a simple getattr > call for the 'membersfolder_id' on the site object. > Changing this to use 'unrestrictedTraverse' instead resolves > the problem including the possibility to specify the path (or > relative content URL) to the folder in ZMI. > > It does break two tests, however, as the DummySite's > 'unrestrictedTraverse' used for testing isn't clever > enough to deal with relative paths/URLs correctly. > > Now my question: Is this something CMFDefault should support? > If so, I'm happy to file a ticket with a patch (and test; > I don't have repository access). > If not, I will simply keep on patching my local installation. > > Just thought I'll let you know. Opinions anyone? Please keep in mind the true nature of CMFDefault: It's a sample application of the framework laid down in CMFCore. So IMHO _if_ this kind of configurable members folder location feature is added, it should be in CMFCore and thus available to CMFDefault. As far as the feature itself is concerned, I've never seen a situation where this is useful or needed. So my vote as far as the CMF is concerned is +-0 because it's a "YAGNI" feature, You Ain't Going to Need It. I'd say the correct place would be a custom membership tool for your specific application that needs to support this use case. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjsrkUACgkQRAx5nvEhZLKx3QCfS3u5pfLRG1H2AHnAVbGeiIHy nTEAoKGU7zm+ft+4CDMrQvzNzPQRXZJO =ei66 -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] IMember: does it exist?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 8, 2008, at 01:32 , Paul Winkler wrote: > Rob Miller <[EMAIL PROTECTED]> writes: >> then CMF does it's normal wrapping of these user objects using the >> standard >> MemberData implementation. > > Hmm, right, so then this might still be on-topic here ;-) > Maybe the right thing is for CMF to do a directlyProvides() call in > wrapUser? The CMF itself doesn't need this. There's no place that tries to ensure a member does indeed provide IMemberData or similar. If this is something you need for Plone I'm happy to consider patches with tests. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjsYVsACgkQRAx5nvEhZLKp+wCeNXxY6pPNfOSf9TEHnt71bPOJ 2A8AoKp6Y73R2YLRPJ699edbJWRPzplv =bVJl -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 On Oct 6, 2008, at 09:21 , 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? If all you want to do is tweak the main_template then a branch is overkill. I'd work directly on the trunk for that. >>> 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. No worries, you've obviously done your homework. And thanks for taking this up, the current template has indeed aged a lot. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjpwq0ACgkQRAx5nvEhZLL4zQCfRAYaFeglskxTGSrCmMGEWWOY KhsAn1XneYNjThMRi9RFpJTApeTF2RhF =wvkC -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 On Oct 5, 2008, at 20:06 , Charlie Clark wrote: > now that I've got my own branch I've finally made a start on a pure > CSS version of main_template.pr for CMFDefault. 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 ;-) > 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'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. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjpVRAACgkQRAx5nvEhZLKTNQCgs3pmw9BO48mfjL7mm/Qwr/ut CZMAoLf+cGMThVL78uyftDpAA+QLMCRc =n+t3 -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] portal_fiveactions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 4, 2008, at 17:28 , Hanno Schlichting wrote: > Jens Vagelpohl wrote: >> Is anyone actually using the portal_fiveactions tool and the supposed >> bridging between Z3 menus and CMF actions it is promising? I'm >> wondering if it's dead wood we're carrying around since it really has >> not been touched much after the initial import: > > I think nobody is using it. > > I doubt it works with "new-style" CMF actions anyways. Just for clarification: The "Five Actions Tool" does not replace the normal actions tool, it's a separate tool that acts as an action provider providing only those "bridged" menu actions. So it's legitimate if it doesn't care about old- or new-style actions. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjoc/8ACgkQRAx5nvEhZLJzIACfer/fUdO8crZmWmXoXDEoNGSK 14UAn3D/uHVi3o0JlFnAdXOji7NyWqJF =81R8 -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] portal_fiveactions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 4, 2008, at 17:28 , Hanno Schlichting wrote: > Jens Vagelpohl wrote: >> Is anyone actually using the portal_fiveactions tool and the supposed >> bridging between Z3 menus and CMF actions it is promising? I'm >> wondering if it's dead wood we're carrying around since it really has >> not been touched much after the initial import: > > I think nobody is using it. > > I doubt it works with "new-style" CMF actions anyways. A quick glance at the code tells me it does not consider either old- or new-style actions at all. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjnjF8ACgkQRAx5nvEhZLJ3TACeJuI2FVRX/m2HfSpdtvrnfZ6o 8XAAn1epQOrlGzFMGYZJ1tzX4/bCCsOl =rzES -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] portal_fiveactions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is anyone actually using the portal_fiveactions tool and the supposed bridging between Z3 menus and CMF actions it is promising? I'm wondering if it's dead wood we're carrying around since it really has not been touched much after the initial import: http://svn.zope.org/?rev=38594&view=rev jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjnft8ACgkQRAx5nvEhZLKQGwCghytyJZJdib/bhkQoEbaqgP5+ ZZQAnRmSfPpu25isTekm9Gn06oyROocO =vDvl -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] IMember: does it exist?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 2, 2008, at 20:32 , Paul Winkler wrote: > But there does not seem to be any such interface as IMember. > I've grepped everywhere I can think of. > > There probably should be :) I'd say that's a typo. The referenced IMember probably means the IMemberData interface, which does exist. If no one complains I'll change it over the next few days. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjlGnoACgkQRAx5nvEhZLIP2QCdHGTywTw3JResbScmc+yHu+3x 2ycAn3u2I09zBcH7v9nGom0KvscI1LI3 =dwXE -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' actions and views - a proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 24, 2008, at 13:27 , yuppie wrote: > Ok. I checked in all my local changes. AFAICS everything works fine, > but > tests are still missing. > > Please note that so far only File has a full add view. All other > content > types use the fallback add view. > > I still use the pattern that adapts ITypeInformation as well. Our add > views are anyway Zope 2 specific, so I don't think requiring explicit > Zope 2 security declarations is unacceptable. All other solutions have > also their drawbacks. Housekeeping question: Do you think https://bugs.launchpad.net/zope-cmf/+bug/161664 is done with what's on the trunk now? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjb+AEACgkQRAx5nvEhZLKukQCfYVli5u+UgsDmyvU0dwmOQiRq HE0AoLPWVJZH1bXgmnomeUbCPk3N6Gqk =az3z -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] actions tool import/export inconsistencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 25, 2008, at 11:10 , yuppie wrote: >> While you still can use the Action tabs, it is no longer recommended > since CMF 2.0 and the export/import machinery moves Actions from those > tabs to the recommended place. Have we made any explicit announcement to that effect or warned people? I must have missed it if there was one. There's no DeprecationWarnings anywhere (yet). I've always been aware of the general direction to move away from old-style actions, but haven't seen any concrete communication to the community, especially the Plone guys. >> The main discrepancy is in the handling of action providers that are >> not 'portal_actions', 'portal_types' or 'portal_workflow'. Their data >> is exported, but they are not re-added to the actions tool during >> import. Also, the BBB note about "CMF 1.6 profiles" is confusing. >> That >> mechanism is still in use today, it hasn't been discarded after 1.6. > > It might not have been the best idea to make implicit migrations on > import. Anyway. We now are talking about CMF 2.2 and most people > should > meanwhile have migrated their 'normal' Actions to portal_actions. So > I'm > fine with removing the migration code. I'll add a big warning on the Actions tab code so people see it when they go to the tab in the ZMI. >> - the old-style action information data should not be handled >> centrally by the actions tool export/import, unless those actions are >> on the actions tool itself. All other providers should export/import >> their old-style actions themselves. > > +1 for making the handler of each tool responsible for its Actions > > But I propose to add deprecation warnings for 'normal' Actions (not > type > Actions) stored in Actions tabs. People did have enough time to move > those Actions to the Actions tool. And if 'normal' oldstyle Actions > are > deprecated, we don't have to provide export/import support for them. I'll try to find some good places for DeprecationWarnings in the ActionProviderBase class. Unfortunately, since there hasn't been any deprecation warning, we'll have to wait for a while to start removing code :-( jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjbWM0ACgkQRAx5nvEhZLI7fACfdaa2GKUkysB+BXucL/u9hy+r ryYAn33bx2Amg2pjQF20ziNptlMWSzDR =WnhW -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] actions tool import/export inconsistencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 An open Launchpad issue had me take a look at the import/export machinery for the actions tool and action providers (https://bugs.launchpad.net/zope-cmf/+bug/177675 ). I see some inconsistencies and would like to get rid of them. Here's the behavior I read out of the code: Export: - _all_ action providers known to the actions tool are written to actions.xml as "action-provider" nodes - if an action provider contains "old-style" actions, those are exported as children of the corresponding "action-provider" node. Curiously, that action information export is marked "BBB: for CMF 1.6 profiles". Import: - the "action-provider" nodes are added to the actions tool if they do not exist _and_ if their IDs happen to be 'portal_actions', 'portal_types' or 'portal_workflow'. None of the other "action- provider" nodes are added. - if the "action-provider" node has children of type "action", their data is imported and recreated on the respective provider as "old- style" actions. This is also marked as "BBB: for CMF 1.6 profiles". The main discrepancy is in the handling of action providers that are not 'portal_actions', 'portal_types' or 'portal_workflow'. Their data is exported, but they are not re-added to the actions tool during import. Also, the BBB note about "CMF 1.6 profiles" is confusing. That mechanism is still in use today, it hasn't been discarded after 1.6. I would like to change the actions tool import/export code so it does the following: - all action-provider nodes from the export should be added to the actions tool during import if they are not already registered there. - the old-style action information data should not be handled centrally by the actions tool export/import, unless those actions are on the actions tool itself. All other providers should export/import their old-style actions themselves. - clarify the BBB comment jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaqmQACgkQRAx5nvEhZLJvYACcDRd6g9jfqs0EdPlkGgUMCh6T GoQAnjOtGyiWIn+IDsB3sw/62Dzetn0G =PfzS -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 On Sep 23, 2008, at 23:27 , Wichert Akkerman wrote: > Previously Jens Vagelpohl wrote: >> As you already found, the ICMFDublinCore should be supported by both, >> right? > > Except for the fact that no CMF (or AT) content type uses the > zope.dublincore variant? ICMFDublinCore is also much more than I'm > interested in - IDCTimes is all I need. I see that IDCTimes provides the "created" and "modified" schema attributes. CMFDefault's DublinCore has "created" and "modified" methods that return the same thing, DateTime instances. If you wanted to force the ICMFDublinCore semantics into the CMF it looks like you would have to change a ton of code that expects those two to be a method. Is that really worth it? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjZ61AACgkQRAx5nvEhZLLT0wCffvI28GiXL1LQNP8PumMWy0v3 ixEAoJjMKjvfX6bZbBNQrIEDtdoXSLjC =Qh8o -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 On Sep 23, 2008, at 19:19 , Wichert Akkerman wrote: > Previously Jens Vagelpohl wrote: >> On Sep 23, 2008, at 17:01 , Wichert Akkerman wrote: >> >>> Are there any objections to making the CMFCore interfaces derived >>> classes from zope.dublincore, or possibly even using those directly >>> where possible? >> >> Do you see any specific benefit, more than just "replace our code >> with >> other code to shift the maintenance burden"? > > I found myself writing some code which needs to get dublin core data > from > content and should work for both zope3 and zope2 applications, except > for the difference in interfaces. As you already found, the ICMFDublinCore should be supported by both, right? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjZJrwACgkQRAx5nvEhZLLyQgCgrUojEKCwI6P5I8jvU4WNQbbr ZI4AnjesKxD+A/GNmICYY3bqlp5UrdSk =HDOn -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 On Sep 23, 2008, at 18:09 , Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Wichert Akkerman wrote: >> 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. The zope.dublincore code hasn't seen any maintenance since being "exploded" out into a separate egg, this is true. In all fairness, the DublinCore module in CMFDefault hasn't seen many changes that are specifically Dublin Core-related, either, but then again it hasn't needed much. It's been working very well with very little maintenance. "Don't fix it if it ain't broke" and keep what we have is what I'd say here. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjZFyUACgkQRAx5nvEhZLLLjACguy8f+yHpK23ak85LRwQ4r+e7 jvoAniuld7BlxLo4sHR/Jxf8UfawpNgM =tyfE -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 On Sep 23, 2008, at 17:01 , 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? Do you see any specific benefit, more than just "replace our code with other code to shift the maintenance burden"? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjZEaIACgkQRAx5nvEhZLIXggCfTlhL6W3aWonllp8ZteSLLnKb T1UAoJlAkKXVLAX/A9aF6fJK1wYICjsu =k4fA -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' actions and views - a proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 19, 2008, at 14:12 , yuppie wrote: > If there are no objections, I'll make the proposed changes on the > trunk. Thanks for taking the time to discuss and think through all of this. > @ Jens: When exactly do you want to make the beta release? When you're done? ;-) Remember, I only suggested making the release a few weeks ago because I had some sprint-time I could devote to cleanup and bug squashing as a preparation. No one specifically asked for it (yet). jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjTq/kACgkQRAx5nvEhZLJO2gCfTZbwuKTQBUAbq1VNIHdsi50J sMMAn0A2FDSN3GN0P/oDRV8xJWxlXljS =06Ys -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
On Sep 18, 2008, at 11:13 , yuppie wrote:
>> - extend the "old-style" actions, those you see e.g. on a type
>> information "Actions" tab in the ZMI, to also have a field for an
>> icon
>> URL expression
>
> That might have been the most pragmatic solution, but in the long
> run we
> should not maintain two different Action machineries.
You are totally right of course. Doing that wholesale switchover and
replacement simply wasn't something I could get done for 2.2.0. I
thought about that many times as I went through all the places that do
define actions. Actually there's not two, but three different
machineries in play when you consider the workflow actions, and those
workflow actions are the strangest because they don't use TAL
expressions but string replacement to expand the expression-style
fields.
> I personally prefer to move all type info Actions to the actions
> tool. I
> can't see a need to specify separate 'view', 'edit' or 'metadata'
> Actions for each content type. That just makes it necessary to
> maintain
> a lot of redundant configuration data. In how many places did you have
> to set "string:${portal_url}/edit_icon.png"?
>
> Some Actions like 'download' should only be available for specific
> portal types. That makes things a bit more complicated, but can be
> solved.
>
> If people really want to maintain separate Actions for each type, we
> should consider to make type infos containers for new-style Actions.
Yes, there's redundant information in many places. Collecting all
actions in the actions tool itself would be the cleanest way, but a
more manageable first step would be making type information objects
into action containers as you suggest. The same could be applied to
DCWorkflow Worklist and Transition definitions.
I have added a Launchpad "blueprint":
https://blueprints.launchpad.net/zope-cmf/+spec/unify-actions
Collecting our projects as blueprints has the advantage that there's a
single place to track all of them, with concise information about the
task and who's doing/reviewing it:
https://blueprints.launchpad.net/zope-cmf
jens
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkjSIgEACgkQRAx5nvEhZLLkLQCdEzmo0d0va5kM6XnsOfX/bjAx
ngQAoIgXB7Evu//jpFDtU7kCGf1czYNE
=TRp9
-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 On Sep 18, 2008, at 09:56 , Wichert Akkerman wrote: >> 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. > > Are they png images? If not, can we please make them png so we can > easily customize them using alpha channels? Of course they are. I thought you were on the checkins list ;-) jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjSCrsACgkQRAx5nvEhZLLgcACfSLTBPP+RltwJdNOSH9HZBljS cWQAn1kw9aI1dyLyrwVjyTZlYCnx8z3+ =1/A3 -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 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. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjSCNMACgkQRAx5nvEhZLIF7wCdFFBqbko8L5ACgR1WZ9NzOox2 5fUAn3X8uo6AcJsBEzq9mOJbrQh0K+TA =oW68 -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 On Sep 14, 2008, at 12:26 , yuppie wrote: > 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: We're down to 2 at this point and I need to take off very soon, so here's a very quick assessment from Tres and me: > 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. This looks like a good solution. I believe Zope 3 uses the same or a similar style. > 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. I'm not sure, hoping for comments from others. > 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. I agree. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjM7HQACgkQRAx5nvEhZLKPOACgpWQjPFL9o0Fng8WtLMSPRfSZ 3ZEAoJoWo0XGe00MXNwI2+aLmsYRxm6L =Scef -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 On Sep 14, 2008, at 06:35 , Wichert Akkerman wrote: > Previously Martin Aspeli wrote: >> 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? >> >> +1 - CMFActionIcons is a bit of a nuisance these days. I never >> understood why you'd need to separate the definition of the action >> (in >> the ZMI or GS) from its icon. > > Easier customization - no need to let people touch the action itself? Just at the high price of maintaining a full separate Zope product. That trade-off seems a bit lame. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjMyPMACgkQRAx5nvEhZLKmwgCfULE4/0dSmqPVdPo0NWRYypB4 Yx8AoJFGKJX7x6yImrRRsnSQFvHHZRMt =GceZ -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] CMFActionIcons vs. new-style actions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today I was looking at the CMFActionIcons product and wondered about a few things. First of all, there's no obvious way to enable the actions and include the template snippets that pull them in. Editing the main_template is needed. Secondly, the new-style actions already define a property to store an expression for generating a icon path, but it doesn't appear to be used anywhere yet. 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? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjLv/AACgkQRAx5nvEhZLLeygCfbw/3TV02VHFczUW/MGKtSa+h u7YAn2zw5mIWLkIa+214a53YOsTzLlJS =cxAi -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 2.2.0 beta
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 12, 2008, at 13:20 , yuppie wrote: > Jens Vagelpohl wrote: >> On Sep 12, 2008, at 10:58 , yuppie wrote: >>> It also would be nice if someone could 'merge' the DEPENDENCIES.txt >>> files into the setup.py files. [3] >> >> I alread did that two weeks ago. > > Great. But if all the information is now in setup.py, why didn't you > remove the DEPENDENCIES.txt files? I've done that now, and backported all that and your changes to the 2.1 branch(es). jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjKV6wACgkQRAx5nvEhZLIhEwCgkRzX5Et5i9C+RhSBWKmZLYl4 A+8An3Vp+M1UdaPTuhoprUNSGrQv5fNq =lFkK -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 2.2.0 beta
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 12, 2008, at 13:20 , yuppie wrote: > Jens Vagelpohl wrote: >> On Sep 12, 2008, at 10:58 , yuppie wrote: >>> It also would be nice if someone could 'merge' the DEPENDENCIES.txt >>> files into the setup.py files. [3] >> >> I alread did that two weeks ago. > > Great. But if all the information is now in setup.py, why didn't you > remove the DEPENDENCIES.txt files? No particular reason. Go ahead if you're already in there. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjKUcMACgkQRAx5nvEhZLJRWACgjqDpyT0qVMv26T8PX6+AD0YX 9dYAoJj/m0tRYwB8O2JlDXOUKdClc2ND =ETY9 -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] CMFDefault 2.1.2-beta egg does not install
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 10, 2008, at 07:53 , Wichert Akkerman wrote: > Jens, can you please cut a new beta egg so we can move forward with > Plone 3.2? Now that we have eggs and releases can be done quickly I'd like to do away with having several betas. Anyone against calling the current state 2.1.2 final? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjKPwMACgkQRAx5nvEhZLIhVgCgo0J27oJmg8YPMfeP3zf3s0ma ZakAnjfhkR4ajyXdwnQtiqoMtKQUMvJ/ =CKMT -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 2.2.0 beta
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 12, 2008, at 10:58 , yuppie wrote: > Jens Vagelpohl wrote: >> Is there anything to hold back a CMF 2.2.0 beta at this point? > > I'd like to finish the add menu changes first. My last proposal[1] is > not implemented because Martin convinced me to choose an other > solution[2]. > > Next week I'll have time to write and implement a new proposal. OK, sounds good. I only suggested it because I have time to do it this weekend. > It also would be nice if someone could 'merge' the DEPENDENCIES.txt > files into the setup.py files. [3] I alread did that two weeks ago. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjKPU8ACgkQRAx5nvEhZLJmSQCggTvswNNEKGPqM4joE6ULect6 SJ8AnRR/h3QabuciQtl4FrKB6ddkF+GN =BJEM -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] CMF 2.2.0 beta
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is there anything to hold back a CMF 2.2.0 beta at this point? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjJO30ACgkQRAx5nvEhZLITwACgjy/aSRfk8vcBLgfwp1DllhLT ZVcAoKKYePHYEzv3rJVqTdyiN4WGPOO0 =dGAA -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] CMFDefault 2.1.2-beta egg does not install
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 By the way, DCWorkflow needed a similar change to make that same traceback disappear, which means Wichert was testing CMFCore in isolation. If possible, could we make sure to test all CMF packages together when making changes? I'm using a simple buildout that pulls them all in: http://svn.dataflake.org/svn/sandboxes/cmf-21/ http://svn.dataflake.org/svn/sandboxes/cmf-trunk/ jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjIy9MACgkQRAx5nvEhZLJ/OgCeJ336V416RlDCgKb84vJ/+HfG n4kAn1Vx04WGs87eXStNRpkFJVAvpN+r =xc+j -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] CMFDefault 2.1.2-beta egg does not install
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 10, 2008, at 07:53 , Wichert Akkerman wrote:
> Previously Wichert Akkerman wrote:
>> Ah, I complained about that to Jens: he pinned the CMF eggs to an
>> exact
>> version of GenericSetup, which makes them impossible to use for Plone
>> which requires a later version.
>>
>> Can these please be changed to a minimum version requirement
>> instead of
>> an exact pin?
>
> I've loosened the version restriction in CMF 2.1 to only use a minimum
> version requirement for GenericSetup, which makes it possible to use
> CMF
> with Plone 3.2 and later again.
>
> Jens, can you please cut a new beta egg so we can move forward with
> Plone 3.2?
There is a reason why originally I pinned the egg at 1.33, and later
relaxed the pin to allow anything 1.3.x: I see test failures with the
1.4.1 egg. Please run the tests with the GS 1.4.1 egg and let me know
what you see. I am seeing errors like this:
raise ConfigurationError("Unknown directive", ns, n)
zope.configuration.xmlconfig.ZopeXMLConfigurationError: File "/usr/
local/zope/cmf-21/eggs/Products.GenericSetup-1.4.1-py2.4.egg/Products/
GenericSetup/configure.zcml", line 62.2
ConfigurationError: ('Unknown directive',
u'http://namespaces.zope.org/genericsetup'
, u'exportStep')
jens
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkjHlFIACgkQRAx5nvEhZLJVvgCdErnPgh8wkcceVWrcvzksL+Uf
xU4An0QP9lX5EmVr9qW01Ii7b9Id7u+f
=d29g
-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] CMFDefault 2.1.2-beta egg does not install
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 8, 2008, at 07:03 , Wichert Akkerman wrote: > While working on plonenext I get an error when trying to install > the Products.CMFDefault egg. It works fine for me in a simple buildout that installs CMFDefault into an instance. I get the 2.1.2-beta egg, all the dependencies are pulled correctly, and the tests run. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjE0P8ACgkQRAx5nvEhZLKwZgCfScn9dzTaqQWujUpDu5AgAr0t xu4AoLQyson8dgLQpfb4Yj1eMdav7rki =XMRw -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 On Aug 3, 2008, at 18:19 , Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I created "satellite" versions of the 2.1.1 eggs for the remaining CMF > products this morning: The whole CMF 2.1-branch is eggified now, and just like on the trunk the toplevel SN folder /CMF/branches/2.1 contains svn:externals links to the respective products. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAki1aAIACgkQRAx5nvEhZLKYkgCfYWsIYU3O+2/npvDZ96HtO+sR 3PUAoJjd0Ov2TphVE69RDkwPK+HQ63rJ =N3LP -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
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. jens ___ 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
Re: [Zope-CMF] [dev] more add menu changes
On Aug 7, 2008, at 12:26 , yuppie wrote: Proposal 1: allowedContentTypes --- This PortalFolder method is used by folder_factories and by folder_contents to decide if the 'New...' button is added. I propose to add a new skip_add_views argument to allowedContentTypes. If true, newstyle types are skipped. Proposal 2: main_template - CMFDefault menus are implemented in main_template. I propose to add a new section for 'folder/add' actions. If there are no objections I'll make these changes on trunk. +1 jens ___ 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
Re: [Zope-CMF] [dev] type infos and 'add' actions - a proposal
On Jul 21, 2008, at 12:51 , 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 +1 from me. Thanks for proactively taking this on. jens ___ 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
Re: [Zope-CMF] Packaging for Products.GenericSetup and others
I have now implemented this policy for the trunk and current release branches of Products.GenericSetup, Products.PluginRegistry and Products.PluggableAuthService: - releases and information have their canonical location on PyPI Done: changed the "url" metadata in setup.py - the zope.org GS pages are changed to refer people to the PyPI page and new tarballs will not be stored there anymore Done on the respective package "home pages" on zope.org. - the package documentation will include hints on how to use the Products.GenericSetup tarball for those people who expect the old (flat) tarball structure Documented in each package's README - (cosmetic) the GS CHANGES and README files are redone to provide valid ReST so the PyPI page looks pretty. Done by reformatting each package's README and INSTALL files, which comprise the documentation shown on the PyPI page for each release. As noted before, if someone like Wichert still needs an old-style tarball put onto zope.org I'll be happy to do so _on request_ (not automatically) and only for the current release branch. jens ___ 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
Re: [Zope-CMF] Packaging for Products.GenericSetup and others
On Jun 11, 2008, at 14:31 , Wichert Akkerman wrote: Previously Jens Vagelpohl wrote: Hi guys, I'm wondering about the need to provide tarballs for GenericSetup through zope.org alongside the tarball on PyPI. It's extra work and the GenericSetup pages on zope.org don't offer any added value over its PyPI page. We'll keep using tarballs for Plone 3.1.x maintenance releases. We may switch to the egg variant for Plone 3.2, but not before. For the current release branch I would not have a problem making the tarball manually alongside the PyPI releases if you need them and give me a heads-up about what you need. jens ___ 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] Packaging for Products.GenericSetup and others
Hi guys, I'm wondering about the need to provide tarballs for GenericSetup through zope.org alongside the tarball on PyPI. It's extra work and the GenericSetup pages on zope.org don't offer any added value over its PyPI page. In order to simplify release management I propose the following: - releases and information have their canonical location on PyPI - the zope.org GS pages are changed to refer people to the PyPI page and new tarballs will not be stored there anymore - the package documentation will include hints on how to use the Products.GenericSetup tarball for those people who expect the old (flat) tarball structure - (cosmetic) the GS CHANGES and README files are redone to provide valid ReST so the PyPI page looks pretty. I would volunteer to do all that. Any opinions? jens P.S.: The same issue is true (and I would volunteer to handle them) for a few other already-eggified packages, Products.PluginRegistry and Products.PluggableAuthService come to mind. ___ 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
Re: [Zope-CMF] cmfuid and zope.app.intids
On May 29, 2008, at 15:10 , Miles wrote: - Has anyone used zope.app.intids at all, or done anything similar? No to both - Does this sound achievable at all? I'd think so. - Is this a generally useful thing to do? From the standpoint of trying to prevent reinventing wheels all over the place it sounds like a good idea to re-use a Zope 3 component. However, beware of backwards-compatibility in terms of software and in terms of persistent data generated by the existing version. Like Tres always says, "persistence means always having to say you're sorry". Essentially, if you can do it while retaining backwards compatibility I'd be all for it. jens ___ 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
Re: [Zope-CMF] Re: License file question
On May 29, 2008, at 08:34 , Wichert Akkerman wrote: Previously Maurits van Rees wrote: Suits me fine. Anyone in favour of updating the ZopeSkel templates to fit that pattern? (Sorry, bit out of topic here on the cmf list as there are no cmf skeletons there. Care to add one? :-)) -1 I want all documentation to be the first thing I see when I unpack something. I don't want to be forced to delve into 3 or 4 subdirectories. This is veering off course a little, a discussion about ZopeSkel handles this should probabably happen elsewhere ;-) I know how I'll proceed with the CMF packages. jens ___ 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
Re: [Zope-CMF] Re: License file question
On May 29, 2008, at 04:19 , Philipp von Weitershausen wrote: [1] http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt Ah, good resource, thanks for pointing that out. Thanks to everyone for the input. I'll go with putting the license file right with the software instead of into a docs folder at the top where setup.py resides. I find it more intuitive to have all documentation where the software is, and leave the "egg scaffolding" in a state where you don't have to touch anything "up high" once it's working. jens ___ 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] License file question
Just wondering: Now that we are splitting the CMF down into its constituent packages and people don't need to get the old-fashioned tarball, do we need to have a copy of the LICENSE.txt file in every package? And if yes, where would it go? It could go into each subpackage toplevel folder, where the setup.py resides, or down into the software folder where the other text files (README, CHANGES. etc) are located. jens ___ 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
Re: [Zope-CMF] Re: [dev] newstyle content creation
On Apr 23, 2008, at 17:46 , Charlie Clark wrote: BTW. got bitten by the five.localsitemanager dependency with my 2.10 install. I've just reread the posts on this and I didn't quite understand them. Things worked fine, of course, when I dropped CMFCore/src/five into my lib/python folder but I'm guessing this is something that's going to be phased out and that we're expecting users to be able to install the package separately themselves. Is this assumption correct? This is correct. If I remember correctly you can just easy_install it. You can also get it from SVN and link it into your instance's lib/ python folder. jens ___ 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
Re: [Zope-CMF] GS 1.4 release
On Mar 22, 2008, at 13:09 , Wichert Akkerman wrote: Plone 3.1rc1 is scheduled for release this Wednesday. I would like to include a new GenericSetup release to get r84623 in. Would it be possible for someone (Jens or Tres I assume) to make a new release? http://www.zope.org/Products/GenericSetup/GenericSetup-1.4.0 http://pypi.python.org/pypi/Products.GenericSetup/1.4.0 Let me know if you have any prolems with the release files. jens ___ 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
Re: [Zope-CMF] GS 1.4 release
On Mar 22, 2008, at 13:09 , Wichert Akkerman wrote: Plone 3.1rc1 is scheduled for release this Wednesday. I would like to include a new GenericSetup release to get r84623 in. Would it be possible for someone (Jens or Tres I assume) to make a new release? Sure, I can do it this weekend. jens ___ 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
Re: [Zope-CMF] Re: GenericSetup 1.4 release
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. jens ___ 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
Re: [Zope-CMF] Re: GenericSetup 1.4 release
On Mar 3, 2008, at 00:14 , Tres Seaver wrote: -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). There's a tarball/zipfile here: http://www.zope.org/Products/GenericSetup/GenericSetup-1.4.0-beta and an egg here: http://pypi.python.org/pypi/Products.GenericSetup Please take a look at the egg, if that's what you will be using, and let me know if it's OK (contains all files, no extraneous files, etc) since I'm not very well versed in doing the whole egg thing. jens ___ 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
Re: [Zope-CMF] Re: GenericSetup 1.4 release
On Mar 7, 2008, at 14:11 , Tres Seaver wrote: -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'. I'll keep running tests within an instance with "zopectl" for now and consider thinks OK when that works. jens ___ 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
Re: [Zope-CMF] Re: GenericSetup 1.4 release
On Mar 7, 2008, at 13:26 , yuppie wrote: Looks like five.localsitemanager is missing in your setup. Yuppie That's it, great catch! 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!). jens ___ 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
Re: [Zope-CMF] Re: GenericSetup 1.4 release
On Mar 7, 2008, at 11:00 , Wichert Akkerman wrote:
I'm happy to see there are no objections. Who is going to make that
release? Jens hasn't responded so perhaps someone else will need
to do
that. Tres, can you take care of this?
I haven't had any time this week. I may be able to do it some time
today.
Thanks Jens, that would be much appreciated. FYI I've pushed back the
Plone 3.1 release to Sunday noon CET, so I no longer need this release
today; tomorrow will be fine as well.
I'm running the tests on the current GS trunk and see a dozen errors
like the traceback below. Right now my setup is Zope from the 2.10
branch after 2.10.4, maybe a few weeks old. I'm not using buildout or
easy_install, I simply link /Products/GenericSetup folder into my
instance's Products Folder the old-fashioned way, and then use "bin/
zopectl test" to run the tests. Does anyone else see these?
jens
Error in test
test_runAllImportSteps_unicode_profile_id_creates_reports
(Products.GenericSetup.tests.test_tool.SetupToolTests)
Traceback (most recent call last):
File "/usr/local/zope/src/Zope-2.10-branch/lib/python/Testing/
ZopeTestCase/profiler.py", line 98, in __call__
testMethod()
File "/usr/local/zope/210Instance/Products/GenericSetup/tests/
test_tool.py", line 447, in
test_runAllImportSteps_unicode_profile_id_creates_reports
tool.runAllImportStepsFromProfile(PROFILE_ID)
File "/usr/local/zope/210Instance/Products/GenericSetup/tool.py",
line 390, in runAllImportStepsFromProfile
ignore_dependencies=ignore_dependencies)
File "/usr/local/zope/210Instance/Products/GenericSetup/tool.py",
line 1180, in _runImportStepsFromContext
message = self._doRunImportStep(step, context)
File "/usr/local/zope/210Instance/Products/GenericSetup/tool.py",
line 1094, in _doRunImportStep
return handler(context)
File "/usr/local/zope/210Instance/Products/GenericSetup/
components.py", line 242, in importComponentRegistry
sm = getSiteManager(context.getSite())
File "/usr/local/zope/opt/Zope-2.10-branch/lib/python/zope/
component/_api.py", line 48, in getSiteManager
raise ComponentLookupError(*error.args)
ComponentLookupError: ('Could not adapt', ,
)
___
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
Re: [Zope-CMF] Re: GenericSetup 1.4 release
On Mar 7, 2008, at 09:37 , Wichert Akkerman wrote: Previously Tres Seaver wrote: -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). I'm happy to see there are no objections. Who is going to make that release? Jens hasn't responded so perhaps someone else will need to do that. Tres, can you take care of this? I haven't had any time this week. I may be able to do it some time today. jens ___ 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
Re: [Zope-CMF] Re: What is the status of GS wiping catalog indexes on catalog.xml import?
On Feb 29, 2008, at 21:08 , Martin Aspeli wrote: Jens Vagelpohl wrote: On Feb 29, 2008, at 10:00 , Andreas Jung wrote: You don't have to wait for for new Zope versions. Defining the interface officially in Zope 2.10, 2.11 and trunk will raise no problems. I have no problems with putting this into the official release branches - or? My personal opinion: I'd rather see the interface-based solution in a few weeks or a couple months (the next Zope release) than the, umh, less-than-professional solution that will stick around forever. As such solutions have a tendency to do. "It works now" absolves everyone from the task to come back later and improve the solution, so no one does. I agree in principle, however this has been left unresolved for far too long. I'm glad things are happening now, though! I agree that something had been left unresolved, but it's a bit odd if an issue languishes in the collector for a long time and then all of a sudden several people come along and say it's a big deal. It can't be such a big deal if there were no complaints in a long time. Anyway, it appears Andreas' interface additions, even though they may not be the final solution, pointed us there. Someone can amend that interface to everyones' linking and we have it in the next Zope releases. After that, it's a matter of adding adapter code to GS. jens ___ 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
