Re: [Zope-CMF] CMFActionIcons moved to github
Am .09.2015, 16:57 Uhr, schrieb Maurits van Rees : Yes, Plone has switched over a long time ago. Plone 4.0 and higher, including Plone 5, have CMF 2.2. (Not 2.3, for compatibility reasons that I don't know.) I can't remember the details myself. I don't think the API has changed much. But CMFActionIcons 2.1.3 is still shipped in Plone 4 for backwards compatibility reasons, so you don't get broken objects in the ZMI. ? Can't Plone 4 be fixed instead? I noticed some links to svn.zope.org in the sources.cfg in the Plone coredev buildout for 4.3, and I wanted to get rid of it. This is part of that. That does not sound like a good enough reason to me or does it relate to the recent certificate problems? In any case the repo should be made read-only if possible. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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: Apply profile dependencies only once
Your mail with the screen shot was delayed, so I didn't see it before I wrote my reply. X-Mailman-Approved-At: Fri, 11 Sep 2015 15:20:01 +0200 Did someone have to approve that manually? Yes, I think that there's a limit to 100 KB per e-mail, though I'm surprised that the screenshot is as big as it is. Anyway: Looks like a tab that tries to make everybody happy. It's too complex, but that's not your fault. This is definitely the case. I think anyone not familiar with the implementation would not be able to tell the difference between the new options. But, for me, this is not about how it works in the ZMI. I am sure with some back and forth like this we can work something out. It is mostly about: what happens when in code you do runAllImportStepsFromProfile with the default settings. BTW 2, Plone 5 is still also using CMFQuickInstaller, but that is going the way of the dodo. Slowly. I didn't have a look at the Plone 5 control panel, but as you describe it, something similar would be quite useful in the portal_setup UI. But the Import tab has already too many options for rare use cases. It might be better to add a new tab for importing add-ons. This sounds like a good idea. The ZMI has traditionally suffered from just having more and more knobs to twiddle with little thought of the actual UI. I don't think that should block this PR (if it's required to solve a common problem at short notice). Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] CMFActionIcons moved to github
Am .09.2015, 13:02 Uhr, schrieb Johannes Raggam : I wonder why Plone still depends on it, if the code was moved to other CMF packages...? I think Plone still hasn't switched to the version of CMF which has the integration. I don't know the details but I think there are things that are done directly in Plone. It's a pity because CMF 2.1 and 2.2 contain a lot of improvements including a browser-view only skin. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] CMFActionIcons moved to github
Am .09.2015, 00:19 Uhr, schrieb Maurits van Rees : Not in active development anymore, as the code was moved into other parts of CMF years ago, but it made sense to me to move this one over too. Not to me, it doesn't. There should be no more work on this particular library. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Still Failing - CMF-trunk_Zope-trunk - Build # 820
Am .08.2015, 04:08 Uhr, schrieb Jenkins : Check console output at https://jenkins.starzel.de/job/CMF-trunk_Zope-trunk/820/ to view the results. Getting distribution for 'tempstorage==2.12.2' … error: [Errno 104] Connection reset by peer Server temporarily unavailable. I've had similar failures recently running my own buildouts. Are the servers seeing too much traffic? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Still Failing - CMF-trunk_Zope-trunk - Build # 754
Am .05.2015, 04:10 Uhr, schrieb Jenkins : Check console output at https://jenkins.starzel.de/job/CMF-trunk_Zope-trunk/754/ to view the results. One thing I don't like about Jenkins is the verbosity of the report and no summary of what failed. This is probably because I'm too stupid. The errors look fairly trivial but I have to work out how to checkout the sources from the new repo. Charlie Error in test test_DirectoryViewFolderCustom (Products.CMFCore.tests.test_DirectoryView.DirectoryViewFolderTests) Traceback (most recent call last): File "/usr/local/lib/python2.7/unittest/case.py", line 332, in run testMethod() File "/var/lib/jenkins/jobs/CMF-trunk_Zope-trunk/workspace/develop/Products.CMFCore/Products/CMFCore/tests/test_DirectoryView.py", line 225, in test_DirectoryViewFolderCustom testfolder = self.ob.fake_skin.test_directory AttributeError: test_directory Error in test test_DirectoryViewFolderDefault (Products.CMFCore.tests.test_DirectoryView.DirectoryViewFolderTests) Traceback (most recent call last): File "/usr/local/lib/python2.7/unittest/case.py", line 332, in run testMethod() File "/var/lib/jenkins/jobs/CMF-trunk_Zope-trunk/workspace/develop/Products.CMFCore/Products/CMFCore/tests/test_DirectoryView.py", line 203, in test_DirectoryViewFolderDefault testfolder = self.ob.fake_skin.test_directory AttributeError: test_directory Error in test test_DirectoryViewMetadata (Products.CMFCore.tests.test_DirectoryView.DirectoryViewFolderTests) Traceback (most recent call last): File "/usr/local/lib/python2.7/unittest/case.py", line 332, in run testMethod() File "/var/lib/jenkins/jobs/CMF-trunk_Zope-trunk/workspace/develop/Products.CMFCore/Products/CMFCore/tests/test_DirectoryView.py", line 189, in test_DirectoryViewMetadata testfolder = self.ob.fake_skin.test_directory AttributeError: test_directory Error in test test_DirectoryViewMetadataOnPropertyManager (Products.CMFCore.tests.test_DirectoryView.DirectoryViewFolderTests) Traceback (most recent call last): File "/usr/local/lib/python2.7/unittest/case.py", line 332, in run testMethod() File "/var/lib/jenkins/jobs/CMF-trunk_Zope-trunk/workspace/develop/Products.CMFCore/Products/CMFCore/tests/test_DirectoryView.py", line 195, in test_DirectoryViewMetadataOnPropertyManager testfolder = self.ob.fake_skin.test_directory AttributeError: test_directory Failure in test test_DeleteFolder (Products.CMFCore.tests.test_DirectoryView.DebugModeTests) Traceback (most recent call last): File "/usr/local/lib/python2.7/unittest/case.py", line 332, in run testMethod() File "/var/lib/jenkins/jobs/CMF-trunk_Zope-trunk/workspace/develop/Products.CMFCore/Products/CMFCore/tests/test_DirectoryView.py", line 298, in test_DeleteFolder self.assertTrue(hasattr(self.ob.fake_skin, 'test_directory')) File "/usr/local/lib/python2.7/unittest/case.py", line 425, in assertTrue raise self.failureException(msg) AssertionError: False is not true Failure in test test_registerDirectory (Products.CMFCore.tests.test_zcml) Failed doctest test for Products.CMFCore.tests.test_zcml.test_registerDirectory File "/var/lib/jenkins/jobs/CMF-trunk_Zope-trunk/workspace/develop/Products.CMFCore/Products/CMFCore/tests/test_zcml.py", line 20, in test_registerDirectory -- File "/var/lib/jenkins/jobs/CMF-trunk_Zope-trunk/workspace/develop/Products.CMFCore/Products/CMFCore/tests/test_zcml.py", line 45, in Products.CMFCore.tests.test_zcml.test_registerDirectory Failed example: reg_keys[1] in _dirreg._directories Expected: True Got: False -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] A Tale of Two Repositories
Am .05.2015, 12:11 Uhr, schrieb yuppie : thanks for working on this issue. I'm not very happy about the proposed solution because it makes the GitHub repository the primary repository and the canonical location for bug reports. But compromises never make everybody happy. For the record, like yuppie I'm not happy with Github as the canonical repository either. Is this because it's easier to use travis-ci? Or simply because it's more convenient to have everything in one place? I'm happy about your proposal because it looks like a practicable solution everybody can live with. I can live with it because I haven't made a commit in at least two years. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Successful - CMF-trunk_Zope-trunk - Build # 611
Hiya Patrick, Am .01.2015, 11:48 Uhr, schrieb Patrick Gerken : I hope you don't mind my jenkins to post here directly. I never managed to enter cmf-tests list and since I am the only tester, I figured I can send here directly. No problem and thanks for adding it. Any chance you can add coverage information? Or isn't that possible with the Zope testing toolchain? Can you do anything about the certificate error on your site? I can, if you want, limit the mails to events of failures. The build runs daily, as you can see by the number, for quite a while already. It was always stable. I guess that means everybody here is a perfect developer who never makes mistakes. haha! Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] member area / home folder changes
Am 05.08.2013, 15:38 Uhr, schrieb yuppie : Last time I checked the syndication views had some issues. Two things I remember: - The folder syndication form seems to allow enabling folder syndication if portal syndication is disabled. This is confusing. - syndication.pt exists but is not used. Okay, I've still got the e-mails. I just remember seeing that you'd already fixed some of the stuff and wasn't sure what was still outstanding. I will have time this month maybe at the upcoming sprint in Halle. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] member area / home folder changes
Am 05.08.2013, 12:26 Uhr, schrieb yuppie : No objections. I'd just like to do some small polishing before we create 2.3 branches. Okay. Is there any of my stuff outstanding that you haven't already fixed for me? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] member area / home folder changes
Hi Yuppie, (checks that he is writing to the list) Am 01.08.2013, 11:46 Uhr, schrieb yuppie : Hi! Just want to explain the changes I made on CMF trunk. First a few words about names: CMF uses sometimes 'member area' and sometimes 'home folder'. IMembershipTool has 'getHomeFolder' and 'getHomeUrl' methods as well as 'createMemberArea' and 'deleteMemberArea' methods. If there is a difference between the two names, 'home folder' is just the folder and 'member area' the folder including all subobjects. In my proposal I proposed to add portal types named 'Members' and 'MemberArea', but I now changed this to 'Members Folder' and 'Home Folder'. Hope that's ok. I think this is clearer: users are interested in their own or others (home) folder. The Members Folder is really only of interest to admins. Do the new types have any special functions or attributes? Or are they purely semantic? You mention a proposal - did that go to the list and I missed it? Or did you put something up on launchpad? 'createMemberArea' now uses separate factories for creating member areas. This allows to use the same method in CMFCore and CMFDefault. The MembershipTool in CMFDefault no longer has a customized version of 'createMemberArea'. I'm not sure what the separate factories are for "member areas and…"? But it certainly makes sense to remove a customisation in CMFDefault. For backwards compatibility I added two factories that are used if no 'Home Folder' portal type exists. 'cmf.folder.home.bbb1' is compatible with the old CMFCore code, 'cmf.folder.home.bbb2' with the old CMFDefault code. In that case the portal type of new home folders is 'Folder' as before. The recommended factory is 'cmf.folder.home'. It no longer supports the 'createMemberContent' hook. It is now recommended to use a customized factory instead. The two new portal types 'Members Folder' and 'Home Folder' allow to customize factories and behavior. For existing sites you can either switch to the new behavior by using the two upgrade steps or just keep the old behavior. The only thing I have here is that changes should probably come in a new release. I think we've (well, you've) done most of the work for moving from TTW and we can look to faster releases than in the past because of the improved test coverage. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] some small changes
Am 09.07.2013, 09:33 Uhr, schrieb yuppie : Hi Yuppie, Hi Charlie! Thanks for your feedback. You didn't reply to the list, so I just reply to you. Feel free to bring this back to the list. It was just me being stupid and confused by another list that defaults to reply to user - I'm on several which are configured differently and it's all too much for my little brain! Charlie Clark wrote: Am 05.07.2013, 10:48 Uhr, schrieb yuppie : - rename '@@view.html' to '@@view', '@@properties.html' to '@@properties' and so on. This allows to remove some method aliases. -1 Call me a stick in the mud but I always like to associate a mime type with a file extension. I know what you mean, using '@@view.html' and '@@properties.html' in CMF was my idea. But meanwhile I think differently: Paths like "site/foo.pdf/edit.html" look strange. File extension are useful if you want to save files to a file system that has no other way to keep track of the mime type. But you don't want to save views that have a visible name. You want to save the object using the default view and the name of the default view is invisible. So the object needs a file extension, not the view. I don't think I'm entirely convinced about path logic. I guess any of these conventions are dependent upon what you're doing. Fortunately, traversal means that we generally don't need to worry too much about the name we use and extensions in view names are useful only in a minority of cases, such as, say, .ics for events. I just like the explicitness. OTOH I also realise that this is somewhat historical - extensions are good way of distinguishing between views and TTW stuff when entering URLs directly, like developers but not users do. And: These names are already hidden behind aliases, for type specific views they are just used internally. This is probably the biggest reason so no more objections from me. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] CMFDefault: renaming type action urls
Am 21.05.2013, 12:34 Uhr, schrieb yuppie : Yes. Default view and 'view' are identical for other content types, but File and Image have a download view and a preview. Okay. Otherwise it's a very sensible clean up of a wart of the old style Meanwhile this is checked in. But if there are no objections I'd like to make a small modification: We have 'view' (not 'viewing') and 'edit' (not 'editing'), so I think we should use 'share' instead of 'sharing' for local roles. Fine with me. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] CMFDefault: renaming type action urls
Hi,
Am 13.05.2013, 10:06 Uhr, schrieb yuppie :
Types: File, Image
Action: object/view
old: url_expr="string:${object_url}/file_view"
old: url_expr="string:${object_url}/image_view"
new: url_expr="string:${object_url}/view"
I think this is possibly the only one I would question: why the explicit
view as opposed to "/"? Is this difference between viewing the file or
image with metadata and when it is used as a resource elsewhere? Otherwise
it's a very sensible clean up of a wart of the old style
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
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 -
I'll take care of it. Thanks very much Patrick. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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?
Am 04.03.2013, 17:46 Uhr, schrieb Lennart Regebro : On the contrary, it's state supported monopolies that are bad… Monopolies of any sort are usually bad and, unfortunately, rarely corrected by market forces. So much for "efficient market theory". Which is why, since Standard Oil, we have anti-trust legislation. There are exceptions but these are usually of a philosophical such as the European tradition of having a monopoly on the use of force, the US position (2nd amendment? is noticeably nuanced). Philosophically speaking I would side with Yuppie in saying the "GitHub is up to no good" and I do not maintain any repositories on it myself (that, and the fact that I can't get my head round git). However, with reference to our common projects I think it is a general discussion and I would feel slightly hypocritical pushing for a clean solution here while contributing to other parts of Zope (chance would be a fine thing) that are on GitHub. Still hoping for a third option. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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?
Am 02.03.2013, 22:44 Uhr, schrieb Tres Seaver : The vote by foundation members to move to Github (rather than self-hosted Git) was far from unanimous. In fact, we are supposed to have worked out a means where folks could push to git.zope.org as the canonical repository for some projects. I would prefer this if possible. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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?
Am 02.03.2013, 21:42 Uhr, schrieb Martin Aspeli : Seriously? I can understand reservations about the move and did indeed voice my own at the time. You do realise it's: a) free (for us) "There's no such thing as a free lunch."™ b) decentralised If the shit really does hit the fan then I'm not sure that would help us that much. I appreciate you may have to do the occasional 'push' to a .com domain, but you've got to be kidding... I don't think the TLD is the problem. GitHub is a VC funded company and not a philanthropic institution. Yuppie has been by far the most prolific contributor to the CMF over the last few years. I'm not sure if it will have much of a future without his continued commitment. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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?
Am 02.03.2013, 13:01 Uhr, schrieb Hanno Schlichting : 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? Well, while I'm sure I'm going to struggle even more with git than I do already with svn, I suppose we'd better get it over with. I have one uncommitted change that I'll commit later today. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Weird UnicodeDecodeError with zope.formlib
Am 30.11.2012, 18:21 Uhr, schrieb Charlie Clark
:
Let me explain: in pdb I have access to request.form which is where I
can see the difference. With Sentry I can only see the raw body of the
request. I may simply have not understood well enough how to use it to
inspect what's happening.
I raise an exception in both cases in the forms' validate method.
Do you see this until you extract it first from the request object?
You are not having one form saying fieldname:string and the other just
fieldname?
No, they are all zope.formlib/zope.schema fields so there is no
additional marshalling.
I have finally tracked down the problem: I seem to have been bitten by a
change in zope.formlib 4.1.
There are two solutions: either extend a form's update method with the
something like the following:
def update(self):
from Products.Five.browser.decode import processInputs
from ZPublisher import HTTPRequest
# XXX: if we don't set default_encoding explicitly, main_template
might
# set a different charset
self.request.RESPONSE.setHeader('Content-Type',
'text/html; charset=%s' % HTTPRequest.default_encoding)
# BBB: for Zope < 2.14
if not getattr(self.request, 'postProcessInputs', False):
processInputs(self.request, [HTTPRequest.default_encoding])
super(_EditFormMixin, self).update()
Or, more simply, base forms on those provided by five.formlib.formbase
Thanks to yuppie for fixing this in the CMF.
I can confirm that this also works with Internet Explorer.
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
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] Weird UnicodeDecodeError with zope.formlib
Am 30.11.2012, 18:14 Uhr, schrieb Patrick Gerken : Hi Patrick, thanks for your patience in attempting to help me on this! I don't understand why you see no difference in the stacktrace, but a difference with pdb in the end. Doesn't one instance show that the input is a string and the other that its unicode? Let me explain: in pdb I have access to request.form which is where I can see the difference. With Sentry I can only see the raw body of the request. I may simply have not understood well enough how to use it to inspect what's happening. I raise an exception in both cases in the forms' validate method. Do you see this until you extract it first from the request object? You are not having one form saying fieldname:string and the other just fieldname? No, they are all zope.formlib/zope.schema fields so there is no additional marshalling. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Weird UnicodeDecodeError with zope.formlib
Hi Patrick,
Am 30.11.2012, 09:50 Uhr, schrieb Patrick Gerken :
Add sentry logging with raven to the sites. Trigger an exception in both
sites. With sentry you can not only see the traceback, but check the
local
variable of each frame. You can do the same with pdb of course but not so
easily side by side to see where the local vars start to differ.
I can give you access to my sentry server to send the logs to.
thanks for the tip. I've got Sentry and Raven running and reporting but
I'm afraid I still can't see the difference. The posted form looks
indentical in both cases. I can only assume that, as you first suggested,
there is a difference lower down the stack which is causing one instance
to decode the URL-encoded form to unicode and the other to encode it as
UTF-8. How can I check this? locale.getdefaultlocale() reports ('de_DE',
'UTF8') for both.
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
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] Weird UnicodeDecodeError with zope.formlib
Am 29.11.2012, 09:43 Uhr, schrieb Charlie Clark : No. I guess I'll have to look more closely at the wigdets data. As I said a different site on the same machine doesn't exhibit these problems so I should have a point of comparison. Definitely weird. From site 1: (Pdb) t = self.widgets['town'] (Pdb) t._getFormInput() u'D\xfcsseldorf' as expected but from site 2: (Pdb) t = self.widgets['town'] (Pdb) t._getFormInput() 'D\xc3\xbcsseldorf' Note the similarity of the field name as one of these forms started out as a copy of the other. Need to check what is causing this. I think I might have set a default encoding for Zope to UTF8 ostensibly to reduce IE / Safari errors. Oh, isn't this fun! Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Weird UnicodeDecodeError with zope.formlib
Hiya Patrick, Am 29.11.2012, 00:12 Uhr, schrieb Patrick Gerken : With the information you provided I'd first try this on a python prompt on a working machine : "Köln" == u"Bonn" "Köln" == u"Bonn" bin/zopepy:1: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal If this does not throw the same error, somebody changed the python default encoding. Then I'd look if some of my validators get constraints with umlauts. There are no fancy constraints just a bundle of TextLine fields. But I guess, you tried that already? No. I guess I'll have to look more closely at the wigdets data. As I said a different site on the same machine doesn't exhibit these problems so I should have a point of comparison. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Weird UnicodeDecodeError with zope.formlib
Hi, one of my sites has (hopefully) started behaving funny. I have a formlib driven contact form that is rejecting any input that is not ascii as part of the validation step of the form: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal I may have got this wrong but I thought inputs into forms could be considered as unicode and we only had to worry about them when storing them in case they were being accessed by non-unicode-aware code. What's really puzzling is that I have almost identical forms on other sites that don't exhibit this behaviour which makes me think it must be a configuration error such as the default encoding which is set to utf-8 for this site. Any ideas? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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 security patches in Products.PloneHotfix20121106
Am 09.11.2012, 20:29 Uhr, schrieb David Glick (Plone) : We should have informed you earlier. There are a lot of tasks associated with preparing a hotfix (and this one in particular covered many vulnerabilities), and it got missed. I apologize. In the future, what's the best place to report possible CMF security issues? zope-cmf Launchpad? Hi David, thanks for the quick response. I would definitely say just post to the list to see if we're still alive. Can you say which versions of CMF are affected? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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 security patches in Products.PloneHotfix20121106
Am 09.11.2012, 17:02 Uhr, schrieb Jens Vagelpohl : Hi all, I don't recall any information being provided to the CMF developers about CMF fixes in the most recent Plone Hotfix: http://plone.org/products/plone-hotfix/releases/20121106 For example, there's a monkey patch to make sure getToolByName only returns valid tool objects and nothing else, see the attached file. I'm not sure if there's an oversight of not forwarding this information to us or if it was determined this fix is not relevant for the CMF. Would any list member who also works on Plone have an insight? Thanks! jens I got this back from David Glick after asking secur...@plone.org: """ Thanks. We haven't had a chance to start applying the patches in the hotfix back to where they really belong, but we'll do so soon. Note that for the time being it should be possible to apply the Plone hotfix to pure CMF sites as well to patch this issue. """ Still no wiser as to why we weren't informed. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Security declarations on adapters
Hi Yuppie, Am 07.09.2012, 09:01 Uhr, schrieb yuppie : [-] means that we don't want/need to convert this [?] means that we still have to decide if and how this should be converted [/] means unfinished Regarding RSS: you've written [/] ISyndicatable @@rss.xml (not hooked up): - [x] RSS.py -> rss.View - [x] RSS_template.pt -> rss.pt - [?] rssDisabled.pt What do you mean by not hooked up? There's not an appropriate action but the template is configured. As syndicatability is determined by a marker interface I don't think we need to have a disabled view for it. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Security declarations on adapters
Am 07.09.2012, 09:01 Uhr, schrieb yuppie : I have additional data, but still have to verify it and merge it into the CMF trunk todos. Just updated the todo for 'content' and added one for 'skins'. [-] means that we don't want/need to convert this [?] means that we still have to decide if and how this should be converted [/] means unfinished Thanks for the clarification. Some of the issues mentioned in 'content' might now belong into 'discussion'. Please update the todos according to your changes. Will do. And I have a quick and dirty view implementation for local role/sharing. Reimplementing it based on formlib would be a lot of work, so maybe I should just check in my code. As I'm not even sure what it does I'd definitely suggest you check it in. I'd also be very interested in your "skinless" workaround. As luck would have it I was discussing CMF with someone and I think we should have it in the docs somewhere. I would also like to add a quick install guide for anyone wanting to use CMFDefault as a springboard. I thought we'd agreed not to make them the default for this release but remove the "experimental" label from the profile. Personally, I would like to see them as the default, not least because they nearly all have coverage. But, we shouldn't be packing too much into a single release. Maybe because you work with trunk you notice less? I didn't propose to pack all this in CMF 2.3. My list also contains the next steps after the release. Where is the list? Off the top of my head: correcting the docs. There are also duplicate DCWorkflow docs. Someone has to figure out if the old .stx docs are redundant and obsolete. There are equivalents for all .stx as .rst. I thought I had moved the files over but apparently not. I don't know what to do about the examples. But the .stx files can go. You moved the docs to the new place, so why didn't/don't you remove the obsolete files yourself? It was sort of rhetorical. I thought I'd done svn move, to preserve the history. But considering the refactoring I guess I didn't. I'll pull the .stx Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Security declarations on adapters
I always like the solipsism of replying to myself! ;-) Am 06.09.2012, 16:58 Uhr, schrieb Charlie Clark : hm, I drew up the lists from the existing Scripts/Templates and thought it was complete. I've just checked again and can only find the following as not done: - [?] viewThreadsAtBottom.pt (structure) - [?] talkback_tree.pt (macros) - [?] setup_talkback_tree.py - [?] discitem_delete.py Just checked on these and it looks like there are no views for discussions. So I've added a stub for them and, at least temporarily, moved these putative todos to "discussion". A bit difficult to write tests for them as I'm currently getting the following error when using the "classic" versions: Error Type: AttributeError Error Value: SectionValue instance has no attribute 'structured_text_header_level' We can, and should, revisit naming again. IIRC you weren't happy with my choices of "skins" and "widgets". Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Security declarations on adapters
Am 06.09.2012, 16:24 Uhr, schrieb yuppie : These changes provide better backward compatibility for code using CMF tools/utilities and better forward compatibility for running CMF on Zope 4. (*If* the proposed changes become part of Zope 4.) As you say, if. We don't have to wait for the Zope 4 release, just for the decision about the changes and for a five.localsitemanager release. Some small changes I made for CMF 2.3 don't play nice with the changes Laurence is working on. Point taken. All the other unfinished tasks can be deferred to CMF 2.4. Do we have a list of these unfinished tasks? There are the (incomplete) todo lists for browser views. I'd also like to revisit the names we did choose for the views and make them the default target of Actions. hm, I drew up the lists from the existing Scripts/Templates and thought it was complete. I've just checked again and can only find the following as not done: - [?] viewThreadsAtBottom.pt (structure) - [?] talkback_tree.pt (macros) - [?] setup_talkback_tree.py - [?] discitem_delete.py I thought we'd agreed not to make them the default for this release but remove the "experimental" label from the profile. Personally, I would like to see them as the default, not least because they nearly all have coverage. But, we shouldn't be packing too much into a single release. Maybe because you work with trunk you notice less? As soon as we have a complete replacement for the oldstyle skins I'd like to move those skins into a separate legacy package. +1 (I recently removed the complete skins tool from some of my CMF instances. That depends on a few hacks, but works quite well.) Sounds great but should be in a separate release. We also should consider moving the skins tool and the directory view code into a separate package. This could be in 2.4 That code has some dependencies that were removed from Zope 2 (Zope 4) and are not required for sites without skins tool. In the long run I have no ambitions to maintain that code and its dependencies. I don't think anyone does. Off the top of my head: correcting the docs. There are also duplicate DCWorkflow docs. Someone has to figure out if the old .stx docs are redundant and obsolete. There are equivalents for all .stx as .rst. I thought I had moved the files over but apparently not. I don't know what to do about the examples. But the .stx files can go. I think all the docs need a review but would like them to be visible first. I'd also like to see at least minimal support for a WYSIWYG editor for HTML-text fields. Not sure if this should be part of CMF or a standalone formlib addition because of the external dependencies. Some day I want to switch to z3c.form which has more add ons. I wouldn't spend too much time on formlib specific features. Again that would be for a later release. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Security declarations on adapters
Am 06.09.2012, 15:29 Uhr, schrieb Laurence Rowe : We're hoping for a Zope4 alpha by the end of the year. I'm currently running CMF 2.2 / Plone 4.3 on my branch with only a couple of minor changes. Its really only the RequestContainer aq rewrapping which causes a problem. With my branch that becomes isolated in five.localsitemanager, which will require a new release for Zope4 anyway. I don't think we should wait for that. I don't think anything precludes a CMF 2.4 following on fairly quickly. Plone is unlikely to make a CMF upgrade until it removes its CMFDefault dependency. Please elaborate. The refactoring of CMFDefault broke the Plone tool subclasses. Its no bad thing really, inheriting from CMFDefault doesn't make a lot of sense for Plone, we just need to do the work of moving code around. In any case we need to wait for a Plone 5 before we can upgrade, if CMF 2.4 came in fairly quick succession we could probably just skip 2.3. Plone duplicates an awful lot of CMFDefault and often not in a good way; being joined at the hip makes no sense. As above I don't see any problems with a fairly quick release of 2.4 after 2.3. CMFDefault brings a lot of benefit to the anyone actually using it. Our release schedule so far has been neither feature nor time driven. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Security declarations on adapters
Hiya Laurence, Am 06.09.2012, 14:46 Uhr, schrieb Laurence Rowe : I think the downsides from leaving it out are: * Another branch of five.localsitemanager to maintain. * Incompatibility between CMF 2.3 and Zope 4 once the parent pointer changes go in. What's the timescale for that? I don't see a problem with 2.3 being tied to 2.13 and 2.4 being for > 2.13 which I assume Zope 4 is? 2.3 has a slew of changes throughout. Plone is unlikely to make a CMF upgrade until it removes its CMFDefault dependency. Please elaborate. Laurence The main downside to leaving the changes out is the necessity of another five.localsitemanager branch to maintain. The changes are compatible with CMF 2.2, but it may not play nicely with the Did you hit enter too early? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Security declarations on adapters
Am 06.09.2012, 13:11 Uhr, schrieb yuppie : Good. What is, in your view, missing from a final release? Laurence proposed some changes for the utilities: https://mail.zope.org/pipermail/zope-cmf/2012-September/030381.html If we agree that's the way to go, I'd like to have his changes in CMF 2.3 before the final release. Unless something downstream is dependent on these kind of changes I don't see any reason to including them at this late stage. All the other unfinished tasks can be deferred to CMF 2.4. Do we have a list of these unfinished tasks? Off the top of my head: correcting the docs. I'd also like to see at least minimal support for a WYSIWYG editor for HTML-text fields. Not sure if this should be part of CMF or a standalone formlib addition because of the external dependencies. The last beta was at the end of March so maybe it's time for another one to include all the formlib stuff you've worked on? I use CMF trunk in production, so I don't need a beta release. But it might be a good idea if other people want a beta for testing. I definitely think another beta would make sense: my own sites don't use trunk simply what PyPI spits out. How can we get the sphinxified docs into the release process? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Security declarations on adapters
Am 05.09.2012, 09:07 Uhr, schrieb yuppie : The setup of your doctest looks fine, you just have to enable syndication for the folder (app.site) to get the view. Tests landed yesterday and I also ran them with the oldstyle implementation. What is, in your view, missing from a final release? The last beta was at the end of March so maybe it's time for another one to include all the formlib stuff you've worked on? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] tools as utilities
Am 06.09.2012, 11:56 Uhr, schrieb Patrick Gerken : Wait, what? Whenever I look into structure, there is only basic information, not even the workflow states of the objects get exported. What am I doing wrong? I was thinking something similar: can you really use Generic Setup to migrate objects from one Zope system to another? I guess you can as long as you provide the right upgrade steps for your content types, ie. you write the missing management stuff, as transmogrify seems to do. Tres, please correct me if I'm wrong on that. In terms of CMF I think we could add something that would allow content objects to be ex- and importable. Though like Patrick I'm not too sure how this would handle adapted content. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] tools as utilities
Am 05.09.2012, 16:00 Uhr, schrieb Lennart Regebro : So you want to tell everyone that either has not received that message, or used Plone since before 2.5, "That yeah, I know you can do that, but we were just messing with you so now you are fucked". I think you are taking my words entirely out of context. Well, I don't think we should say that. I won't be telling Plone users anything. And anyone with an existing Plone 2.5 or earlier site has a more problems than CMF 2.3 compatibility, which the last I heard was not intended anyway. I've recently struggled with a Plone 3 to Plone 4 migration and would not wish the same on anyone else. There are lots of good reasons for having only one website per Data.fs / Zope instance. And if we don't want to support more than one site the ZODB, there should be a warning of you try to do it, btw. The CMF (has to) treats its users as adults. While Yuppie has described that he uses that setup he also pointed out the possible pitfalls of doing so. Given the recent discussion I do think it would be a good idea to make this policy with a note that other setups may work but will not be supported. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] tools as utilities
Am 05.09.2012, 15:05 Uhr, schrieb Lennart Regebro : I think it is. We have to have some way to move a Plone site from one ZODB to another. No, one site per Data.fs is what we should support. This has more or less been the explicit aim of Zope > 2.8 I find export by zexp generally works on a per non-container object basis okay but not beyond that. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] tools as utilities
Am 05.09.2012, 15:36 Uhr, schrieb yuppie : - CMF 2.3 targets Zope 2.13 as primary platform. So we can't rely on Zope 4 features. Agreed, but we should be looking to getting 2.3 out of the door anyway. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] tools as utilities
Am 05.09.2012, 11:48 Uhr, schrieb yuppie : I use a single Zope instance for several small CMF sites and I use .zexp export and import for moving CMF sites from one Zope instance to an other. Works fine for me. Even with Plone sites. Even if it works for you I'm not sure that this is a use case we should support. The nastiest part of the bootstrapping issue is the fact that without the fallbacks currently in place you can't navigate to the Setup Tool of a CMF 2.2 instance and run the upgrades. The ZMI folder listing calls code that depends on CMF tools. But fixing these issues is not on the top of my list. I just mentioned them for the sake of completeness. Which is fine and something we don't do often enough! 2.) Site root lookup: = In several tools we still assume aq_parent(aq_inner(self)) is the portal. Or other code uses the tool as context object, expecting root and request in its acquisition chain. These should be identified and replaced by getUtility(IURLTool).getPortalObject() or other suitable code. Maybe we could add a convenience API for that? getToolByName can be used instead as it does the lookups. getToolByName is no option because it is part of the machinery that should become obsolete. Not sure that is should actually ever become obsolete. Much as I am in favour of the interface-based lookup, these tools are an essential part of the CMF. getUtility(IURLTool).getPortalObject() might be overkill because it adds the request to the context. All the code that needs the request should be fixed already. Using queryUtility(ISiteRoot) should be sufficient. But AFAICS the only way to find all the places where this needs to be fixed is to set up a site with tools that are not stored in the site root. That's a big ask. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Security declarations on adapters
Yuppie recently pointed out that I'd completely forgotten about the RSS output of my changes to syndication which was broken. While I was fixing this I was struck by two things: * is there an easy way to write the test for something that requires a tool and some content? * backporting the changes to the PythonScript I hit a roadblock that I can't use security declarations on the adapter. Fortunately, I was able to use the tool as a workaround but, apart from ripping out the PythonScript, I can't think of a better solution. Any ideas? I'm also struggling with a convenient way of handling the difference in time formatting arising form using native datetime and DateTime with it's convenient rfc822 method Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] tools as utilities
Am 04.09.2012, 15:35 Uhr, schrieb Tres Seaver : I'd rather not add any cruft to support .zexp imports, which have seemed fundamentally broken to me for a long time. I'd agree on that. Occasionally, and on a strict, per object basis, they have their use but not at the same as updates. Or what do you have in mind? 2.) Site root lookup: = In several tools we still assume aq_parent(aq_inner(self)) is the portal. Or other code uses the tool as context object, expecting root and request in its acquisition chain. These should be identified and replaced by getUtility(IURLTool).getPortalObject() or other suitable code. Maybe we could add a convenience API for that? getToolByName can be used instead as it does the lookups. 3.) Action providers: = Action providers are still registered and looked up by ID. Most Actions were moved to the Actions Tool. Only two 2 special Action providers are left: Types Tool and Workflow Tool. I have no plans to convert that registry to something based on utility lookup. I guess it would be better to create specialized 'object' and 'workflow' categories that are linked to the Types Tool and the Workflow Tool. But that's a different story. 4.) Skins: == The Skins Tool lookup is based on the getSkinsFolderName method. If there are no objections, I'll replace that by queryUtility(ISkinsTool) without providing any backward compatibility code for getSkinsFolderName. +1. Thanks for the analysis. +1 Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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: 2, UNKNOWN: 2
Hi yuppie, Am 24.04.2012, 17:42 Uhr, schrieb yuppie : Today I saw these errors in one of my buildouts. I was able to fix them by improving the tear down in MembershipToolTests. Can you confirm this is fixed? Yes, seems to be working just fine now. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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: 2, UNKNOWN: 2
Am 11.04.2012, 17:06 Uhr, schrieb Charlie Clark : I can't reproduce the other failures. Thanks for looking. I'll do clean checkout and buildout and see if that makes any difference. I can reproduce the errors on CMF trunk with Zope trunk on Mac OS, Debian and FreeBSD. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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: 2, UNKNOWN: 2
Am 11.04.2012, 16:03 Uhr, schrieb yuppie : It wasn't a blank line. You removed whitespace in rev 125119: Modified: Products.CMFDefault/trunk/Products/CMFDefault/tests/test_utils.py === --- Products.CMFDefault/trunk/Products/CMFDefault/tests/test_utils.py 2012-04-09 16:16:46 UTC (rev 125118) +++ Products.CMFDefault/trunk/Products/CMFDefault/tests/test_utils.py 2012-04-09 16:30:40 UTC (rev 125119) @@ -27,7 +27,7 @@ MULTIPARAGRAPH_DESCRIPTION = \ '''Description: this description spans multiple lines. - + It includes a second paragraph''' Doh, it was my editor what done it! (Configured to remove my bête noire of trailing) whitespace). I added some whitespace back in. I can't make any sense from the RFC whether this should actually be supported but for our purposes we need to keep it. Do you any examples of where this behaviour is required? I can't reproduce the other failures. Thanks for looking. I'll do clean checkout and buildout and see if that makes any difference. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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: 2, UNKNOWN: 2
et up Products.CMFCore.testing.FunctionalZCMLLayer in 0.400 seconds.
Set up Products.CMFDefault.testing.FunctionalLayer Traceback (most
recent call last):
File
"/Users/charlieclark/Sites/CMF/eggs/zope.testrunner-4.0.4-py2.6.egg/zope/testrunner/runner.py",
line 380, in run_layer
setup_layer(options, layer, setup_layers)
File
"/Users/charlieclark/Sites/CMF/eggs/zope.testrunner-4.0.4-py2.6.egg/zope/testrunner/runner.py",
line 672, in setup_layer
layer.setUp()
File
"/Users/charlieclark/Sites/CMF/src/Products.CMFDefault/Products/CMFDefault/testing.py",
line 34, in setUp
zcml.load_config('configure.zcml', Products.CMFDefault)
File "/Users/charlieclark/Sites/CMF/src/Zope2/src/Zope2/App/zcml.py",
line 54, in load_config
_context = xmlconfig.file(config, package, _context, execute=execute)
File
"/Users/charlieclark/Sites/CMF/eggs/zope.configuration-3.8.0-py2.6.egg/zope/configuration/xmlconfig.py",
line 648, in file
context.execute_actions()
File
"/Users/charlieclark/Sites/CMF/eggs/zope.configuration-3.8.0-py2.6.egg/zope/configuration/config.py",
line 691, in execute_actions
callable(*args, **kw)
File
"/Users/charlieclark/Sites/CMF/eggs/zope.publisher-3.13.0-py2.6.egg/zope/publisher/zcml.py",
line 90, in setDefaultSkin
skin = component.getUtility(IBrowserSkinType, name)
File
"/Users/charlieclark/Sites/CMF/eggs/zope.component-3.12.1-py2.6.egg/zope/component/_api.py",
line 169, in getUtility
raise ComponentLookupError(interface, name)
ConfigurationExecutionError: 'zope.interface.interfaces.ComponentLookupError'>: (zope.publisher.interfaces.browser.IBrowserSkinType>, u'cmf')
in:
File
"/Users/charlieclark/Sites/CMF/src/Products.CMFDefault/Products/CMFDefault/skin/configure.zcml",
line 12.2-14.8
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
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] 2.3
Am 11.04.2012, 10:16 Uhr, schrieb yuppie : Just a general remark: The last time we added a warning to getToolByName it had to be taken back out. The protest was too big. No one wanted to spend the time on all the third-party packages that still use that API. What's worse, back then even the CMF packages were not switched to a pure utility model and would emit these warnings as well. I think I remember. No warning then. We've still got a few instances of methods (in ActionsTool) using it but I'm torn between replacing them with the utility lookup plus fallback or leaving them as they are for 2.3 and changing them without fallback later. The current code provides an elegant lookup with fallback. AFAICS the only thing we need to do for backwards compatibility is using registerToolInterface. So it isn't urgent to deprecate and remove getToolByName. Okay. It might be useful to write a howto for people who want to modernize their code. Definitely. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] 2.3
Am 22.03.2012, 13:28 Uhr, schrieb yuppie : The tools are *local* utilities. Including the ZCML doesn't fix this issue. You have to run the upgrade step. Should we add a warning to CMFTools.utils.getToolByName? To use getUtility and the interface instead? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] 2.3
Hi Jens, Am 05.04.2012, 17:35 Uhr, schrieb Jens Vagelpohl : H Charlie, Before going any further, please stop that usage pattern. The correct way to build those Sphinx docs is: - cd into the docs folder - make sure the sphinx-build script you want to use, which can be either the one inside Products.DCWorkflow or at the toplevel "CMF" package, is in the path and then run "make html": $ cd docs/ $ PATH="../bin:$PATH" make html ... Thanks for the clarification and your patience. I have a feeling with the way you are doing it you put output and Sphinx build state files for different Sphinx buildouts in one and the same place, which will not work. It does create the ReST files that make can then run over. I've found the problem: the files I generate have the wrong paths in the automodule directive .. automodule:: DCWorkflow.utils instead of .. automodule:: Products.DCWorkflow.utils Fixed now. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] 2.3
Am 04.04.2012, 23:33 Uhr, schrieb Jens Vagelpohl : This is now fixed. The top-level (CMF package) buildout did not know about the documentation dependency on "pkginfo", only the buildout inside the Products.CMFDefault package did. Thanks very much Jens. I've added DCWorkflow except for the fact I can't get the api-doc to work properly. I've basically copied what you did for CMFDefault so added a bootstrap for doc generation but I'm still getting import errors. I'm using the "CMF-level" api-doc to generate the ReST files. fuchsia:Products.DCWorkflow charlieclark$ bin/sphinx-build docs tmp Running Sphinx v1.1.3 loading pickled environment... done No builder selected, using default: html building [html]: targets for 0 source files that are out of date updating environment: 0 added, 2 changed, 1 removed Traceback (most recent call last):rkflow File "/Users/charlieclark/Sites/CMF/src/Products.DCWorkflow/eggs/Sphinx-1.1.3-py2.6.egg/sphinx/ext/autodoc.py", line 321, in import_object __import__(self.modname) I'm using the "CMF-level" api-doc to generate the ReST files. <- I suspect this may be where I'm going wrong but I couldn't see anything in the conf.py or Makefile that looked liked it would work the proper magic. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] 2.3
Am 04.04.2012, 17:45 Uhr, schrieb Charlie Clark : At the risk of looking like Baldrick: which configuration are you referring to? CMFDefault's own buildout or the top-level one? I see the CMF buildout has gained the sphinx-quickstart command but I haven't quite worked out how to get this to run using my local files. Sometimes it just helps to ask the dumb questions out loud... docs support has been added to the Products.CMFDefault *package*. The key was in that word, Charlie. :o api-doc stuff looks pretty reasonable but needs some trimming: all sub-folders including tests are treated as packages which doesn't make a great deal of sense from the point of documenting the API. """ fuchsia:CMF charlieclark$ bin/sphinx-build src/Products.CMFDefault/docs tmp Running Sphinx v1.1.2 Exception occurred: File "/Users/charlieclark/Sites/CMF/src/Products.CMFDefault/docs/conf.py", line 16, in import pkginfo ImportError: No module named pkginfo """ sphinx-build no longer works. Or should I be working from CMFDefault checkout and building from there? See above. Should probably check why documents now can't be generated from the top-level of the project, although package level is probably saner. I also cleaned up many Sphinx complaints about bad formatting. Thanks. I'm still working on fixing up the intra-document references and footnotes which I want to be able to build before checking in. I can, of course, now do this! Time to review the Sphinx documentation to reduce my error rate! Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] 2.3
Hi Jens, Am 04.04.2012, 11:17 Uhr, schrieb Jens Vagelpohl : I have fixed it by creating a small buildout configuration at the root of the package that will create a working sphinx-build script under bin/ with all the dependencies set up, and by replacing all faulty module references to "CMFDefault" with "Products.CMFDefault". At the risk of looking like Baldrick: which configuration are you referring to? CMFDefault's own buildout or the top-level one? I see the CMF buildout has gained the sphinx-quickstart command but I haven't quite worked out how to get this to run using my local files. """ fuchsia:CMF charlieclark$ bin/sphinx-build src/Products.CMFDefault/docs tmp Running Sphinx v1.1.2 Exception occurred: File "/Users/charlieclark/Sites/CMF/src/Products.CMFDefault/docs/conf.py", line 16, in import pkginfo ImportError: No module named pkginfo """ sphinx-build no longer works. Or should I be working from CMFDefault checkout and building from there? I also cleaned up many Sphinx complaints about bad formatting. Thanks. I'm still working on fixing up the intra-document references and footnotes which I want to be able to build before checking in. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] 2.3
Hi Yuppie, Am 03.04.2012, 14:11 Uhr, schrieb yuppie : +1 Is CMFDefault/help now obsolete? Could it be deleted? I guess so. I'm still working on "tidying" up what can loosely be termed as the narrative documentation. Still in the clean-up phase but should get this done this week. @ Jens will we be able to point the release to a docs page on Zope.org? I had a go at autogenerating the api documentation but failed miserably - lots of empty pages got generated because Sphinx had trouble with import paths. Does anyone know the appropriate incantations for this? Not sure if this would be for 2.3 but I think that CMFCalendar should be rolled into CMFDefault. The main reason being that the default profile for CMFCalendar uses browser views and explicitly requires the CMFDefault skin layer. You then can't use CMFCalendar if you override the default skin layer. Plus, CMFCalendar's functionality is extremely limited and intimately tied to CMFDefault. -1 CMFCalendar is an example add-on. It should be possible to write add-ons like CMFCalendar. So if there are any issues with keeping it in a separate optional package they should be fixed instead of giving up. Okay. I guess the key issue is making working with Zope-3 skins easier. I'd like to have a different CMFDefault profile that did without CMF skins (yes, I do appreciate the irony), ie. the ability to jetison PythonScripts et al. CMFCalendar won't work with that because of the explicit dependency upon the CMF skin layer. Certainly a big enough change not to be in 2.3. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] 2.3
Am 21.03.2012, 22:58 Uhr, schrieb Jens Vagelpohl : The beta eggs are released now. Jens, could we have a patch release to include my fallbacks? I'd like to be able to try the beta with a couple of other sites without adding links to trunk in my buildouts. Charlie PS. We should probably try and avoid an April 1st release! ;-) -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] 2.3
Am 22.03.2012, 13:46 Uhr, schrieb Jens Vagelpohl : The tests only fail on Python 2.7, they run through fine on 2.6. As such, they're not functional failures but failures dur to changes in behavior between 2.6 and 2.7. In one place a DeprecationWarning is not written to the log, in another diff output has changed slightly. Thanks, Jens. I'd forgotten I'd made Python 2.7 my default. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] 2.3
Am 22.03.2012, 13:42 Uhr, schrieb Charlie Clark : thanks for the quick and informative reply. On both of my test sites I've not been able to look at the site in the ZMI without getting the errors. Even running Site/portal_setup fails. FWIW both sites are using the ursa globals. I can try patching this in the way you suggest and then see how the upgrade works. Fallbacks for ursa.py and DynamicType's getIconURL required but then an upgrade is possible. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] 2.3
Am 22.03.2012, 13:28 Uhr, schrieb yuppie : The tools are *local* utilities. Including the ZCML doesn't fix this issue. You have to run the upgrade step. It should be possible to use the ZMI without this kind of errors. In some places I added fallbacks like this one: try: utool = getUtility(IURLTool) except ComponentLookupError: # BBB: fallback for CMF 2.2 instances utool = aq_get(self, 'portal_url') If you can't run the upgrades from the ZMI it might be necessary to add more fallbacks in CMF. Hi Yuppie, thanks for the quick and informative reply. On both of my test sites I've not been able to look at the site in the ZMI without getting the errors. Even running Site/portal_setup fails. FWIW both sites are using the ursa globals. I can try patching this in the way you suggest and then see how the upgrade works. Charlie PS. I've just run tests on trunk and am getting failures in CMFCore: Failure in test test_getActionObject_oldskool_action_deprecated (Products.CMFCore.tests.test_ActionsTool.ActionsToolTests) Traceback (most recent call last): File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py", line 327, in run testMethod() File "/Users/charlieclark/Sites/CMF/src/Products.CMFCore/Products/CMFCore/tests/test_ActionsTool.py", line 99, in test_getActionObject_oldskool_action_deprecated '2.4. Use Action and Action Category objects instead.' in warning) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py", line 608, in deprecated_func return original_func(*args, **kwargs) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py", line 420, in assertTrue raise self.failureException(msg) AssertionError: False is not true Failure in test test_getDiff (Products.CMFCore.tests.test_FSPythonScript.CustomizedPythonScriptTests) Traceback (most recent call last): File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py", line 327, in run testMethod() File "/Users/charlieclark/Sites/CMF/src/Products.CMFCore/Products/CMFCore/tests/test_FSPythonScript.py", line 269, in test_getDiff self.assertEqual(list(cps.getDiff()), _DIFF_TEXT.splitlines()) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py", line 509, in assertEqual assertion_func(first, second, msg=msg) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py", line 738, in assertListEqual self.assertSequenceEqual(list1, list2, msg, seq_type=list) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py", line 720, in assertSequenceEqual self.fail(msg) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py", line 408, in fail raise self.failureException(msg) AssertionError: Lists differ: ['--- original', '+++ modified... != ['--- original ', '+++ modifie... First differing element 0: --- original --- original - ['--- original', + ['--- original ', ? + - '+++ modified', + '+++ modified ', ? + '@@ -7,4 +7,4 @@', ' ##parameters=', ' ##title=', ' ##', "-return 'cps'", "+return 'cps -- replaced'"] Ran 219 tests with 2 failures and 0 errors in 3.376 seconds. -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] [OFFTOPIC] Re: 2.3
Am 22.03.2012, 12:35 Uhr, schrieb Ruslan Mahmatkhanov : Sorry for offtopic, but since I'm fighting with similar error (not related to new CMF and CMF at all) hope you don't mind if I ask it there: ComponentLookupError: ((0x2db87acc>, URL=http://localhost:8080/Plone/portal_css/Sunburst%20Theme/++resource++plone.app.discussion.stylesheets/discussion.css>), , u'') Hi Ruslan, apart from telling you that something hasn't been registered I can't really help you on this. It looks like the ETag cache info can't be set but you'll need to talk to the Plone people for more information. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] 2.3
Am 21.03.2012, 22:58 Uhr, schrieb Jens Vagelpohl : The beta eggs are released now. Great, thanks! I'm testing with some existing sites and getting the following error even before I run the upgrades: ComponentLookupError: (Products.CMFCore.interfaces._tools.IURLTool>, '') I'm obviously missing a registration but my site includes Products.CMFCore package. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] 2.3
Am 21.03.2012, 16:47 Uhr, schrieb Jens Vagelpohl : If we keep piling up tasks that are too big to be tackled in a small amount of time as part of the release process we'll never get anything released. I would classify both these items as "nice to have, but not on the critical path". True. I've done a *very* basic port of the docs to ReST so that Sphinx will at least generate stuff. This has been done by copying the exiting STX files and renaming them. Should they be moved instead to preserve the history? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] 2.3
Am 21.03.2012, 00:36 Uhr, schrieb Tres Seaver : Sounds good. We should review the code for any stuff deprecated-and-promised-to-be-remove-in-2.3 before releasing a beta. I suppose we could also migrate the old Zope Help docs to "docs" for Sphinx generation? I know much of the docs are inaccurate and outdated but this might help expose the worst bits which should then be exorcised or at least pruned. Not sure if this would be for 2.3 but I think that CMFCalendar should be rolled into CMFDefault. The main reason being that the default profile for CMFCalendar uses browser views and explicitly requires the CMFDefault skin layer. You then can't use CMFCalendar if you override the default skin layer. Plus, CMFCalendar's functionality is extremely limited and intimately tied to CMFDefault. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] 2.3
Hi, I finally landed my update step for syndication during the PyCon sprints! I thought I had a few more browser views to update to using the EditSettingsForm but on a quick check of the files it seems that this has already been done. Yuppie, I remember that you have commented out some of my views (portal configuration and membership, I think) because of the encoding problem, did you correct them yourself last year and I was simply looking at old source? If that is the case then I think we're good to go with 2.3. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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
Hi Tres, Am 08.02.2012, 21:36 Uhr, schrieb Tres Seaver : Was effbot.org down last night? I can see that distribution today on the downloads page. is this related to what Hanno recently posted to zope-dev? """ I hopefully fixed the Zope 4 failures - related to not being allowed to download elementtree from effbot.org. """ Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Towards a 2.3 Release
At the recent Zope 4 sprint in Berlin [1] Yuppie, Jens and myself briefly discussed making a 2.3 release. It is largely a matter of crossing the t's and dotting the i's: * SyndicationTool needs testing with the PythonScripts and templates to make sure the extensive changes haven't broken them. The upgrade step needs writing and testing * all my views that affect tool "properties" need to use the new SettingsForm view to be safe * all my formlib-based views will revert to the standard CMF form display * views only profile needs completing * apparently the "absolut" skin can cause problems with used in combination with profiles. Yuppie, do you have any more information on this? * the views only profile is no longer experimental. I would like to be able to make this a base profile (with the "absolut" skin) but have hit problems with CMFCalendar requiring the standard CMFDefault skin In Berlin we decided against a beta but I would actually like to test my existing sites against a new version, so a beta would probably be a good idea. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Fwd: [Zope-dev] Products.CMFUid runtime issue
Am 28.09.2011, 16:38 Uhr, schrieb Charlie Clark : > Am 27.09.2011, 23:41 Uhr, schrieb Charlie Clark > : > >> Hi Ruslan, >> I've just looked at this and it seems that we never released a 2.2 >> version >> of CMFUid so you're using a very old bit of code that is most probably >> not >> suited to your version of Zope. You should be okay with the 2.2.0-beta >> version. > > It looks like there was a 2.2.1 tag made but never released. Was there a > reason for this or just an oversight? I have just run the CMFUid tests > with Python 2.6 against Zope-2.13.9 and all passed. Is that okay for a > release? > > Ruslan, as for putting these into the BSD ports tree, I think that's fine > with Zope but I can't really think of a need for a standalone CMF build. > > Charlie A follow-up on this after discussing the issue with Jens at the Zope 4 sprint in Berlin: 2.2 was released but flagged as "hidden" on PyPI. That flag has now been removed. Ruslan, can you confirm that your BSD port now works as expected? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] working on the trunk
Am 05.10.2011, 15:26 Uhr, schrieb yuppie : > Strange! Your container implements IAttributeAnnotatable and > AttributeAnnotations is registered correctly? Yes, I was working with objects that provided things explicitly. > Are you trying to use zope.annotation.factory? Last time I checked that > didn't work with Zope 2. But the AttributeAnnotations adapter works for > me without showing anything in the ZMI. That's probably the problem - I was following the documentation which suggests using zope.annotation.factory. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] working on the trunk
Am 04.10.2011, 10:55 Uhr, schrieb yuppie : > I think in general it's fine to use zope.schema for CMFCore interfaces. > But if you use properties instead of separate accessors and mutators, > you can't set different read/write permissions in Zope 2. So please make > sure modifying the settings is protected sufficiently. Right, thanks for the reminder. Currently I have a schema in CMFDefault derived from a very abstract interface in CMFCore and I think I'll stick with that because I use a CMFDefault specific SimpleVocabulary. >> Regarding zope.annotation - IAttributeAnnotatable creates a new object >> within the folder > Why do you think so? AFAICS the default implementation stores all > annotations in the __annotations__ attribute. Running some tests with the most recent version and it definitely creates child objects that are visible in the ZMI. I guess I need to test this a bit more but I suspect I might have to provide my own implementation. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] working on the trunk
Am 30.09.2011, 22:29 Uhr, schrieb Tres Seaver : > > You want 'container.ZopeFind' or 'container.ZopeFindAndApply'. Thanks Tres! Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] working on the trunk
Am 30.09.2011, 10:55 Uhr, schrieb yuppie : > > AFAICS only the getUpdateBase method of ISyndicationTool needs to be > backwards compatible. Everything else is new API or doesn't return > DateTime objects. Wouldn't it be better to use datetime internally? You > already need an upgrade step for SyndicationInformation. Writing an > additional upgrade step for SyndicationTool wouldn't be much extra work. ISyndicationInfo is a new interface. I'm tempted to use zope.schema directly on this but I suppose that does tie any implementation to zope.schema rather maybe annotated Python tyes. Thoughts? Regarding zope.annotation - IAttributeAnnotatable creates a new object within the folder but I'd rather not have the SyndicationInfo visible within the ZMI but IAnnotations only uses a dictionary and so less suitable for storing multiple values. If I go the AttributeAnnotatable way is it okay to use Persistent rather than SimpleItem as long as manage_fixupOwnershiAafterAdd is provided? Or is that too kludgy and preferable to work on my current adapter to provide attribute access to an Annotations dictionary? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] working on the trunk
Hiya yuppie, Am 30.09.2011, 10:55 Uhr, schrieb yuppie : > If you want to modernize SyndicationInformation, why do you still store > DateTime objects in the database? (And why don't you use > zope.annotation?) I think that when I started this I was initially trying to update the syndication stuff and practise writing tests by filling out the missing blanks. It then snowballed with my views work. You're right, of course, that having removing the ZMI interface to SyndicationInfo I've got more control over how stuff was stored. I need to revisit the zope.annotation docs but the last time I looked it didn't offer much. > Quoting the docstring of schema.py: "SchemaAdapterBase and > ProxyFieldProperty are legacy code. They should only be used to adapt > old content types that can't handle unicode and datetime correctly." What? You think I'm going to start reading the code? ;-) Having got Site Syndication licked I thought I could consolidate the view code. How wrong I was! > AFAICS only the getUpdateBase method of ISyndicationTool needs to be > backwards compatible. Everything else is new API or doesn't return > DateTime objects. Wouldn't it be better to use datetime internally? You > already need an upgrade step for SyndicationInformation. Writing an > additional upgrade step for SyndicationTool wouldn't be much extra work. Right. BTW. anyone know of an OFS implementation of os.walk? There used to be zwalk but I think it's disappeared behind the Google horizon. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] working on the trunk
Am 29.09.2011, 14:14 Uhr, schrieb yuppie :
> Yes.
I've hit a bit of a problem with folder syndication - I already have an
annotations adapter for storing the values on the folder and I can extend
this to be able to handle individual values rather than a dictionary but
ProxyFieldProperties don't work because the adapter itself doesn't support
properties. I also have some additional methods on the adapter that I use
from the view. What do you think is the best way to proceed here? Subclass
the SchemaAdapter so that the encoding and DateTime stuff works okay? For
the methods I don't see any alternative but to expose the annotations
adapter explicitly within the view. Bit of a muddle, I guess.
>> I still need to set view.adapters = {} for some reason but that's okay.
> zope.formlib expects that setUpWidgets is always called before
> handle_change. If you test handle_change isolated, you have to set
> adapters by hand.
My tests never call setUpWidgets - that is almost impossible from within
unittests. But applyChanges expects an adapters dictionary for the form
even it's empty.
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
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] working on the trunk
Hi Yuppie,
thanks as ever for the helpful explanation.
Am 29.09.2011, 10:39 Uhr, schrieb yuppie :
> SettingsEditFormBase has a getContent() method similar to that in
> z3c.form. This allows a clean distinction between 'content' and
> 'context'. For content objects they are usually the same, but in your
> case the site root is the context and the (adapted) SyndicationTool is
> the edited "content".
SettingsEditFormBase landed after my sturm and drang work last year. So
you generally replace my explicit calls to tools with getContent? I guess
I just need some proxyFields for enabling and disabling. Had to throw in
some additional adapters to make the tests happy but test_handle_change
now works as it should. I guess unittesting views is pushing things a bit
but I like it if I can get it to work.
> Please have a look at the membership views. They show how to use
> getContent(). In your case the method would look like this:
> @memoize
> def getContent(self):
> syndtool = getUtility(ISyndicationTool)
> return SyndicationToolSchemaAdapter(syndtool)
> This example uses a hardcoded adapter. You can still register it and
> look it up, but I guess that's overkill.
Indeed.
> I doubt anybody wants to use a customized adapter. And if it is
> hardcoded, you don't need to register
> it for testing.
I still need to set view.adapters = {} for some reason but that's okay.
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
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] working on the trunk
Am 27.01.2011, 17:05 Uhr, schrieb yuppie : > zope.formlib is not made for DateTime values and encoded strings. So you > *always* have to make sure these values are converted correctly. And it > is hard to do that inside the form code. Obviously you did have trouble > to get it right that way. After I started using adapters for the edited > objects I had much less trouble using formlib. Of course you don't need > an adapter if your objects already provide the right interface. > And one more benefit: Inside the form code you can completely ignore the > old-fashioned implementation of the edited objects and write nice modern > code. Finally have made the time to look at this. I've written a schema adapter for the forms and it looks like SettingsEditForm handles the conversion to Zope's DateTime nicely. Now, I'm stuck with the problem of getting my view unit tests to work. Looks like I need a few adapters registered. :-/ >> In my defence I hope it's worth noting that we now >> have tests for a heap of stuff in CMFDefault which previously didn't >> exist. >> >> Regarding SyndicationInfo - I'd appreciate any pointers on writing a >> migration step. Given the hopelessly outdated state of the current >> implementation I'm not convinced anyone will need to do the migration > What was wrong with the old implementation? I never had trouble using > the old configuration objects and forms. The old RSS template didn't > work for me, but that's a different issue. I think the old implementation was just wrong headed to use SimpleItem for this. But think I've worked out how to do the migration. >> but >> then, of course, one of the aims of CMFDefault is to provide exactly >> this >> kind of example. > I'm sure I'm not the only one who has existing CMF sites with > SyndicationInformation objects in it. Making sure these sites can be > upgraded without trouble is essential. And not a nice to have extra. > Especially if the old implementation did work and the new one doesn't > provide any new features. I agree that a migration step is necessary and will put one in. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Switching to Chameleon
Am 28.09.2011, 17:20 Uhr, schrieb Laurence Rowe : > Plone tends to wait for CMF to stabilise before thinking of moving to > a new version. At least when I last looked around a year ago (after > adding some workflow pluggability into CMF) CMF trunk broke far too > much in Plone to consider it for a minor revision. Fair enough, although CMF releases tend to be very stable. > Hopefully someone All too often that someone tends to be yuppie... > will put the effort in to port Plone to CMF 2.3 in time for Plone 5. > It's certainly true that CMF is a smaller part of Plone than it used > to be, that's down to the introduction of the component architecture > so new features tend to be built on that instead. FWIW I just ran the tests for CMFDefault with Chameleon. Seems to breaks in the doctests due to the way i18n is handled. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Switching to Chameleon
Am 28.09.2011, 16:48 Uhr, schrieb Hanno Schlichting : > > Nah, it most likely won't. There's no PLIP yet to propose such an > update and I'm not aware of anyone who plans one. I suppose you hardly need it any more now that you've been able to push most of the stuff you do need straight into Zope(2). Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Switching to Chameleon
Am 28.09.2011, 16:42 Uhr, schrieb Alan Runyan : > +1 the Plone guys have shot me down for including this in Plone 4.3; > but as Plone 4.3 probably would include CMF 2.3 - it would make me happy > to see them > getting five.pt whether they like it or not. Really? I thought Plone 4 was already using Chameleon? BTW. I'm hoping to finish up my stuff for 2.3 at PyCon Germany. Who else is going to be around? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Switching to Chameleon
Hi, finally getting some development done for probably the first time this year. I've been able to switch all my CMF-based projects to Chameleon (via five.pt) and have not hit any problems. Should we do this for CMF 2.3? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Fwd: [Zope-dev] Products.CMFUid runtime issue
Am 27.09.2011, 23:41 Uhr, schrieb Charlie Clark : > Hi Ruslan, > I've just looked at this and it seems that we never released a 2.2 > version > of CMFUid so you're using a very old bit of code that is most probably > not > suited to your version of Zope. You should be okay with the 2.2.0-beta > version. It looks like there was a 2.2.1 tag made but never released. Was there a reason for this or just an oversight? I have just run the CMFUid tests with Python 2.6 against Zope-2.13.9 and all passed. Is that okay for a release? Ruslan, as for putting these into the BSD ports tree, I think that's fine with Zope but I can't really think of a need for a standalone CMF build. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Fwd: [Zope-dev] Products.CMFUid runtime issue
Am 25.09.2011, 11:04 Uhr, schrieb Ruslan Mahmatkhanov : > Good day. > When trying to access zope with Products.CMFUid installed, i got this > error: > """ > File > "/usr/local/lib/python2.7/site-packages/Products.CMFUid-2.1.3-py2.7.egg/Products/CMFUid/UniqueIdAnnotationTool.py", > line 118, in UniqueIdAnnotationTool > SimpleItem.__implements__, > AttributeError: type object 'SimpleItem' has no attribute > '__implements__' > """ > I dunno if this correct solution, but i was able to avoid this with > changing calls to SimpleItem.__implements__ to > SimpleItem.__implemented__. And all seems working fine. Hi Ruslan, I've just looked at this and it seems that we never released a 2.2 version of CMFUid so you're using a very old bit of code that is most probably not suited to your version of Zope. You should be okay with the 2.2.0-beta version. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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
Am 23.08.2011, 07:00 Uhr, schrieb CMF tests summarizer : > [1]UNKNOWN FAILED (failures=16, errors=13) : CMF-trunk Zope-trunk > Python-2.6.6 : Linux >https://mail.zope.org/pipermail/cmf-tests/2011-August/015153.html This one is beyond my feeble powers. It looks like all the doctests are failing. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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
Am 07.08.2011, 20:45 Uhr, schrieb Hanno Schlichting : > So yes, while these changes look at bit evil, they do have a major > impact. Quite a speed-up! Unfortunately, as Jens has pointed out, it breaks DiscussionItem in a non-obvious way. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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
Am 07.08.2011, 17:13 Uhr, schrieb Jens Vagelpohl : > The problem appears in CMFDefault.DiscussionItem.createReply on line > 251, where the newly created discussion reply is aqcuisition-wrapped in > the talkback object: >item = DiscussionItem( id, title=title, description=title ) > self._container[id] = item > item = item.__of__(self) > 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. Ouch! 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. http://svn.zope.org/Zope/trunk/src/OFS/Traversable.py?rev=122213&view=diff&r1=122213&r2=122212&p1=Zope/trunk/src/OFS/Traversable.py&p2=/Zope/trunk/src/OFS/Traversable.py The revised method is significantly more complicated. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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
Am 05.07.2011, 07:00 Uhr, schrieb CMF tests summarizer : > [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. -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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
Am 31.05.2011, 16:05 Uhr, schrieb Godefroid Chapelle : > The arguments against the proposal seem lighter and lighter. No, they are the same all along. It is the repetition that is becoming tedious. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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 2.3 plans?
Am 19.04.2011, 14:24 Uhr, schrieb Laurence Rowe : > I think we would need to get to a CMF beta in the next couple of > months to have a realistic chance of getting this into Plone 4.2. I think I should be able to commit myself to getting my stuff done by the end of May. Jens, before cutting a release we should probably review the proposed changes and what still needs or should still be done. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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 2.3 plans?
Am 19.04.2011, 13:41 Uhr, schrieb Jens Vagelpohl : > Hi Laurence, > I could create a first alpha release for the various packages if that > helps. > For the first beta a.k.a. trunk branch point I need to know if anyone is > working on features that are not on the trunk yet. Please speak up if > branching for CMF 2.3 needs to be delayed. AFAIK the major block to a release is the stuff I need to tidy up in my browser-views only skin plus an upgrade step from old-style SyndicationInfo to an adapter based one. It's all on trunk and Yuppie has kindly done most(?) of the tidying up necessary but I still need to find the time to finish up the bits. Laurence, what timescale are you looking at? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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: 2, UNKNOWN: 2
Am 13.04.2011, 07:00 Uhr, schrieb CMF tests summarizer :
> [1]UNKNOWN UNKNOWN : CMF-trunk Zope-2.13 Python-2.6.5 : Linux
>https://mail.zope.org/pipermail/cmf-tests/2011-April/014668.html
> [2]UNKNOWN UNKNOWN : CMF-trunk Zope-trunk Python-2.6.5 : Linux
>https://mail.zope.org/pipermail/cmf-tests/2011-April/014669.html
Both of these seem to be caused by a site being down:
Running /usr/local/python2.6/bin/python bootstrap.py --distribute
Traceback (most recent call last):
File "bootstrap.py", line 164, in
options.setup_source).read().replace('\r\n', '\n')
File "/usr/local/python2.6/lib/python2.6/urllib2.py", line 126, in
urlopen
return _opener.open(url, data, timeout)
File "/usr/local/python2.6/lib/python2.6/urllib2.py", line 391, in open
response = self._open(req, data)
File "/usr/local/python2.6/lib/python2.6/urllib2.py", line 409, in _open
'_open', req)
File "/usr/local/python2.6/lib/python2.6/urllib2.py", line 369, in
_call_chain
result = func(*args)
File "/usr/local/python2.6/lib/python2.6/urllib2.py", line 1161, in
http_open
return self.do_open(httplib.HTTPConnection, req)
File "/usr/local/python2.6/lib/python2.6/urllib2.py", line 1136, in
do_open
raise URLError(err)
urllib2.URLError:
Running ./bin/buildout
/bin/sh: ./bin/buildout: No such file or directory
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
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: 4 OK, 2 Failed
Am 29.03.2011, 16:16 Uhr, schrieb Tres Seaver :
> These seem to be tied to Yuppie's recent formlib changes::
> --
> File
> "/home/stefan/autotest/temp/python26-zope213-cmf23/src/Products.CMFDefault/Products/CMFDefault/formlib/schema.txt",
> line 117, in schema.txt
> Failed example:
> content.foo_datetime == foo_zope_datetime
> Expected:
> True
> Got:
> False
Yes, looks like the change to DST in Europe is the problem:
(Pdb) content.foo_datetime
DateTime('1969/12/31 00:00:00 GMT+1')
(Pdb) foo_zope_datetime
DateTime('1969/12/31 00:00:00 GMT+2')
I have *no* idea why this is happening!
FWIW I'd prefer unit tests for this kind of work but most importantly is
the work Yuppie is doing on bringing the two together. Partly caused by my
heavy-handed use datetime in the browser views I've written.
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
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] RFC: Removing svn:externals from buildouts
Am 26.03.2011, 08:12 Uhr, schrieb Raphael Ritz : > In my understanding it is a convenience to manage > checkouts as well as switching back and forth between > dev mode and non-dev mode for selected eggs. Of course, I could always go and look things up myself! http://pypi.python.org/pypi/mr.developer It *is* some kind of buildout extension. From my cursory glance over the documentation I think this should be okay: we replace svn:externals with an appropriate section in a buildout.cfg? Probably easier for me to work with than manually doing svn switch. I'll give a run next week and let you know. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] RFC: Removing svn:externals from buildouts
Am 25.03.2011, 18:03 Uhr, schrieb yuppie : > Don't know who uses mr.developer for CMF development. I added that > configuration recently and only on trunk. I've heard of it but I have no idea what it is - anyone surprised at my ignorance? ;-) I thought it was some kind of buildout package for testing! > I still have some trouble using mr.developer in Eclipse. But if it works > for everybody else and the nightly tests don't break I'm fine with > replacing the svn:externals. Looks like I'll have to look at it and see if I work out how to use it. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Bug 739951: deleteLocalRoles times out
Am 22.03.2011, 05:37 Uhr, schrieb Suresh V. : > Please see: > https://bugs.launchpad.net/zope-cmf/+bug/739951 > for bug report and patch. > If approved, I can commit. -10 for me. This breaks transactional integrity. Do you have a test case for this? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] force unicode on user input text fields
Am 24.02.2011, 10:45 Uhr, schrieb ToutPT : > Hi, > Context: I'm working on an issue with dexterity reported here: > http://goo.gl/Hc9yg > This issue is related to CMF, so I want to ask: What do you think if we > force unicode > on setTitle and setDescription mutators ? Hiya Jean-Michel, we had a recent discussion about this and Yuppie drew up some useful guidelines - http://svn.zope.org/*checkout*/CMF/trunk/CODINGSTYLE.txt So at the moment it's a no go on enforcing unicode for setTitle, setDescription, et al. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] wrapping users - a proposal
Am 22.02.2011, 11:46 Uhr, schrieb yuppie :
Hi Yuppie,
thanks very much for proposing and implementing this. It should make the
whole "Member" thing a lot easier and safer to work with.
> 1.) MemberData factory lookup
> -
> CMF 2.2 has a new feature that allows to register customized MemberData
> factories: https://bugs.launchpad.net/zope-cmf/+bug/377208
> That feature seems to be obsolete in CMF 2.3 because the MemberAdapter
> is now responsible for creating MemberData objects and AFAICS using
> customized MemberData with an un-customized MemberAdapter doesn't make
> much sense.
> Because CMF 2.3 will anyway break customized MemberData implementations
> I propose to remove the factory lookup completely in CMF 2.3.
+1
I hope this doesn't break too much code for people.
> 2.) direct MemberData property access
> -
> Wrapped users are now MemberAdapter objects. So wrapped users no longer
> have attributes like 'email' or 'listed'. This is a security improvement
> because you can't bypass the API with its permission checks.
> But 'member.email' is more convenient than 'member.getProperty('email')'
> and used in many places. I fixed these in CMF itself, it I'm afraid that
> change will break a lot of third party code.
> I propose to add read-only properties that return the values in a modern
> format (datetime instead of DateTime, unicode instead of encoded
> strings).
> Question:
> Should we support a fixed schema with the default member data properties
> or should we use a customized __getattr__ method?
If the access is always via the adapter then I would prefer a customised
__getattr__
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
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
Am 03.02.2011, 00:50 Uhr, schrieb Tres Seaver : > Can anybody else comment who is doing CMF-based work on Windows? Not personally but involved with enough projects that also have (largely frontend) development on windows. What are "modern" windows systems? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] working on the trunk
Am 26.01.2011, 16:50 Uhr, schrieb yuppie : > I'm not happy with the current state of CMF trunk. Especially the > syndication related changes cause trouble in different ways: > - SyndicationInformation was replaced by SyndicationInfo without > providing migration code. Local syndication settings get lost in > existing sites. > - In the ZMI the SyndicationTool no longer has a tab that allows to > inspect and modify tool settings. The form that replaces the ZMI tab is > broken: It uses datetime objects instead of DateTime objects and mixes > them with existing DateTime settings. > Last week I reviewed parts of the new code and fixed some small issues. > But the bigger issues still exist. Based on what I encountered I wrote > this small guide: > http://svn.zope.org/*checkout*/CMF/trunk/CODINGSTYLE.txt > Please keep the the trunk stable and use your own branch for unfinished > changes. I think this applies almost entirely to my work on browser views. Yuppie's been in touch with me privately but I haven't found time to do the tidying up. I agree with nearly all the points. I'm not certain that SchemaAdapters are always necessary. In my defence I hope it's worth noting that we now have tests for a heap of stuff in CMFDefault which previously didn't exist. Regarding SyndicationInfo - I'd appreciate any pointers on writing a migration step. Given the hopelessly outdated state of the current implementation I'm not convinced anyone will need to do the migration but then, of course, one of the aims of CMFDefault is to provide exactly this kind of example. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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/branches/2.2/Products/CMFCore/exportimport/content.py remove type check that seem useless
Am 13.01.2011, 15:27 Uhr, schrieb Godefroid Chapelle : > > http://zope3.pov.lt/trac/changeset/119560/Products.CMFCore/branches/2.2 That looks okay to me but I'm not sure if it should stay quite that way - a dedicated method for encoding might be preferable. But I'm not sure if the encoding shouldn't happen when the file is written - aren't there other places where this might be required? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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/branches/2.2/Products/CMFCore/exportimport/content.py remove type check that seem useless
Am 13.01.2011, 14:01 Uhr, schrieb Godefroid Chapelle : >> Aren't you risking double encoding now? That patch looks like it makes >> things worse, not better. > I am not sure I understand what you mean. Hi Godefroid, the unpatched code checks to see whether a self.Title() or self.Description() are unicode in which case they can be encoded. Your patch will force encoding even on strings, ie. double-encoding. Regarding the procedure: changes to the CMF should be tested on CMF buildouts, with CMF specific tests. You should probably run the exportimport with pdb to see what self.Title() is returning but, yes, I suspect the problem you are experiencing is Plone and not CMF related. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Trouble adding a new site
Am 08.12.2010, 15:21 Uhr, schrieb yuppie : > No. Have a look at the addConfiguredSite function: It first adds a bare > CMFSite object, then adds the setup tool and importing the profile that > adds the types tool is the last step. Your event handler just tries too > early to look up the tool. ah, got it! I do have a subscriber to SiteRoot modifications... Thanks Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Trouble adding a new site
Am 08.12.2010, 14:48 Uhr, schrieb yuppie : > In line 59 you just have a bare CMFSite object without any tools. Hi Yuppie, thanks for the quick reply. How come I don't have any tools? Is this related to more recent buildouts not magically including Products.* stuff? Products.CMFDefault (2.2.0) is installed. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Trouble adding a new site
Hi, I've got a problem with CMF on Zope 2.12.13. I'm sure it's just a bit of configuration I'm missing but I'm getting the following error when I try and add a site to fresh buildout: Traceback (innermost last): Module ZPublisher.Publish, line 127, in publish Module ZPublisher.mapply, line 77, in mapply Module ZPublisher.Publish, line 47, in call_object Module Products.CMFDefault.factory, line 59, in addConfiguredSite Module OFS.ObjectManager, line 366, in _setObject Module zope.container.contained, line 329, in notifyContainerModified Module zope.event, line 23, in notify Module zope.component.event, line 26, in dispatch Module zope.component._api, line 138, in subscribers Module zope.component.registry, line 323, in subscribers Module zope.interface.adapter, line 575, in subscribers Module zope.component.event, line 33, in objectEventNotify Module zope.component._api, line 138, in subscribers Module zope.component.registry, line 323, in subscribers Module zope.interface.adapter, line 575, in subscribers Module advitam.site.navigation.navigation, line 44, in FolderChange Module zope.site.hooks, line 95, in adapter_hook Module advitam.site.navigation.navigation, line 20, in __init__ Module Products.CMFCore.PortalFolder, line 191, in contentIds Module Products.CMFCore.PortalFolder, line 184, in contentItems Module Products.CMFCore.PortalFolder, line 153, in _filteredItems Module Products.CMFCore.utils, line 123, in getToolByName AttributeError: portal_types Thanks for any pointers! Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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
