Re: [Zope-CMF] [Checkins] SVN: Products.CMFCore/trunk/ - fixed Zope 2.12 compatibility
Hi. On Sat, Dec 26, 2009 at 6:25 PM, Yvo Schubbe y.2...@wcm-solutions.de wrote: Log message for revision 107108: - fixed Zope 2.12 compatibility Just to make this explicit: CMF trunk should continue to run with Zope 2.12 and not only with 2.13, correct? If so, I'll add a second test runner to the buildout, so it's easier to ensure this. On a related note, if I'm going to backport the five.formlib extraction to 2.12, it would it be ok to depend on a 2.12.3 release for CMF 2.2 with this stuff in it, right? Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup and PluggableAuthService
On Wed, Dec 30, 2009 at 4:19 PM, Jens Vagelpohl j...@dataflake.org wrote:
In the debugger I see that the object in question is a absolute_url
adapter residing in the base component registry in the site root. IMHO
the components exporter should not look at the base registry at all,
only a local registry if one exists in the folder the tool sits in. Correct?
Right. As you noticed nobody ever tried to use GS outside a CMF/Plone context :)
The code in question does a:
sm = getSiteManager(context.getSite())
That will get the nearest site manager, which in case of CMF will
always be the one in the CMF site root.
What you want is probably something like this:
from zope.component.interfaces import ComponentLookupError
from zope.component.interfaces import IComponentRegistry
from zope.location.interfaces import IPossibleSite
def importComponentRegistry(context):
Import local components.
# context is the portal_setup tool
# getSite is GS API to get the parent
site = context.getSite()
sm = None
if IPossibleSite.providedBy(site):
# All object managers are an IPossibleSite, but this
# defines the getSiteManager method to be available
try:
sm = site.getSiteManager()
except ComponentLookupError:
sm = None
if sm is None or not IComponentRegistry.providedBy(sm):
logger = context.getLogger('componentregistry')
logger.info(Can not register components, as no registry was found.)
return
importer = queryMultiAdapter((sm, context), IBody)
if importer:
body = context.readDataFile('componentregistry.xml')
if body is not None:
importer.body = body
And then adjust exportComponentRegistry in a similar way. This is
untested code :)
Hanno
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [GS] Execution order of steps (import handler executed before tool creation)
Hi. 2010/1/23 Andreas Jung li...@zopyx.com: I am currently in trouble with the imports of a particular Plone product (CMFBibliographyAT). I'm pretty sure I've helped Martin to fix this in a branch for CMFBibliographyAT. Martin, did you check in your work from the last Tune-Up? What happened there, was an error earlier up in the GS steps (look up in the log), which prevented the tool from being created. But maybe this is also something new. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://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
2010/3/31 Tres Seaver tsea...@palladion.com:
I believe the root of this problem is that the 'index' and 'versions'
bits of a buildout.cfg are effectively Highlanders (there can only be
one). I gave up on trying to get the two, two, two Zopes in one
buildout to work, and instead created a separate buildout.cfg for
running CMF's tests against Zope 2.12.3.
Yeah, that sounds sensible. The extra test part with an index was a
hack in the first place.
Unless somebody objects violently, I plan to check the attached config
in on a branch of the main CMF buildout, and rip out the stuff which
tries to do both from the trunk version. This change will require
Stefan's nightly runner to be adjusted, so I'm CC'ing him.
Looks all good, except for this first line of comment, which should be
CMF trunk + Zope 2.12 :)
# CMF trunk + Zope trunk
Personally I prefer versions.cfg files, so we could use an:
extends = http://download.zope.org/Zope2/index/2.12.3/versions.cfg
instead of the index = line. But I don't care much for this specific
test buildout.
[buildout]
parts =
zopepy
test
eggs =
Zope2
Products.CMFCalendar
Products.CMFCore [test]
Products.CMFDefault
Products.CMFTopic
Products.CMFUid
Products.DCWorkflow
Products.GenericSetup
five.localsitemanager
develop =
src/Products.CMFCalendar
src/Products.CMFCore
src/Products.CMFDefault
src/Products.CMFTopic
src/Products.CMFUid
src/Products.DCWorkflow
src/Products.GenericSetup
src/five.localsitemanager
index = http://download.zope.org/Zope2/index/2.12.3
[versions]
# CMF-only dependencies
five.formlib = 1.0.2
[zopepy]
recipe = zc.recipe.egg
eggs = ${buildout:eggs}
interpreter = zopepy
scripts = zopepy
[test]
recipe = zc.recipe.testrunner
eggs = ${buildout:eggs}
defaults = ['--module', '^Products[.](CMF|DC|GenericSetup)|^five[.]']
___
Zope-CMF maillist - Zope-CMF@zope.org
https://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
On Wed, Mar 31, 2010 at 8:33 PM, Tres Seaver tsea...@palladion.com wrote: OK, the change I'm planning on the trunk essentially reverts your last commit (all the extra version pins to make the 'test-zope212' part build), plus deleting the test-zope212 part (see attached patch). Sure. That wasn't much more than a band-aid. BTW, I think the other test buildouts which do not run aganst the Zope2 trunk should probably also be adjusted to use released Zope 2.12.x eggs as well: we aren't co-developing the Zope 2.12 branch along with CMF 2.2 (any more, at least). Well, it is nice to catch problems introduced in Zope 2 on the day after they are made. And not when someone tries to update the buildout to a new version at some later point. The risk is much lower for stable branches, but it still exists. As seen from todays test failures, they nicely showed how I screwed some things up a bit too much on Zope trunk :) I also don't know why the 'instance' and 'i18n*' parts are configured in these buildouts -- does somebody have a memory of why, or a reason to keep them? Yvo has to comment this. I think he sometimes rebuilds the pot files in CMF with the i18n part. Not sure about the instance. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: CMF.buildout/trunk/src/ Don't use http:// externals for CMF externals.
On Thu, Apr 1, 2010 at 1:24 PM, yuppie y.2...@wcm-solutions.de wrote: Jens Vagelpohl wrote: Bringing up that question again certainly doesn't do any harm. I personally have no objections to using relative SVN URLs. I don't plan to bring it up again on Zope-dev. I just proposed to make an exception for CMF. I'm on Subversion 1.6 anyways, so +1 for using the new format for the CMF buildout. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: CMF.buildout/trunk/src/ Don't use http:// externals for CMF externals.
On Thu, Apr 1, 2010 at 5:39 PM, Tres Seaver tsea...@palladion.com wrote: I'm +0 on making this change: I don't konw who will be using this buildout via an anonymous HTTP URL, but if everybody working on CMF is alraedy using SVN = 1.5, I can't see any harm in the relative externals. I've gone ahead and made the change. One obvious user that doesn't handle svn+ssh urls is the nightly buildbot. So using relative externals seems to be the best option. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Test setup problems with Zope 2.13
Hi Charlie, On Sun, Jul 11, 2010 at 7:31 PM, Charlie Clark charlie.cl...@clark-consulting.eu wrote: 2010-07-11 19:23:38 ERROR Application Couldn't install BTreeFolder2 Traceback (most recent call last): ... stat_info = os.stat(path) OSError: [Errno 2] No such file or directory: '/Users/charlieclark/Sites/cmf-svn/CMF.buildout/trunk/src/Zope2/src/Products/BTreeFolder2/btreefolder2.gif' I see from the updates that Products/BTreeFolder2 has been deleted / factored out. The question is - where's it gone to? Or what bits of my buildout do I need to reinstall? When you work against an SVN checkout, please make sure to always run both SVN update and bin/buildout. Also check svn status for orphaned directories (those with a question mark) and delete them. Products.BTreeFolder2 doesn't live inside the Zope2/src tree anymore but is a standalone distribution. In Zope 2.13 this distribution is still a dependency of Zope2 and installed when running bin/buildout. Only in Zope 2.14 will it be a complete optional dependency. If you follow my above instructions, you should get a working buildout again. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [Zope-dev] SVN: five.pt/trunk/src/five/pt/ The container should be the Acquisition.aq_parent.
On Sun, Oct 24, 2010 at 2:29 PM, Tres Seaver tsea...@palladion.com wrote: 'container' is supposed to be the folder which holds the script / template, not the context. In a CMF site, that will typically be the site root, given the way items in skin layers appear to be direct attributes of the portal object. For purposes of Five views, the view object seemss like the right object to be the 'container' for the template: if that is the case here (hard to see from just the diff), great. Note this comment from Products.Five.browser.pagetemplatefile in the pt_getContext method (made during the AQ vs. parent pointer work): namespace.update( here=obj, # philiKON thinks container should be the view, # but BBB is more important than aesthetics. container=obj, ... So in view page templates container and context have historically always been the same. So far we said BBB trumps anything else here. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFCore/trunk/Products/CMFCore/ Removed os.path.walk call in windows development mode
On Mon, Feb 7, 2011 at 2:59 PM, yuppie y.2...@wcm-solutions.de wrote: If someone knows a better way to detect NTFS, please let me know. I looked for better ways, but there's nothing good in default Python or pywin32. The only real approach seems to involve calling the external diskpart command with a script like list volumes and parsing the output... nothing I'd want to do. And if I remember correctly diskpart isn't available on old Windows versions either. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup global registries
On Wed, Mar 9, 2011 at 3:00 PM, Wichert Akkerman wich...@wiggy.net wrote: You really want to use the ZCA for every occurance of a string-object mapping? Really? As long as Zope doesn't have a central configuration registry like Pyramid has, it unfortunately makes sense. It's massive overkill and we shouldn't need to force simple values into interfaces, but that's the current state of things. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup: Question on StackOverflow
On Sat, Apr 9, 2011 at 9:09 AM, Suresh V. suresh...@yahoo.com wrote: http://stackoverflow.com/questions/5603459/genericsetup-what-does-toolset-xml-accomplish-if-toolinit-still-has-to-be-called As Jens pointed out, the CMF developers don't use stackoverflow as a support channel. But your question has been answered by the Plone folks anyways. As a side note: It's general considered bad practice to ask the same question on multiple channels. This applies to posting the same question to multiple mailing lists (cross posting) or to a bug tracker and a general mailing list or as in this case to a mailing list and a web forum. At least wait a couple days to see if you get a response on one channel, before posting it on a different one. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup: Question on StackOverflow
On Sat, Apr 9, 2011 at 11:31 AM, Jens Vagelpohl j...@dataflake.org wrote: IMHO it's not a metter of how popular a given tool is. It's a matter of where the developers/supporters hang out and what channels they use for accepting questions, bug reports or support requests. For the CMF that means this list or the Launchpad sites for the various components. If there's someone who wants to volunteer monitoring and answering requests on a separate channel, like that website, that's fine. But until that time people should be warned that posting requests somewhere else may not yield any results. Indeed. It just so happens that stackoverflow is the official support channel for Plone users as linked by http://plone.org/support For our casual users and integrators mailing lists aren't a good fit and using Nabble to mask mailing lists as web forums was only a minor improvement. We continue to use mailing lists for core and add-on developers. And of course it's up to the CMF developers to choose their official support channels. Just don't be alarmed if you see references to stackoverflow from time to time - it's probably from people coming through Plone. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup backport
On Tue, Apr 26, 2011 at 11:53 AM, Godefroid Chapelle got...@bubblenet.be wrote: I had made changes to GS registries (use ZCA instead of own registries) which got released in 1.6.3. I backported those changes to 1.4. http://zope3.pov.lt/trac/browser/Products.GenericSetup/branches/1.4-with-global-zca Can I merge to 1.4 branch ? Please don't. The changes broke quite a number of tests and some of my own code. It's bad enough this got into the 1.6 bug fix releases, even though it's a feature change. Most tests failed as the ZCA now has to be setup before calling certain API's like profile_registry.registerProfile. It's been a very common pattern in Plone add-ons to call this on the module level of a test to register a test-only profile. We have adjusted most of the test layers for the recent Plone release, so the change can stay in the 1.6.x series from my point of view. But if would be a lot of pain to do this for Plone 3.x releases using GenericSetup 1.4. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://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 - OK: 3, UNKNOWN: 1
On Tue, Jul 5, 2011 at 12:44 PM, Charlie Clark charlie.cl...@clark-consulting.eu wrote: Am 05.07.2011, 07:00 Uhr, schrieb CMF tests summarizer nore...@zope.org: [1] UNKNOWN FAILED (failures=1, errors=4) : CMF-trunk Zope-trunk Python-2.6.6 : Linux https://mail.zope.org/pipermail/cmf-tests/2011-July/014957.html All errors are related to FSMetaData Error in test test_basicPermissions (Products.CMFCore.tests.test_FSMetadata.FSMetadata) Traceback (most recent call last): File /usr/local/python2.6/lib/python2.6/unittest.py, line 279, in run testMethod() File /home/stefan/autotest/temp/python26-zope214-cmf23/src/Products.CMFCore/Products/CMFCore/tests/test_FSMetadata.py, line 43, in test_basicPermissions ['Manager','Anonymous']) File /home/stefan/autotest/temp/python26-zope214-cmf23/src/Products.CMFCore/Products/CMFCore/tests/test_FSSecurity.py, line 51, in _checkSettings % permissionname) ValueError: 'Access contents information' not found in inherited permissions. Yes, these are my fault. I kept testing the CMF against Zope trunk for the most part of the weekend, but didn't run the tests anymore for the last round of changes. Not sure what exactly caused these, but I'll have a look. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://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 - OK: 3, UNKNOWN: 1
On Sun, Aug 7, 2011 at 8:25 PM, Charlie Clark charlie.cl...@clark-consulting.eu wrote: Hanno, have you got any stats on the optimisation? I looked briefly at the changes and I'm not sure if this is really worth it. Nikolay is working on this and some more evil looking patches at https://github.com/fafhrd91/experimental.performance These fixes combined currently result in almost a 50% speedup in rendering time and cut down the number of function calls significantly. Just one example he shared with me for rendering the edit screen of a page in Plone (req/s, function calls): Stock Plone 4.2: ~5.5, 17, /Plone/front-page/edit (manager) With Chameleon: ~7.8, 101000, /Plone/front-page/edit (manager) With evil looking optimizations: ~12.3, 43000, /Plone/front-page/edit (manager) So yes, while these changes look at bit evil, they do have a major impact. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://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 - OK: 3, UNKNOWN: 1
On Sun, Aug 7, 2011 at 5:13 PM, Jens Vagelpohl j...@dataflake.org wrote: After the wrapping, the discussion item has the wrong path. Even though self, the talkback object, has the correct path when calling getPhysicalPath on it. I can't see anything overly stupid in the DiscussionItem code, so there has to be an issue with that Zope getPhysicalPath change. Reverting that one change in the current Zope trunk fixes the tests. Thanks for the thorough analysis! I tracked this down to a missing aq_inner call in the new getPhysicalPath and fixed that. The ValueError: 'Access contents information' not found in inherited permissions failures remain, which are next on my list. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://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 - OK: 3, UNKNOWN: 1
On Thu, Aug 11, 2011 at 9:31 PM, Jens Vagelpohl j...@dataflake.org wrote: On Aug 11, 2011, at 21:10 , Hanno Schlichting wrote: I tracked this down to a missing aq_inner call in the new getPhysicalPath and fixed that. Thanks for taking the time, Hanno. I wouldn't have been able to figure than one out. Any code that does manual __of__ wrapping is suspicious and suggests there's Acquisition problems lurking somewhere - I just got lucky to finding this one so fast ;) The ValueError: 'Access contents information' not found in inherited permissions failures remain, which are next on my list. That's fixed as well. The FS objects no longer have the Access contents information permission. They only got that through the OFS.ZDOM base class, which is gone in Zope 4. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CatalogTool as utility
On Tue, Sep 20, 2011 at 12:19 PM, yuppie y.2...@wcm-solutions.de wrote: But an additional ZCatalog branch is an additional maintenance burden. And the required change is small and 100% backwards compatible. The zope.globalrequest dependency could be made optional. Do we really need an extra ZCatalog branch for that? If there's a completely backwards compatible way of doing, we should do that. I was under the impression, that we had to do an API change for some methods and add a new request argument to those. If that argument is required depending on how the tool was retrieved, that's confusing to me and I'd rather go the zope.globalrequest route. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CatalogTool as utility
On Thu, Sep 22, 2011 at 3:14 PM, yuppie y.2...@wcm-solutions.de wrote: My checkin for Products.ZCatalog has an optional dependency on five.globalrequest. If five.globalrequest is not installed, Products.ZCatalog behaves exactly as before. I hope we don't need a Products.ZCatalog 2.14 release for that. Zope 2.13 can use it without five.globalrequest. See http://svn.zope.org/?rev=122892view=rev Is that ok? Should I add an explicit extra in the setup.py of Products.ZCatalog? That's ok. One minor nitpick: Instead of writing: request = getattr(self, 'REQUEST', None) I'd write: request = aq_get(self, 'REQUEST', None) with a module import of: from Acquisition import aq_get That way objects which have only an explicit AQ chain or only __parent__ pointers will also work. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] Move to github?
Hi. Stephan Richter has volunteered to do SVN to Github conversions for all Zope projects and has already completed all of Zope 2 core and some actively used projects like five.localsitemanager. Does anyone have objections if I ask him to convert the CMF packages? And if Tres reads this: Objections to moving PAS / PluginRegistry? Cheers, Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://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 -
Tres Seaver tseaver@... writes: On 03/04/2013 06:46 AM, Maurits van Rees wrote: If that commit helps, then some test errors will show up in Products.CMFDefault, mostly this: TypeError: Object has default comparison New BTrees expects objects used as keys to have real comparison semantics: Python's default (based on id()) is not suitable for persistent objects. The most common source of this warning is trying to store `None`: from BTrees.OOBTree import OOBTree tree = OOBTree() tree[1] = 1 tree[None] = 2 Traceback (most recent call last): File console, line 1, in module TypeError: Object has default comparison Unfortunately the ZCatalog has advertised support for storing None for some time, so there's likely some code out there which uses this. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://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 -
Maurits van Rees m.van.rees@... writes: I have added a missing pin for z3c.recipe.scripts (1.0.1), which should help there. I'm surprised you found that pin missing. I thought I had removed all use of that recipe from the CMF trunk builout, as it isn't compatible with buildout 2 yet. But maybe it's too ambitious to aim for buildout 2 / Zope 4 compatibility for CMF trunk. I only tried to fix the sources and buildout so it would at least run, after Zope was moved to github. But of course there's code and test changes to be made to reach compatibility with all the new zope.* 4.x versions. I'm not really up to work on all of those. So if nobody else is interested in that work, maybe it would be safer to aim for Zope 2.13 compatibility only at this point. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://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 -
Patrick Gerken patrick.gerken@... writes: are the missing CMF Tests only temporary or is there a need for a new source of test reports? I spoke to Stefan Holek and he no longer has the time nor interest to maintain the Zope2 and CMF nightly tests. He's not working on any web based projects anymore, so this is quite understandable. As CMF isn't moving to github, it seems the free travis-ci integration won't help here either. So if someone is interested in running the tests, that would probably be appreciated. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Move to github?
yuppie y.2013@... writes: Hanno Schlichting wrote: Does anyone have objections if I ask him to convert the CMF packages? Yes. I have objections. I'd like to keep contributing to CMF. But I'm not going to support GitHub Inc. by using its services. Ok. I thought this might be controversial for CMF. I'm not going to push or argue about this for CMF, as I think Yvo is the closest to a benevolent dictator we have for CMF these days and the project certainly cannot afford to loose him. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] DynamicType.portal_type
yuppie y.2015@... writes: yuppie wrote: There is no test that shows what was broken and fixed. AFAICS there is nothing wrong with using None for uninitialized objects. We just have a new requirement in Products.ZCatalog 3: Attributes with None values can no longer be indexed. Wouldn't it be better to adjust the portal_type just for indexing in the IndexableObjectWrapper? Fixed the issue this way: - reverted r130422 - adjusted the IndexableObjectWrapper I guess other indexed attributes can also contain None. Not sure if converting them to an empty string is always the best solution. Thanks for cleaning up after me. I took the easy way out when trying to make CMF trunk and Zope trunk work together. Adjusting the indexing behavior is the better approach. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
