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, 00:19 Uhr, schrieb Maurits van Rees <m.van.r...@zestsoftware.nl>: 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 # 754
Am .05.2015, 04:10 Uhr, schrieb Jenkins ger...@starzel.de: 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 y.2...@wcm-solutions.de: 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 ger...@starzel.de: 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
Hi Yuppie, (checks that he is writing to the list) Am 01.08.2013, 11:46 Uhr, schrieb yuppie y.2...@wcm-solutions.de: 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] member area / home folder changes
Am 05.08.2013, 12:26 Uhr, schrieb yuppie y.2...@wcm-solutions.de: 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] [dev] CMFDefault: renaming type action urls
Am 21.05.2013, 12:34 Uhr, schrieb yuppie y.2...@wcm-solutions.de: 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] 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 02.03.2013, 22:44 Uhr, schrieb Tres Seaver tsea...@palladion.com: 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 04.03.2013, 17:46 Uhr, schrieb Lennart Regebro rege...@gmail.com: 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, 21:42 Uhr, schrieb Martin Aspeli optilude+li...@gmail.com: 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 ha...@hannosch.eu: 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-dev] ZTK 2.0: Deprecate zope.sequencesort
Hi Tres, Am 28.02.2013, 21:04 Uhr, schrieb Tres Seaver tsea...@palladion.com: The main export of the package is the 'sort' function, which takes a sequence, per-column sort specs (key/attr name, sort function, direction), and optional extra data (e.g., the DTML namespace) and a flag indicating whether to use key or attribute lookup. The 'SortBy' class is really just an implementation detail of that API. I guess the right way to port the package is to implement a sort API. I have ported it to Python 3.2 and 3.3 and released a 4.0.0 version. Thanks for the port. I guess the question is still whether it should still be in ZTK - providing DTML as an example suggests that this really is a Zope only library. Do you see use for it outside the Zope context? 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Error suitable python version
Hi Peppe, although I don't think your issue is related to the development of Zope, if you don't keep this on mailing list no one else will see any possible issues- Am 07.12.2012, 19:25 Uhr, schrieb peppe scuglia peppe...@gmail.com: Hi When i try to install with Bin/easy_install -i http://download.zope.org/Zope2.2.13.19 Zope2 Why on earth are you do want to do that? bin/pip install Zope2 works fine. Note, unless you have a clear idea of exactly what you want to do it's unusual to install Zope directly like that and Zope is a little too big just to try out. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Error suitable python version
Hi Peppe, Am 06.12.2012, 16:58 Uhr, schrieb peppe scuglia peppe...@gmail.com: Hi I use python 2.6.6 but i dont know why there is an error when i try to install zope 2.8.2 or zope 3.4.0 using Linux. It find the interpreter of python 2.6.6 in usr/bin/python , but when i make .configure --with-python /usr/bin/python , there is an error no suitable python version found. You should install Python version 2.4.3 before continuing. Versions 2.4.7 etc... I read that this version of python 2.6.6 run on zope 2.8.2 or 3.4.0 Please help me!! What have i do?? You cannot use Python 2.6 with Zope 2.12. Zope 2.8 is no longer 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Error suitable python version
Am 06.12.2012, 17:14 Uhr, schrieb peppe scuglia peppe...@gmail.com: What version of zope you recommends for python 2.6.6? Thanks again for your disponibility The current version of Zope is 2.13.19 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-CMF] Weird UnicodeDecodeError with zope.formlib
Am 30.11.2012, 18:21 Uhr, schrieb Charlie Clark
charlie.cl...@clark-consulting.eu:
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-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-CMF] Weird UnicodeDecodeError with zope.formlib
Am 30.11.2012, 18:21 Uhr, schrieb Charlie Clark
charlie.cl...@clark-consulting.eu:
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-dev] Fwd: Re: [Zope-CMF] Weird UnicodeDecodeError with zope.formlib
Am 30.11.2012, 08:29 Uhr, schrieb Adam GROSZER agroszer...@gmail.com: I think I had the same. My hunch was IE, but had no repro. If you *have* a repro, you could log the *whole* raw request input and investigate what's the difference. Hi Adam, this is different from the usual IE Safari shenanigans which were related to the accept_charset not being sent and Zope making a bad guess. I can reproduce the error without difficulty in Opera. I'm going to try a new instance of the site and see how that behaves. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Fwd: Re: [Zope-CMF] Weird UnicodeDecodeError with zope.formlib
Am 30.11.2012, 09:37 Uhr, schrieb Adam GROSZER agroszer...@gmail.com: Opera? which version and OS and whatnot? 12.12 on Mac OS 10.7.5 As originally noted, I don't have the problem in the same browser with an extremely similar form on a different site. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-CMF] Weird UnicodeDecodeError with zope.formlib
Am 30.11.2012, 18:14 Uhr, schrieb Patrick Gerken patrick.ger...@computer.org: 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
[Zope-dev] Fwd: Re: [Zope-CMF] Weird UnicodeDecodeError with zope.formlib
I'm forwarding this from the CMF list as I'm stumped. I worked my way up the debug stack but couldn't find what was causing one Zope instance to decode to unicode and the other to leave content as utf-8 (or maybe it's the other way round?). Both instances on the same machine. Any ideas? Charlie --- Weitergeleitete Nachricht --- Von: Charlie Clark charlie.cl...@clark-consulting.eu An: zope-...@zope.org Kopie: Betreff: Re: [Zope-CMF] Weird UnicodeDecodeError with zope.formlib Datum: Thu, 29 Nov 2012 11:52:13 +0100 Am 29.11.2012, 09:43 Uhr, schrieb Charlie Clark charlie.cl...@clark-consulting.eu: 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-CMF] Weird UnicodeDecodeError with zope.formlib
Hiya Patrick, Am 29.11.2012, 00:12 Uhr, schrieb Patrick Gerken patrick.ger...@computer.org: With the information you provided I'd first try this on a python prompt on a working machine : Köln == uBonn Köln == uBonn 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
Re: [Zope-CMF] Weird UnicodeDecodeError with zope.formlib
Am 29.11.2012, 09:43 Uhr, schrieb Charlie Clark charlie.cl...@clark-consulting.eu: 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-dev] Small fix in Products.ZCTextIndex, how to go further?
Am 14.11.2012, 16:26 Uhr, schrieb Hanno Schlichting ha...@hannosch.eu: Hi. The change looks ok. But I think you broke an optimization. IIRC the code compares the old and new values for the index, and skips the indexing step if they are the same. The typical item.reindexObject() call sents data for all indexes, even if just one or two them have changed. The optimization made sure to skip any extra work, if there wasn't really any change for the text index. Without that check, you end up updating and writing a bunch of internal data structures in the text index every time. Those lead to slower write performance and more conflict errors. Could you have another look, and see if you can preserve the optimization? Could we also have a clean up with a specific exception in the try: except: clause? I assume we're expecting an AttributeError? And move filter to a generator expression / list comprehension? I could say for Python 3 compatibility but that doesn't matter so much as there is no easy way for the isinstance(t, basestring) 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-CMF] CMF security patches in Products.PloneHotfix20121106
Am 09.11.2012, 17:02 Uhr, schrieb Jens Vagelpohl j...@dataflake.org: 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-dev] Zope 4 Sprint Report [was: (no subject)]
Am 10.09.2012, 21:54 Uhr, schrieb Leonardo Rochael Almeida leoroch...@gmail.com: The expectation is to be able to release a Zope4 alpha by the end of the year. Next sprint will be at the Plone Conference in Arnhem, focussing on WSGI and merging branches. Hi Leonardo, thank you very much for the report. It's nice to see that ideas for Zope's future are crystallising. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-CMF] Security declarations on adapters
Hi Yuppie, Am 07.09.2012, 09:01 Uhr, schrieb yuppie y.2...@wcm-solutions.de: [-] 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 06.09.2012, 13:11 Uhr, schrieb yuppie y.2...@wcm-solutions.de: 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
Hiya Laurence, Am 06.09.2012, 14:46 Uhr, schrieb Laurence Rowe l...@lrowe.co.uk: 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, 16:24 Uhr, schrieb yuppie y.2...@wcm-solutions.de: 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
I always like the solipsism of replying to myself! ;-) Am 06.09.2012, 16:58 Uhr, schrieb Charlie Clark charlie.cl...@clark-consulting.eu: 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] [dev] tools as utilities
Am 05.09.2012, 11:48 Uhr, schrieb yuppie y.2...@wcm-solutions.de: 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
Re: [Zope-CMF] [dev] tools as utilities
Am 05.09.2012, 15:36 Uhr, schrieb yuppie y.2...@wcm-solutions.de: - 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, 15:05 Uhr, schrieb Lennart Regebro rege...@gmail.com: 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, 16:00 Uhr, schrieb Lennart Regebro rege...@gmail.com: 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
[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-dev] We need to change how code ownership works.
Am 20.08.2012, 11:09 Uhr, schrieb Lennart Regebro rege...@gmail.com: Such as? As previously noted: the TC's in particular the indemnification clause. Plus, the usual when dealing with an apparently free service provided by a company beholden to VC's. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] We need to change how code ownership works.
Am 20.08.2012, 12:50 Uhr, schrieb Robert Niederreiter r...@squarewave.at: On 20.08.2012 12:39, Charlie Clark wrote: Am 20.08.2012, 12:27 Uhr, schrieb Robert Niederreiter r...@squarewave.at: There are lots of very famous os projects hostet on github - which - without any doubt raises the reputation of github itself. ah, the common cold defence: everyone has it so it must be good. no, just a manner of chance. and even if, git is not proprietary. Git is the tool and not the service. https://github.com/popular/starred i doubt that github i willing to get into the doghouse by doing really nasty things - and thus getting into risk of loosing projects. This is pure speculation, or are you privy to board decisions at Github. see above, git is not proprietary. nobody is trapped inside github at all if nasty things happen. Changes to the TC's that substantially affect this can happen at any time. lots of you also use gmail, g+ or other stuff, where i have more concerns about abuse than at github... This irrelevant in the context of ownership and copyright. you came up with concerns against VC's. So in which context was this meant then? Without wanting to start a diatribe against VC's: the key term was beholden to. VC's are understandably interested in a quick and substantial return on their investment and will do whatever it takes to achieve that. They are not philanthropists and ownership is a key lever for them. This is a fundamentally different proposition to paying for a service from a company or setting up an organisation to do it yourself. There is no free lunch. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
Am 18.08.2012, 15:35 Uhr, schrieb Chris Withers ch...@simplistix.co.uk: I'm not going to dignify this with a fuller response other than to say that Jean-Paul Smets' entire email is nothing but bullshit written to try and promote an inferior competing product. The issues of hosting and vcs were aired a few months ago and should be considered separately. The TC's of any of the these products should be read carefully and I, for one, do not like the indemnification clause at Github. I would, therefore, agree with Jean-Paul in this respect. I agree with Jens, that new work should be considered as a fork. It currently feels very much cloak dagger. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope trunk: browser views
Am 10.07.2012, 16:29 Uhr, schrieb yuppie y.2...@wcm-solutions.de: Hi! Zope 2 has customized implementations of the ``browser:view`` and ``browser:page`` directives. I tried to make that code more similar to zope.browserpage without breaking Zope 2 and CMF. I guess the biggest change I made was removing the Five version of BrowserView from the base classes. Please let me know if you have any questions or if I did break something. Hi Yuppie, I'm sure that's going to break any code that has from Products.Five import BrowserView in it. What should this be replaced by? And what changes in ZCML? Most of my code sits upon CMF so I hope I should be reasonably insulated through that. But the change is probably a good thing™ so thanks in advance. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Add zmi_views 'fix' also for zope.app packages?
Hi Uli, Am 29.05.2012, 13:44 Uhr, schrieb Uli Fouquet u...@gnufix.de: Hi there, As Christopher Lozinski pointed out, there seem to be usecases where people want to use single zope.app packages without zope.app.zcmlfiles and the whole bunch of zope.app packages it pulls in. I think this is a non-usecase. zope.app is a namespace for the app part of Zope. If you want to use a part of this app then it's reasonable to assume that you want the rest: caveat developor! Would it make sense for these packages to also register ZMI related stuff only if some condition is met (say: zope.app.zcmlfiles is installed)? No, having apps trying to guess about their use as library code is a bad idea and should not be encouraged. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-CMF] cmf-tests - OK: 2, UNKNOWN: 2
Am 11.04.2012, 16:03 Uhr, schrieb yuppie y.2...@wcm-solutions.de: 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
Am 11.04.2012, 17:06 Uhr, schrieb Charlie Clark charlie.cl...@clark-consulting.eu: 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-dev] Merge proposal: zope.interface/branches/tseaver-no_2to3
Am 05.04.2012, 22:36 Uhr, schrieb Tres Seaver tsea...@palladion.com: Unless the community's consensus is against the branch, I plan to merge it to the zope.interface trunk by early next week. + many/lots! 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-CMF] 2.3
Hi Jens, Am 05.04.2012, 17:35 Uhr, schrieb Jens Vagelpohl j...@dataflake.org: 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
Hi Yuppie, Am 03.04.2012, 14:11 Uhr, schrieb yuppie y.2...@wcm-solutions.de: +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-dev] Content Type Meta tag stripping in zope.pagetemplate
Am 25.02.2012, 00:18 Uhr, schrieb Marius Gedminas mar...@gedmin.as: The HTML spec requires that: To sum up, conforming user agents must observe the following priorities when determining a document's character encoding (from highest priority to lowest): 1. An HTTP charset parameter in a Content-Type field. 2. A META declaration with http-equiv set to Content-Type and a value set for charset. 3. The charset attribute set on an element that designates an external resource. -- http://www.w3.org/TR/html4/charset.html#h-5.2.2 (Aside: The rationale for this ordering, IIRC, is that it allows HTTP servers to do on-the-fly charset conversion from one 8-bit charset to a different one, without having to parse HTML and modify the charset name in the meta declaration.) As a follow up to this it's worth noting that as from Opera 12 the practice will be: * BOM sniffing * http header * meta declaration In that order and inline with Webkit and IE: It is better to encode your Web pages in UTF-8, and serve them as such. In HTTP, the HTTP header has priority, then the meta name contained in HTML. Some Web pages have specific encoding. It happens often on the Web that the Web page encoding is different from the one specified in the file and/or the one specified in HTTP headers. It creates issues for users who receive unreadable characters on their screens. So the browsers have to fix the encoding on the fly. We had bug reports about Web sites sending BOM different from the HTTP header. We decided to make the BOM authoritative like webkit and IE, because there are more chances for it to be exact than the HTTP headers. http://my.opera.com/ODIN/blog/2012/03/26/whats-new-in-opera-development-snapshots-march-26-2012 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Content Type Meta tag stripping in zope.pagetemplate
Am 27.03.2012, 12:16 Uhr, schrieb Fred Drake f...@fdrake.net: In other words... the web will continue to thrive on hacks and sniffing data to support users' expectations in spite of the data on the web. I appreciate the motivation (it's not the users' fault the content provider can't get it right), it saddens me that there will no end of quirks-mode-like data interpretation. And that after this many years, we still can't get content-type and encodings straightened out. True but I think that the problem was largely of our own making in not coming up with one, preferably only one way of handling this. Re-reading Marius' post I was struck by the whole idea of the http-server transcoding the content on the fly. Now, I've never looked at this in detail but have any of the major webservers ever done that? Having struggled in the past with weird encoding errors limited to Safari and IE only, probably caused by me not handling the encode/decode chain properly in my code but still left staring unbelievingly at a long and confusing traceback and yearning for an easy to way to do the right thing which in my view should be the webserver trying to serve up UTF-8. I guess, that years ago we had to worry much more about encodings (latin-1, windows-1252, mac-roman, IBM code pages, and whatever unix was doing). I've been reading about http 2.0 coming up - is this going to improve the matter? 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Content Type Meta tag stripping in zope.pagetemplate
Am 27.03.2012, 16:04 Uhr, schrieb Fred Drake f...@fdrake.net: Transcoding on the fly? The page template generates Unicode; that's then encoded. Are you suggesting we shouldn't be using Unicode as the internal representation? Not at all, just harking back to the time when we didn't use unicode internally. In the CMF we still have to deal with that on occasion. Failure to do so would make it easy to get things wrong. Indeed. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] New release for zope.schema
Am 22.03.2012, 15:27 Uhr, schrieb Jan-Carel Brand li...@opkode.com: Any ideas why this vocabulary doesn't provide it in Python 3? I think you have to use the @implements class decorator for Python 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-CMF] 2.3
Am 21.03.2012, 22:58 Uhr, schrieb Jens Vagelpohl j...@dataflake.org: 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: (InterfaceClass 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 22.03.2012, 13:42 Uhr, schrieb Charlie Clark charlie.cl...@clark-consulting.eu: 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:46 Uhr, schrieb Jens Vagelpohl j...@dataflake.org: 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 21.03.2012, 16:47 Uhr, schrieb Jens Vagelpohl j...@dataflake.org: 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
[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-dev] Content Type Meta tag stripping in zope.pagetemplate
Am 24.02.2012, 09:47 Uhr, schrieb Miano Njoka mianonj...@gmail.com: While it is not essential, it is necessary in some cases where the finished document will be read from disk or is used by other applications eg. Deliverance[http://packages.python.org/Deliverance/]. In fact w3c's HTML validator throws a warning that one should declare the character encoding in the document itself if it is missing. This is actually what the validator says: No character encoding information was found within the document, either in an HTML meta element or an XML declaration. It is often recommended to declare the character encoding in the document itself, especially if there is a chance that the document will be read from or saved to disk, CD, etc. As ZPT produces XHTML the proper place for any encoding declaration is in the XML declaration, defaulting to UTF-8, which should throw a validation error if incorrect. Like much of the HTML standard the meta tags were never really thought through and, because invisible to the user, all too often copied mindlessly from one project to another: I have customers today with completely invalid and misleading meta tags of which they and the rest of the world is blissfully unware. And as a result browsers - the main consumers of the format were made fault tolerant - after all the user often had no idea what was causing the problem or how to rectify it. I have seen many examples of the server saying one think and the meta something else entirely. I think nearly all browsers believe what the server says over what's in the meta tag. According to MAMA, which was instrumental in developing HTML 5 based on what has actually been written, the charset was set in the http-headersover 99 % of the time. Unfortunately, it doesn't contain any stats on discrepancies between the http-header and the meta. http://dev.opera.com/articles/view/mama While there is apparently a possible security risk when not declaring the charset I think the Pythonic principle of there should be preferably one obvious way to do something should apply when within Zope trying to decide the charset of a file and that should be well documented. I'd suggest keeping the stripping but implementing a more rigorous approach such as you suggest. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] TreeVocabulary in zope.schema.vocabulary
Hiya, ... lots cut ... I like the _populateIndexes() method. Having a single pass without a signifying parameter makes it easier to understand. Am 06.02.2012, 10:12 Uhr, schrieb Jan-Carel Brand li...@opkode.com: A vocabulary must minimally be able to determine whether it contains a value, to create a term object for a value, and to return a query interface (or None) to find items in itself. So it looks like someone thinks that any vocabulary must be able to create a term object. Thoughts on that? Yes: I think it's much more important to define what kind of terms are expected. Apart from local utilities I've never come across the need to add terms individually and even then term generation is outside the scope of the vocabulary as you already have a term factory. Validating terms seems more important so I guess and __setitem__() method which imposes the same checks as you run in _populateIndexes() might be worthwhile to stop the index being fouled up by application code. I think I'm now finished and have implemented everybody's suggestions and improvements. The TreeVocabulary now has a terms_factory attribute which is an OrderedDict by default and which can be overridden in a subclass to an alternative datastructure. It also implements IEnumerableMapping. All the TreeVocabulary methods are covered by tests and I tested with Python 2.6 and Python 2.7. If there aren't any more objections, I'd like to now merge with trunk. I think it's okay to go ahead and merge. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-CMF] cmf-tests - OK: 3, UNKNOWN: 1
Hi Tres, Am 08.02.2012, 21:36 Uhr, schrieb Tres Seaver tsea...@palladion.com: 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
Re: [Zope-dev] Zope 4 release management
Am 01.02.2012, 15:40 Uhr, schrieb Alexandre Garel alex.ga...@tarentis.com: All I see here is usability not religion Which is pretty much what Jens said originally. To me, much of the argument seems to be trying to solve a different problem: getting more people involved in contributing to Zope or at least maintaining important packages. While this is a laudable goal I think it is has little to do with the tools involved, something that is becomingly increasingly irrelevant as more and more third-party packages are used in Zope projects; something which Zope did a great deal to encourage. Currently the hurdle to getting involved is signing and sending the committer agreement. A hurdle which I think is worth keeping. On hosting: personally, it does matter to me a great deal where the little code I write is hosted. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] PyConUS sprint on Zope 4
Am 29.01.2012, 22:29 Uhr, schrieb Leonardo Rochael Almeida leoroch...@gmail.com: Hi, Anyone going to this PyConUS who would like to sprint on Zope4? Topics of particular interest to me include security (as I explained in a previous e-mail) and the new ZMI. Hiya, I'm certainly staying for the sprints. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] TreeVocabulary in zope.schema.vocabulary
Hiya, Am 30.01.2012, 14:33 Uhr, schrieb Jan-Carel Brand li...@opkode.com: ... lots cut ... Yes, the values must be unique, because we do value lookups. The title attr doesn't have to be unique though. You could have a Forestry department for two different regions. The title will be the same, but the value and token attrs can't. I think the tests should be extended to show that this also includes nesting because this is non-obvious. ie. I believe that the region Izmir is within the state of Izimir in Turkey. This should be possible by calling _getPathToTreeNode during one of the passes through _flattenTree. getTermPath would then just need to do a lookup on this. I don't like the way the path_node gets implicitly populated during a call to _flattenTree. hm, okay. Personally, I think you should be able to populate your dictionaries with only a single pass through the terms. However, as this only needs to happen when the application starts we don't need to worry too much about the performance. I'd rather have a separate method that calculates the path and then explicitly assign it to self.path_node. In any case, there is now a node_index in the code snip but I don't see the advantage of cls.createTerm(*args) over SimpleTerm(*args) See above. createTerm is there to let developers override it and provide their own term objects. Do you have a concrete use case for this? Not really, but that doesn't mean it doesn't exist. Then someone will speak up for it if they need it or do their own subclassing/composition as required. Otherwise it's just food for warts. Remember that createTerm is a convenience method only. Frankly, I don't see the need for it in what is a fairly specialised class. I like consistency and symmetry, so if SimpleVocabulary has it, as an add-on developer I'd expect for TreeVocabulary to also have it. I don't however feel very strongly about it though, and I wanna get this done, so I removed it. Well, we could always think about removing it from SimpleVocabulary: it's not in the interface so no subclass actually has the right to depend on 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] TreeVocabulary in zope.schema.vocabulary
Hiya, Am 26.01.2012, 15:02 Uhr, schrieb Jan-Carel Brand li...@opkode.com: Ok, Charlie also expressed his reservations. I'll put it in a different package then. Hang on a minute! While I'm not 100 % convinced of the need in the core I think a separate package just for TreeVocabulary would be splitting hairs. If z3c.form can use it then I think that is justification enough. I'm not too sure what to name it though. For example, under what namespace? zope or z3c? I'm guessing zope.vocabulary, or rather zope.treevocabulary? Furthermore, for the dict class in use in the vocabulary, you could add a factory class that can be overriden easily. That would allow people with OrderDict capabilities to use them without having to re-sort later on. Could you please elaborate on what you mean? If I create a factory class to create TreeVocabulary instances, how will overriding that factory (without creating a separate SortableTreeVocabulary) allow people to use OrderedDict? Incidentally, I came upon this: http://pypi.python.org/pypi/ordereddict which provides the OrderedDict to Python 2.4 to 2.7 I think it might make sense to just subclass OrderedDict and implement an ordered tree from the start. I agree. Despite my previous remark about class methods, I don't think we need to worry much about Python 2.4 and 2.5 and ordered dictionaries are just so damn useful that they've been added to the standard library. Back to bike-shedding. As I was intrigued by the whole thing I've spent some time looking at the code. I'm not too happy on the use of nested functions as I find they obscure code, particularly when used recursively. I think that createTree and recurse should be written as separately testable generators. I also don't see a need for createTerm in this particular class and the subsequent awkward call from createTree. As it stands it is copy paste both in method and test. If you must have it with the same implementation createTree = SimpleVocabulary.createTree does the job just fine but I don't see the advantage of cls.createTerm(*args) over SimpleTerm(*args) As I said this is bike-shedding but I think our source code should be written with a view to being read and probably copied verbatim. With that in mind I prefer readability and testability over integration. In the end it tends to make things easier to use. The exceptions where refactoring to produce slightly uglier code but with significant performance hopefully prove the rule. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] TreeVocabulary in zope.schema.vocabulary
Hiya, Am 24.01.2012, 18:48 Uhr, schrieb Jan-Carel Brand li...@opkode.com: I've clarified some of the docstrings and added the missing one. None have doctests, perhaps you are referring to fromDict, which gives an example dict to show the required structure. I guess that could easily be turned into a doctest, I'll look into it. No need to add doctests. It was more a comment on the docstring of one method in comparison with the others. It would be nice to expand the README here. I don't see anything about vocabs there at all, but I'm willing to add some tests. er, just because the existing documentation is pants doesn't mean it can't be improved upon! ;-) I'm still not sure about having TreeVocabulary in zope.schema if it is only going to be used with, shudder, Archetypes. On the one hand schema are theoretically dissociated from any form library and zope.form is already incomplete, on the other we try and avoid application-specific requirements in the libraries. All the more important to expand the documentation so that other libraries can benefit from the plumbing. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] TreeVocabulary in zope.schema.vocabulary
Hiya, Am 24.01.2012, 12:35 Uhr, schrieb Jan-Carel Brand li...@opkode.com: Perhaps I should rephrase I would like my changes to be merged with the zope.schema trunk. The tests I've added provide 100% coverage of the TreeVocabulary code. I've only glanced cursorily at the source but I'm not sure that a merge is okay yet. At least not all of the methods have doc strings and one of them seems to have a doctest. It would be nice to expand the README here. getTerm is a copy of the SimpleVocabulary method. Using the @classmethod decorator is fine but inconsistent with other vocabulary classes. Using the decorator is more readable so I'd suggest changing all relevant methods to do that. Off the top of my head I don't know which Python versions support classmethods. That should be checked in case zope.schema is in a ZTK that is running on Python 2.4 I would just like someone to sign it off. Should I rather create a ticket on launchpad? Or otherwise, should I just go ahead and merge the changes to trunk? I would suggest going via launchpad if only because it is a better paper trail. At the moment I'm still not quite sure whether this is required in zope.schema. Do widgets only exist for z3c.form? 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.intid and zope.keyreference.interfaces.NotYet exception (patch)
Hiya, Am 23.01.2012, 23:20 Uhr, schrieb Cykooz cyk...@googlemail.com: Oh ... Or there is no one who is engaged in package zope.intid, or no one gets an NotYet exception on the fault this package. Who can give me write access into SVN for the package zope.intid? You must apply to the Zope Foundation for access to the repository. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] merge zope.configuration dictactions branch
Hi Chris,
Am 05.12.2011, 04:02 Uhr, schrieb Chris McDonough chr...@plope.com:
On the zope.configuration trunk (and in all past releases), each ZCML
action is maintained as a tuple. The tuple can be of any length up to
seven elements, but mustn't exceed a length of seven. A complex system
of lengthening and shortening (in
zope.configuration.config.resolveConflicts) tries to ensure that the
tuple is of the smallest length required by chopping false elements off
the end of each action tuple during storage and reconstituting them to
7-element tuples during processing and sorting. I think this juke was
purely to make doctests easier to write, but I'm not entirely sure.
eek! I'm sure there was a better reason for this in the first place. As
things stand ZCML declarations are not orthogonal so a key-based approach
seems the better fit.
Up til now, pyramid_zcml could live with actions being at most 7
elements. But recent changes to the Pyramid trunk (adding
introspectables) blew out the presumption that an action tuple could
be no longer than 7 elements (it now might need to be 8 elements).
Rather than extend the structure of the zope.configuration tuple with a
Pyramid-only introspectables argument, I've created the
chrism-dictactions branch
(http://svn.zope.org/zope.configuration/branches/chrism-dictactions/)
which changes ZCML action structures to be dictionaries. This allows
each action to contain arbitrary keys. This modification satisfies the
immediate requirement (adding introspectables) and allows us to never
need to change the zope.config code again if more elements need to be
added to actions.
+1 as all ZTK test pass.
I could have instead added an extras dictionary on to the end of the
tuple as an 8th element, but it seems six of one a half dozen of
another, and the z.config code is much easier to understand when the
action is just a dictionary instead of a pseudo-struct.
I'm trying to think of where I've seen that pattern of {'organised'
'others':{}} before... oh, yes in dodgy RDBMS schema.
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-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Supporting interworking with repository branches on github
Hi Laurence, Am 22.11.2011, 18:13 Uhr, schrieb Laurence Rowe l...@lrowe.co.uk: While the Zope Foundation deliberates on version control, What's this about the Zope Foundation deliberating, why don't you just say prevaricating?, on version control? I thought Tres presented a cogent argument for maintaining the status quo and stick with svn. I think it's likely that development will continue using Git and Github. Sounds like a self-fulfilling prophecy. FWIW the STD justification for something (everyone else has got syphilis so I want it, too.) is never a good one. Enough of the linguistic shilly-shallying. I do think that we need something like PIPs or PLIPs for Zope 4 (jokingly referred to as ZIPs in one of my recent posts) to work through some of the suggestions that have been made. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-CMF] Fwd: [Zope-dev] Products.CMFUid runtime issue
Am 28.09.2011, 16:38 Uhr, schrieb Charlie Clark charlie.cl...@clark-consulting.eu: Am 27.09.2011, 23:41 Uhr, schrieb Charlie Clark charlie.cl...@clark-consulting.eu: 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-dev] Revert removal of ++skin++ in Zope4?
Hi Lennart, I'm not sure if you're not mixing different issues here. Am 17.11.2011, 11:35 Uhr, schrieb Lennart Regebro rege...@gmail.com: Absolutely. Getting rid of CMFSkins is a part of getting rid of CMF, not a part of moving to Zope 4. Different issues. I assume you are referring to removing Plone's dependencies on CMF. That is not relevant to the discussion about Zope 4 / ZMI reimagined. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Revert removal of ++skin++ in Zope4?
Am 16.11.2011, 12:49 Uhr, schrieb Lennart Regebro rege...@gmail.com: Right. Could we standardize on skins or browserlayers plz? Having both confuses the heck out of me. Definitely a topic that needs (re)-opening. From a CMF point of I think we're just about at the point where we could switch to browser layers, well, at least once CMF 2.3 has been released. But I think that CMF Skins still offer some functionality that you don't get with browser layers out of the box. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Revert removal of ++skin++ in Zope4?
Am 16.11.2011, 15:15 Uhr, schrieb Christian Theune c...@gocept.com: But they also have their merits. If I could make a wish, I'd like to see a shared implementation that marries all the benefits. Something I love a lot is the ++skin++ traverser for example. I also like the idea of tagging the Request object with structured information (an interface) to indicate specialisation. I hate that I have to spell the layer in each ZCML statement. Smells like a ZIP to 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-CMF] [dev] working on the trunk
Am 04.10.2011, 10:55 Uhr, schrieb yuppie y.2...@wcm-solutions.de: 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 05.10.2011, 15:26 Uhr, schrieb yuppie y.2...@wcm-solutions.de: 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 30.09.2011, 22:29 Uhr, schrieb Tres Seaver tsea...@palladion.com: 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
Hiya yuppie, Am 30.09.2011, 10:55 Uhr, schrieb yuppie y.2...@wcm-solutions.de: 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 y.2...@wcm-solutions.de:
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
[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] [dev] working on the trunk
Am 27.01.2011, 17:05 Uhr, schrieb yuppie y.2...@wcm-solutions.de: 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] Fwd: [Zope-dev] Products.CMFUid runtime issue
Am 25.09.2011, 11:04 Uhr, schrieb Ruslan Mahmatkhanov cvs-...@yandex.ru: 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-dev] access to create z.i and z.c releases
Am 23.09.2011, 09:36 Uhr, schrieb Chris Withers ch...@simplistix.co.uk: t tried zope.interface 3.8.0 on MacOS X Lion and got: Oh you brave boy! Given what Apple managed with Snow Leopard I've held off Lion so far and I always use the MacPorts toolchain. Works fine on Snow Leopard and builds with gcc-4.2 here. Maybe your Python was built with 4.0 or has some unrecognisable architecture flags? 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Products.CMFUid runtime issue
Am 23.09.2011, 09:44 Uhr, schrieb Ruslan Mahmatkhanov cvs-...@yandex.ru: Patches are here: https://github.com/mexicarne/zope/commit/1398afc68dd412d5dbe84f5fd5eadf0ae7a18c24 Please consider to commit. I think CMFUid is still part of the CMF so this should really be directed to that list. Going by the current tests we're not yet up to Python 2.7 so it could be an incompatibility with that. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Passing variable across pages
Am 21.09.2011, 16:24 Uhr, schrieb Joshua Immanuel j...@hipro.co.in: After seeing this mail, I've started to think whether I should stop cross posting in my future mails and which mailing list should I single out. Please advice. Dear Joshua, cross-posting is generally unwelcome on any mailing list except for the purpose of announcements. While this list is primarily about the development of Zope, polite requests about real world applications are generally accepted assuming they are related to Zope or the ZTK. However, simply asking I have this problem, how do I solve it questions, and Bablyak's definitely fall into this category, are not in the spirit of the list. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
Am 26.08.2011, 09:51 Uhr, schrieb Wolfgang Schnerring w...@gocept.com: However, what's important to me is that we try to make packages cohesive, and that we try to make integration between packages understandable. The current zope.component, because it came out of the Zope3 monolith, contains integration bits to various other Zope packages: - zope.event - zope.security - zope.configuration - ZODB In that light, it makes a lot of sense to me to have two (or more?) packages, core and integration, but I'd *very* much like them to be named in a way that one can tell this fact from their names. What remains is the issue that zope.component *also* contains code for the thread-local site concept -- which doesn't feel like an integration with another package, but might not be considered core functionality, either (I'm not sure yet but I lean towards considering it core). Wolfgang, I think that what you suggest is too much for the moment and I think it even contains the Zope 3 risk of trying to get everything right. I have the feeling that getting things right is going to take a lot more head-scratching and beard-pulling! Tres' proposal has the not inconsiderable advantage of merging work already done. You are right to point out inconsistencies and warts but against that should be weighed the possibility of making a port to Python 3.x a real possibility. And, given that the work has come from an external if related project, the main aim of exposing these libraries to the wider world has been achieved. So from +1 for Tres proposal and +1 for a roadmap on this. Regarding Withers suggestion - should we be looking to move these libraries to the WSGI namespace? Or are there real use cases outside the web world? 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] web sites are keep crashing
Am 26.08.2011, 15:27 Uhr, schrieb Babylakshmi Muthusamy babylakshmim...@gmail.com: Hi AJ, I have moved one of the site's database from ZODB to mysql. Should I have to change any of the configuration? Hi Babylakshimani, that change has nothing to do with the problem. Does your Zope-user have access to files in /usr/local/zope/PPD/architecture/domains/ BTW. as you say you are new to Zope, what documentation have you been given. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] getting size of zope.schema.List from a view in bluebream
Am 23.08.2011, 13:34 Uhr, schrieb Joshua Immanuel j...@hipro.co.in:
This solves just the '__len__' issue. But if do the slice operation like
this
self.context.list_field[offset:limit]
I get the following error
ForbiddenAttribute: ('__getslice__',[...])
I guess my approach is flawed. Implementing all the functionality (like
the one I did for length) that a list provides is a overkill. So, please
guide me in this regard.
Joshua,
I think it's really difficult to work out what you are trying to do.
Please state your problem more clearly. Are you still using zope.form or
are you using z3c.form?
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-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-CMF] cmf-tests - OK: 3, UNKNOWN: 1
Am 23.08.2011, 07:00 Uhr, schrieb CMF tests summarizer nore...@zope.org: [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-dev] [BlueBream] disabling zope.schema constraint check in edit form
Am 18.08.2011, 13:19 Uhr, schrieb Joshua Immanuel j...@hipro.co.in: Yes. But considering the fact that I am doing this check at the interface level. I wonder if that is ever possible, because the constraint method knows just the value of the field. You can always go from the field to the object to which it is bound. Not sure if your constraint is actually the best way to go. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-CMF] cmf-tests - OK: 3, UNKNOWN: 1
Am 07.08.2011, 20:45 Uhr, schrieb Hanno Schlichting ha...@hannosch.eu: 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-dev] direction
Am 05.07.2011, 14:44 Uhr, schrieb Jens Vagelpohl j...@dataflake.org: zopefour as a domain isn't very helpful. It would add yet another top-level name to the existing list (Zope 2, Zope 3). In the best of all possible worlds the package now known as Zope2 would simply be Zope, and its website is at www.zope.org. Zope is making the jump from version 2.x to 4.0. +1 Logically Zope 2.12 would have been a major release due to eggification and dropping Python 2.4. Only makes sense to make label the next major version as such rather than pretending with 2.x that only minor changes are being made. As I've been able to do little or no development this year thanks to Leonardo for raising this and Hanno for his explanation. I do think a public roadmap, with opportunities for people wanting to get involved would be a good idea. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. updating catalog indexes in bluebream
Am 23.06.2011, 14:43 Uhr, schrieb Joshua Immanuel j...@hipro.co.in: I guess that I don't have to manually update the indexes each time when an object is added/modified. Am I missing something? The indices do have to be updated every time you add, delete or modify an object. This is one of the reasons for the event system you were asking about the other week. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] component registry navelgazing
Hiya, Am 12.06.2011, 22:48 Uhr, schrieb Chris McDonough chr...@plope.com: from zope.component.registry import Components c = Components() from zope.interface import Interface, implements class IFoo(Interface): pass ... class Foo(object): ... implements(IFoo) ... foo = Foo() c.queryAdapter(IFoo, foo) None In order to get the object itself back from such an adaptation, you need to use the default= argument. I know that the question has been answered but your question makes me ask another: why would you want to adapt an object with itself? 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] component registry navelgazing
Am 13.06.2011, 17:01 Uhr, schrieb Chris Withers ch...@simplistix.co.uk: I have something, I want something that implements IWhatever. Now, it may well be that something implements IWhatever, but it may also not. As the author of the code in question, I don't want to have to care. Other authors can plug in adapters for the cases where something doesn't implement IWhatever I can appreciate the use case but not the semantics - you are not looking for an adapter but an implementation. I guess this is related to the IWhatever(object) approach which does the magic for you. I guess queryProvider(object, interface) would be a better spelling for that use case, which may be more general than I'm suggesting. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. persisting data in ZODB via forms
Hi Joshua, Am 08.06.2011, 10:34 Uhr, schrieb Joshua Immanuel j...@hipro.co.in: Hello all, I am using zope.formlib.form package for my forms, when overriding the 'createAndAdd' method of form.AddForm I don't explicitly do the zope.event.notify(ObjectCreatedEvent(..)) call. I just add the data to self.context and it gets added (persisted) in the ZODB. Persistence is handled by the transaction management and is IIRC independent of the notifications system. Nevertheless, not calling the events is not advisable. But when I extend the form.EditForm in order to implement my own Apply action method, just calling the form.applyData or form.applyChanges doesn't persist the data. zope.event.notify(ObjectModifiedEvent(..)) call is needed in order to persist data. If someone could explain on this or point me to some documentation relating to this would be very helpful to me. From memory I can recall something similar related to making changes to copies of instance attributes but failing to apply them to attributes and needing to specifically go context.attribute = form_result for the changes to persist. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. persisting data in ZODB via forms
Hi Joe,
Am 08.06.2011, 11:05 Uhr, schrieb Joe Steeve j...@hipro.co.in:
Supposing, we have a form action like:
@form.action('Apply')
def handle_edit(self, action, data):
self.context.name += Blah
This change is visible in subsequent requests. i.e if we view this
object via another form, we can see the modification. However, if we
restart the server (bluebream), this change is lost. The same thing
happens when we use form.applyData. If we 'notify'
ObjectModifiedEvent, this does not happen.
Since the object's modification is visible across requests, I am
assuming that the transaction mechanism 'did' apply the changes to the
object.
But, it did not get to the disk :-/
I'm surprised at this but I'm not familiar with Bluebream's transactional
processing. The quickest thing to do is to reenable notification and add a
debug so that you can follow all the subscription calls and see what you
need to call.
Why do want to disable notification?
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-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. persisting data in ZODB via forms
Am 08.06.2011, 11:31 Uhr, schrieb Joe Steeve j...@hipro.co.in: How do we get the list of subscribers for a particular event? By checking the registry for all adapters registered. from zope.component import queryAdapter queryAdapter(object, interface) ... # check the syntax and make sure you have the registry loaded. Why do want to disable notification? We dont want to disable notification. We are just trying to understand how zope.formlib works. We were of the understanding that every 'request' starts and ends a transaction automatically (somewhere). So, seeing this explicit notify() confused us. Note that adding a new object does not require this explicit notify(). The transactional stuff does not happen in zope.formlib. Unfortunately zope.formlib is a bit opaque in the way it works. Further, if we have to expect the developer to manually notify after every change, it could invite unnecessary bugs. Which is why you should let the library handle this for you wherever possible and something you write tests for. We are killing the server with a Ctrl-C. Maybe something is not getting flushed out to the disk yet? No, that is not likely to be the case. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-CMF] GenericSetup backport
Am 31.05.2011, 16:05 Uhr, schrieb Godefroid Chapelle got...@bubblenet.be: 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-dev] beta.zope.org (www.zope.org relaunch project)
Am 10.05.2011, 06:55 Uhr, schrieb Andreas Jung li...@zopyx.com: Constructive criticism and feedback is welcome _now_. Hi Andreas, along with others I'd like to thank you and the team for taking the time to do this. The new site has a clear message and looks good - not sure if the Zope logo should be repeated three times on the front page (surely the word mark should not be part of The World of Zope) and there are some spelling issues dekade should normally be spelt with a c; Python can either be capitalised or written in quotes but not both... One thing that I think is missing on the resource page is a Products overview - PyPI isn't really suitable for someone wanting to see whether Zope (2) is suitable for them and despite what we now think about how to extend Zope, the Products do provide off-the shelf solutions for many situations; something that as developers we easily overlook. Something like the Plone directory, probably implemented as part of zope2.zope.org, but visible in the resources section. I suspect this means some kind of QS is required as only too many Products will no longer work with current versions of Zope and the onus must be with the Product author or maintainer. 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-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-CMF] CMF 2.3 plans?
Am 19.04.2011, 13:41 Uhr, schrieb Jens Vagelpohl j...@dataflake.org: 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 insert excuse here 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
