Re: [Zope-dev] makeClass and makeClassForTemplate
On 4 September 2012 22:23, yuppie wrote: > Hi Laurence! > > > > Laurence Rowe wrote: >> >> Now that you've cleaned up Products.Five in Zope trunk, what should >> other packages that use ``makeClass`` and ``makeClassForTemplate`` >> change to? > > > Well. I wasn't aware of the fact that other packages use these constructors. > Please let me know if you think additional BBB support is needed. > > >> For five.formlib I simply exchanged ``makeClass`` for ``type`` and >> ``makeClassForTemplate`` for ``SimpleViewClass``, see: >> >> http://zope3.pov.lt/trac/changeset/127697/five.formlib/branches/zope-trunk-compat >> >> Would these changes be ok for packages that want to continue working >> with Zope 2.13? > > > AFAICS it's fine to use the ``type`` constructor instead of ``makeClass`` in > Zope 2.13. > > ``SimpleViewClass`` is not available in Zope 2.13, so that part will not > work in Zope 2.13. ``makeClassForTemplate`` has a slightly different > signature, but the way five.formlib uses it should work with both versions. > So I would fall back to ``makeClassForTemplate`` if import of > ``SimpleViewClass`` doesn't work. Other than five.formlib, I only found makeClass being used in plone.app.portlets and kss.core. I've fixed both of those to use type instead and have used the suggested fallback for five.formlib on trunk. I don't think we need any BBB support in Zope itself for this. Laurence ___ 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 )
[Zope-dev] makeClass and makeClassForTemplate
Hi Yuppie, Now that you've cleaned up Products.Five in Zope trunk, what should other packages that use ``makeClass`` and ``makeClassForTemplate`` change to? For five.formlib I simply exchanged ``makeClass`` for ``type`` and ``makeClassForTemplate`` for ``SimpleViewClass``, see: http://zope3.pov.lt/trac/changeset/127697/five.formlib/branches/zope-trunk-compat Would these changes be ok for packages that want to continue working with Zope 2.13? Laurence ___ 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] Restoring zLOG trunk
On 30 August 2012 15:56, Laurence Rowe wrote: > On 29 August 2012 15:44, Tres Seaver wrote: >> On 08/29/2012 09:25 AM, Tres Seaver wrote: >>> That base class has been gone since ZConfig 2.9.2. I don't think the >>> Zope2 trunk has pinned / unpinned ZConfig in a long time, so I'm not >>> sure why it would just now break (ZConfig 2.9.2 was released in >>> February, and 2.9.3 in June). >> >> I just pushed a change to the Zope2 trunk to use the new speling. > > While Tres fixed the error on Zope trunk, the same fix is still needed > by zLOG. According to > http://svn.zope.org/repos/main/zLOG/README-trunk.txt: > > """ > This package has been re-integrated into the Zope2 package. Maintenance > happens on the 2.11 branch and new development could occur inside > `Zope2/src/zLOG`. > """ > > However, Zope 2.12, 2.13 and trunk still use the egg and the only > place it seems to exist in that package is at > /Zope/branches/2.11/lib/python/zLOG, presumably where it was moved > from during eggification. > > I'm going to restore zLOG trunk by copying in the current 2.11 branch > so it can be fixed in a similar manner. zLOG 2.12.0 released and Zope trunk versions.cfg updated to use it. Laurence ___ 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 )
[Zope-dev] Restoring zLOG trunk
On 29 August 2012 15:44, Tres Seaver wrote: > On 08/29/2012 09:25 AM, Tres Seaver wrote: >> That base class has been gone since ZConfig 2.9.2. I don't think the >> Zope2 trunk has pinned / unpinned ZConfig in a long time, so I'm not >> sure why it would just now break (ZConfig 2.9.2 was released in >> February, and 2.9.3 in June). > > I just pushed a change to the Zope2 trunk to use the new speling. While Tres fixed the error on Zope trunk, the same fix is still needed by zLOG. According to http://svn.zope.org/repos/main/zLOG/README-trunk.txt: """ This package has been re-integrated into the Zope2 package. Maintenance happens on the 2.11 branch and new development could occur inside `Zope2/src/zLOG`. """ However, Zope 2.12, 2.13 and trunk still use the egg and the only place it seems to exist in that package is at /Zope/branches/2.11/lib/python/zLOG, presumably where it was moved from during eggification. I'm going to restore zLOG trunk by copying in the current 2.11 branch so it can be fixed in a similar manner. Laurence ___ 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] [ZODB-Dev] RFC: release persistent as a standalone package
On 1 July 2012 02:16, Leonardo Rochael Almeida wrote: > I'm +1 on the change even without the answer to my next question, but > can you elaborate on what is the advantage of releasing persistent > appart from ZODB? As well as the clearer separation of concerns it opens up the possibility for other persistence systems to adopt persistent for detecting changes to mapped objects, gaining the benefit of its fast C implementation. The BTrees package is also useful outside the context of the ZODB. Laurence ___ 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 4 ZMI sprint report
On 26 January 2012 04:29, Christopher Lozinski wrote: > Thank you for the sprint report. > > I think it is great that you are working on upgrading the ZMI. > > I am also turning my attention to this problem. Clearly ZMI needs an > upgrade. > I need an upgraded ZMI. > > Today I fired up my old version of ZAM. I can give you a password and > url if you want to see what it looks like. My understanding is that > it is a well thought out upgrade for the ZMI. Properly done with page > templates, not dtml, and pluggable. It certainly looks nice. > > Of course it has copy, cut, delete, rename, but no create. > > I also did a reinstall of the ZAM demo, but it broke. > > Am I doing the wrong thing working on ZAM? Is that consistent with the > direction others are taking on upgrading the ZMI, or should I be putting > my energy elsewhere? > > If I am doing the right thing working on ZAM, perhaps the first thing I > should do is get the install working again correctly. For that I have > to get svn access from the Zope foundation. I presume Larry Rowe is the > release manager for Zope 4, so he is the person who signs off on the > upgrades to ZAM? > > Do I understand the process correctly? Is ZAM part of Zope 4? Is it > the basis of the new ZMI, or is something else the new ZMI? I think building a better ZMI will be important in the long run though I'm not sure it should land in Zope 4 itself as I think it could be too big a step for that release. I wasn't able to get zam.demo (svn trunk) to run, so I don't have an opinion on ZAM itself at the moment. Note that Zope 4 is based on Zope 2 rather than BlueBream so I don't know how much of the existing work would still be applicable. I can volunteer some time towards guiding the Zope 4 release process, though it may be appropriate to find someone more comfortable with the existing svn/email/launchpad toolchain to be release manager if the consensus is to stay with that. Laurence ___ 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 4 release management
On 1 February 2012 14:35, Jonathan Ballet wrote: > On Wed, Feb 01, 2012 at 02:21:32PM +0100, Lennart Regebro wrote: >> >> What we would like to do, of course, is to have a self-hosted github. >> :-) (And that exists. Buuut... it costs $250 per commiter and >> year, so that's not an option, obviously.) > > Just to be sure I keep the fire on: what about self-hosted Gitorious? > It's not as neat as Github, but you still have the same (similar) > forking/merging abilities than Github. >From me, the key advantage of Github is the functionality to easily discuss code in pull requests and the one-click merging where appropriate. It takes me much less effort to respond to a Github pull request where I have all the relevant information to hand than an email with a patch or a request to take a look at a branch in subversion. For projects I work on in my own time that often makes the difference when it comes to responding in a timely manner. Github certainly has it's problems too, but it has an api for scripting which makes it possible to send better commit emails or integrate with Launchpad for bug tracking if someone wants to put the effort in. I don't really have an opinion on whether Github or a repository hosted on a zope.org server is nominated as the ZF's canonical repository (presumably with a pre-receive hook that checks all commit authors are known to have signed the contributor agreement.) With DVCS it shouldn't really matter. It's access to improved tools that's important for me. Laurence ___ 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 2 WSGI investigation
On 3 January 2012 08:34, Sylvain Viollon wrote: > > Op 1 jan 2012, om 20:39 heeft Martin Aspeli het volgende geschreven: > >> >> Hi, >> > > Hello, > >> There are three known WSGI implementations of the Zope 2 publisher. >> I've had a look at them and made some notes about what I think >> provides the best story: >> >> ## Zope 2.13 WSGIPublisher >> > > [...] > >> >> ## infrae.wsgi >> >> Pros: >> >> * Clean and well documented >> * Properly emits publication events >> * Supports streaming > > Those two points are features I use actively in Silva, and where motivation > for me to work on my > implementation. (I had a look before to repoze.zope2 and the default Zope 2 > support, back in 2.12). > >> * Supports simplified virtual hosting with X-VHM-Host > > That is not completely true. I support setting the hostname, however to set a > virtual path, you need to do this during traversing, which is done in > BaseRequest, > that I don't change (because it is a big large blob of code where you cannot > really plug anything in it, or > change only a few line in it without changing everything). > > In production we use mod_rewrite to rewrite the URL with an old > VirtualHostMonster url and pass it to mod_wsgi with the help of the flags PT. What advantage is there to setting the X-VHM-Host header over just setting the Host header? Laurence ___ 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
On 24 November 2011 07:58, Wichert Akkerman wrote: > On 11/24/2011 01:29 AM, Florian Friesdorf wrote: >> On Wed, 23 Nov 2011 09:50:49 -0500, Tres Seaver >> wrote: >>> Second, it is already feasible to work with modern VCSes against the >>> existing SVN repository: I've been doing it with bzr for literally years >>> now; I know of lots of documentation on using git against SVN as well. Of >>> course, Github is more than a VCS, but its main advantage over other >>> solutions lies in being able to accept casual contributions from non-core >>> developers, which is hardly in scope for the early phases of the Zope4 >>> effort. >> github enables a peer review process: while everybody who signed the >> plone committer agreement could just commit to the plone repo, we do >> pull-requests and somebody else with commit rights checks the request >> and merges. > > We've never had a problem with peer review before. People review the > commit lists which receive all commits with full diffs and react if they > see something off. That is a very well working peer review system. I > don't see that improving with github; in fact I see it becoming worse: > commit emails no longer get diffs at all, and people are less likely to > look at a webinterface for a quick review than they are to take a quick > look at an email. The move from Plone to github certainly made me stop > all review work, where I reviewed all commits to core code before. I'm not sure I agree with that, it's certainly been an issue in CMF for instance. Where we really miss out is that only a fairly small group of people feel confident enough to commit their changes, and as a group we do a poor job of encouraging new contributors as patches are often left in the bug tracker. I certainly find it much easier to review a pull request and click merge from the github interface (leaving it to Jenkins to validate that the tests continue to pass.) For the long term health of the project this is vital, we're not replacing the developers we're losing. It certainly shouldn't be that difficult to produce our own emails with full changesets for Plone, it just requires someone who misses them to pick it up. Laurence ___ 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
On 23 November 2011 06:58, Wolfgang Schnerring wrote: > * Tres Seaver [2011-11-22 22:46]: >> On 11/22/2011 12:13 PM, Laurence Rowe wrote: >>> While the Zope Foundation deliberates on version control, I think >>> it's likely that development will continue using Git and Github. >> >> Please don't try to jump the gun on the process here [...] >> It is not appropriate for a small subset of the community to preempt >> this kind of choid: "ask forgiveness rather than permission" is *not* >> going to fly here, and trying to push harder only irritates folks you >> might otherwise persuade. > > When reading the emails on this list about this topic, I get a strong > feeling of "us vs. them". Is that really necessary? > > In that light, and trying to make visible the (positive!) aspects of the > different opinions, allow me to ask: > > Tres, while I realize that you also rightly raise the formal issue that > a vocal minority shouldn't surge ahead and create facts, do I understand > you correctly that the main inherent[1] issue is a legal one, concerning > proper handling of copyright etc.? Could someone explain what's at stake > here, since at least I only have a vague feeling of "if something in > that area goes wrong, it could be really bad"? > > Laurence, do I understand you correctly that your main concern is ease > of use for development and that decentralized version control would be > preferable to a centralized one? Do you feel unduly blocked by the need > to resolve these (rather tricky) legal issues? Might a technical > solution be of use until this is resolved (git can read/write svn, can't > it)? Yes, we want to benefit from the ease of merging afforded by git and be able to use the excellent facilities that github provides. Unfortunately git-svn is really only a tool for an individual developer (collaboration still takes place in svn) and does not bring the benefits that a real git repository does - the ability to collaborate on github and use the tools provided there. The current scratch repository is a conversion using svn2git, as that has proper support for tags. It's not clear to me what the blocking issues are from the ZF perspective, whether legal or just that most ZF members don't want to use git. Laurence ___ 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 )
[Zope-dev] Supporting interworking with repository branches on github
As you are already aware, at the SF Zope sprint we used Git and github for our work. The work contained in https://github.com/zopefoundation is by people who have already signed the Zope Foundation contributor agreement. While the Zope Foundation deliberates on version control, I think it's likely that development will continue using Git and Github. We want to do this in a way that maintains flexibility for code committed to Git to also be committed to svn.zope.org, so it would be helpful to get a list of Name, Email, username for svn.zope.org committers to facilitate the creation of an author mapping file. (Presumably this information is in LDAP or similar.) We would of course be happy to hand administration rights of the github organization to the Zope Foundation if it was felt to be helpful in ensuring that contributions to that repository counted under the committer agreement. Laurence ___ 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 4 roadmap
On 22 November 2011 10:13, Sylvain Viollon wrote: > > Op 17 nov 2011, om 20:57 heeft Tres Seaver het volgende geschreven: > > Hello, > >> >> >> On 11/17/2011 02:05 PM, Laurence Rowe wrote: >>> On 17 November 2011 15:23, Martin Aspeli >>> wrote: >>>> On 17 November 2011 14:46, Laurence Rowe wrote: >> >> >> >>>>> - Move authentication out to WSGI middleware. >>>> >>>> +1 - anything we can do to make AccessControl simpler and more >>>> debuggable would be a big win. >> >> >> Note that there is a counter-trend here among the Pyramid crew: many >> developers *want* tight integration of authentication, particularly the >> login forms. >> > > And there is a major issue with this is that for the moment your > authentication depends from where you are in your Zope 2 application. Maybe > in some part of the application the authentication will be done using LDAP, > and not in some other: you can have a acl_users only for some part of the > application, and users there are available locally and not globally. That is > because the authentication is done after the traversing. If you want to do > this in a WSGI middleware, you will have to do the traversing in a WSGI > middleware before, otherwise lot of people won't be able to migrate theirs > applications to Zope 4, because the paradigm changed. > > I don't think this is a good idea because of that. Do you have multiple acl_users folders in a single Silva site? Or is it simply the same case as Plone where you might have multiple sites within the one ZODB? In the long run I expect that Plone will move to configuring multiple sites in a single instance through the WSGI configuration (rather than by creating sites through the ZMI.) In this scenario it would be possible to have different authentication configurations for each site in the WSGI config. Laurence ___ 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 4 release management
On 17 November 2011 20:20, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/17/2011 03:14 PM, Laurence Rowe wrote: >> On 17 November 2011 19:45, Tres Seaver wrote: >>> Again, this is a choice to be made by the foundation: any polling >>> will be done by the members of the foundation (this might be the >>> biggest non-election item on the agenda for the next annual >>> meeting). >> >> When is the next annual meeting? > > Q1 2012 (date still to be set by the board). Is there any possibility the board could poll the members of the Zope Foundation between annual meetings? We're not looking to migrate the whole of svn.zope.org, only use github for what is essentially a new project. Laurence ___ 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 4 release management
On 17 November 2011 19:45, Tres Seaver wrote: > Again, this is a choice to be made by the foundation: any polling will > be done by the members of the foundation (this might be the biggest > non-election item on the agenda for the next annual meeting). When is the next annual meeting? Laurence ___ 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 4 roadmap
On 17 November 2011 15:23, Martin Aspeli wrote: > On 17 November 2011 14:46, Laurence Rowe wrote: >> Here's my current understanding of the Zope 4 roadmap. >> >> >> Zope 4 >> -- >> >> Significant progress has already been made on the following features >> and I expect they should all land in time for a Zope 4 release: >> >> - Storing parent pointers (elro, davisagli): we have a branch of Zope >> that changes OFS to store parent pointers on objects implementing >> ILocation and fixed the issues that arose in copy/cut/paste and zexp >> export code. There's an issue remaining with Acquisition, where we >> lost some protection against cycle protection - Hanno continues >> working on this. See also: >> http://wiki.zope.org/zope2/SetParentAndNameInOFS > > +1 > >> - Remove XML zexp export (davisagli). > > +1 > >> - Catalog using intids (rossp): we have branches of Zope, ZCatalog and >> CMF which change the catalog to use intids as their internal uid and >> rid. This needs more testing, but looks very promising. Currently it >> uses plone.app.intid / five.intid to maintain an intid to physical >> path mapping. Once the parent pointer work is stable, we can stop >> doing this and load objects directly from the database connection > > +0 - can we articulate the benefit of doing this? Currently items are keyed by path in ZCatalog as they must be pulled out with their correct acquisition context (five.intid must also maintain a mapping based on path for the same reason.) When we have parent pointers we will be able to use zope.intid directly instead of five.intid (which many of us have had bad experiences with.) Using intids will mean that renaming or moving items does not require them to be unindexed and reindexed in the portal_catalog as they will maintain their same intid and will open up the possibility of intersecting result sets from a the portal_catalog with a zc.relation catalog. >> - Chameleon (chaoflow): Florian worked on making Zope use Chameleon by >> default. This works for the most parts, but there's some problems left >> in tests, as Chameleon wants an utility to be registered but a lot of >> tests in Zope and CMF don't use ZCML test layers. > > +1 > >> - WebOb (garbas): Rok worked on bringing in WebOb as an underpinning >> for the request/response objects and making both API's available at >> the same time. I think the request is done and a good deal of the >> response works. Doing this means we can deprecate parts of the old >> request API and encourage the use of the more standard WebOb API. > > +1, though we'll need to balance the desire to be a better WSGI > citizen with adding yet more complexity to BaseRequest and > BaseResponse. > >> - WSGI (matthewwilkes, hannosch): We fixed the bugs that had been >> reported about using the current WSGI support (mod_wsgi problems, >> forced dependency on repoze.who) on trunk and the 2.13 branch. >> Afterwards Matthew continued on a branch to remove the ZServer/medusa >> from Zope and leave only the WSGI publisher in place. > > +1 - I think WSGI should be the only way to deploy Zope 4. > >> - Decorators for AccessControl (chaoflow). > > +1 > >> Future releases (Zope 5, 6, etc.) >> - >> >> There has been some discussion on these topics but not much in the way >> of code yet: >> >> - Traversal Simplification. Remove attribute lookup from default traversal. > > +1, although this will require a lot of fixes in Zope consumers. I > think we need a substantially simpler traversal mechanism that people > actually understand. I've pdb'd BaseRequest.traverse more times than I > care to remember and I still only vaguely understand it. > >> - Unicode IDs in OFS > > +1 > >> - Remove __allow_access_to_unprotected_subobjects__=1 from >> OFS.SimpleItem.Item > > +1, though again will break quite a lot. It's scary from a security > perspective, though. > >> - New ZMI > > +0 - we certainly need better XSRF protection and accessibility and > look and feel are not great, though I think we should also consider > what we actually use the ZMI for. A low-level object browser is really > useful as a last resort admin tool. A number of the other things (like > the various CMF tools, PAS, etc) could just as well expose their own > views more independently of the ZMI, though we'd still need a way to > discover those views. Perhaps something more simliar to the Plone > control panel where tools can register views that just appear in a > list of things you may need t
Re: [Zope-dev] Zope 4 release management
On 17 November 2011 16:32, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/17/2011 07:25 AM, Laurence Rowe wrote: > >> Along with David Glick, I would like to volunteer for the Zope 4 >> release management role, where I would take responsibility for >> producing the initial release of Zope 4 and David would then take >> over for the maintenance releases. >> >> In doing so, I thought it would be helpful to set out our >> understanding of the mission of Zope 4. If accepted I'll work to >> produce a first draft of a roadmap based on the outcome of the recent >> sprints and discussions on this mailing list. >> >> >> Mission --- >> >> Zope 4 will be the first of several releases that seek to simplify >> our software stack. Over the years Zope 2 grew through the adoption of >> new technologies, notably Zope 3, but rarely removed older ways of >> doing things. Below, 'Zope 4' refers to the series of releases >> including Zope 5, 6, etc. >> >> Over the series of releases, Zope 4 will progressively remove more >> and more software as we transition to using software components >> shared with other Python web frameworks. >> >> It is as important to state what Zope 4 *is not* as what it should >> be: >> >> * Zope 4 will not seek to be of interest to those developing new >> applications. They should instead look to projects such as Pyramid >> that build on the experience and technologies of Zope without regard >> for the backwards compatibility concerns that will constrain Zope 4. >> >> * Zope 4 will not seek to innovate in itself but encourage innovation >> in software components shared with the wider Python web community. > > > I smell something funny in here: if we aren't innovating, why are we > making the effort? Zope 3, Grok and Pyramid have all innovated already. This is about making better use of those existing innovations and progressively removing code and dependencies from what is currently Zope2. > >> * Zope 4 will not move so quickly that it becomes impossible to make >> Plone, its main consumer, work with it. > > > We should be working to enable the other Zope2-consuming projects to keep > up, too. I see Zope 4,5... very much as a transition path. I expect the different Zope2 based projects will move down that path at different speeds and that Plone will drive it by virtue of its larger developer base. Most of the other Zope2 based applications do not have the same wide community of developers to draw on. > >> * But neither will Zope 4 seek to retain backwards compatibility at >> any cost. As the basis of Plone 4, Zope 2.13 will see maintenance >> releases as long as Plone 4 is supported. > > > As long as any significant body of developers commits to maintaining it, > even if the Plone devs don't care any more. Of course. I expect that for some existing Zope2 applications that will be the easier path. > >> * Zope 4 will not have a release cycle independent of Plone. Zope 4 >> only exists as a transitional path for Zope 2 based applications and >> experience has shown that Zope 2 releases not used in any Plone >> release do not receive the same level of ongoing maintenance. > > > I would actually argue that "Zope4" have no real release cycle at all: > instead, the individual pieces which make up Zope should have their own > cycles, with perhaps a ZTK-like tracking set that Plone and others use as > platform targets. At some point we will need to make a release that will receive bug fixes. The best point to do that will be the same time as a Plone release. This probably applies more to the central distribution (currently named Zope2), the other subsidiary distributions will certainly go their own way (as we've already seen with DateTime, ZPublisher, etc.), though any included with a Plone release will have a much larger number of people invested in making future bug fix releases. > >> We want to encourage all features to be developed on separate feature >> branches so we can maintain a stable trunk. Before these feature >> branches are merged they should be posted to the mailing list for >> review. >> >> This process will necessitate a lot of merging, so I want to propose >> that we move to Git for development (something we found very helpful >> at our recent San Francisco Zope 4 sprint.) > > > Note that this question is *not* suitable for "loudest voice on zope-dev > wins" ressolution. The software belongs to the Zope Foundation, which > will make any such decision. The work done on github by the Zope4 > sprinters in
[Zope-dev] Zope 4 roadmap
Here's my current understanding of the Zope 4 roadmap. Zope 4 -- Significant progress has already been made on the following features and I expect they should all land in time for a Zope 4 release: - Storing parent pointers (elro, davisagli): we have a branch of Zope that changes OFS to store parent pointers on objects implementing ILocation and fixed the issues that arose in copy/cut/paste and zexp export code. There's an issue remaining with Acquisition, where we lost some protection against cycle protection - Hanno continues working on this. See also: http://wiki.zope.org/zope2/SetParentAndNameInOFS - Remove XML zexp export (davisagli). - Catalog using intids (rossp): we have branches of Zope, ZCatalog and CMF which change the catalog to use intids as their internal uid and rid. This needs more testing, but looks very promising. Currently it uses plone.app.intid / five.intid to maintain an intid to physical path mapping. Once the parent pointer work is stable, we can stop doing this and load objects directly from the database connection - Chameleon (chaoflow): Florian worked on making Zope use Chameleon by default. This works for the most parts, but there's some problems left in tests, as Chameleon wants an utility to be registered but a lot of tests in Zope and CMF don't use ZCML test layers. - WebOb (garbas): Rok worked on bringing in WebOb as an underpinning for the request/response objects and making both API's available at the same time. I think the request is done and a good deal of the response works. Doing this means we can deprecate parts of the old request API and encourage the use of the more standard WebOb API. - WSGI (matthewwilkes, hannosch): We fixed the bugs that had been reported about using the current WSGI support (mod_wsgi problems, forced dependency on repoze.who) on trunk and the 2.13 branch. Afterwards Matthew continued on a branch to remove the ZServer/medusa from Zope and leave only the WSGI publisher in place. - Decorators for AccessControl (chaoflow). Future releases (Zope 5, 6, etc.) - There has been some discussion on these topics but not much in the way of code yet: - Traversal Simplification. Remove attribute lookup from default traversal. - Unicode IDs in OFS - Remove __allow_access_to_unprotected_subobjects__=1 from OFS.SimpleItem.Item - New ZMI - Move authentication out to WSGI middleware. Long term - - Move to WebOb as our request object. The wider Python web framework community seems to have settled on WebOb as their request object of choice, so to facilitate sharing of software components with other projects we should consider making WebOb our request object too (instead of just wrapping it). This will require buy-in from the wider ZTK community as the ZTK components will need - Move to Python 3. Laurence ___ 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 )
[Zope-dev] Zope 4 release management
Along with David Glick, I would like to volunteer for the Zope 4 release management role, where I would take responsibility for producing the initial release of Zope 4 and David would then take over for the maintenance releases. In doing so, I thought it would be helpful to set out our understanding of the mission of Zope 4. If accepted I'll work to produce a first draft of a roadmap based on the outcome of the recent sprints and discussions on this mailing list. Mission --- Zope 4 will be the first of several releases that seek to simplify our software stack. Over the years Zope 2 grew through the adoption of new technologies, notably Zope 3, but rarely removed older ways of doing things. Below, 'Zope 4' refers to the series of releases including Zope 5, 6, etc. Over the series of releases, Zope 4 will progressively remove more and more software as we transition to using software components shared with other Python web frameworks. It is as important to state what Zope 4 *is not* as what it should be: * Zope 4 will not seek to be of interest to those developing new applications. They should instead look to projects such as Pyramid that build on the experience and technologies of Zope without regard for the backwards compatibility concerns that will constrain Zope 4. * Zope 4 will not seek to innovate in itself but encourage innovation in software components shared with the wider Python web community. * Zope 4 will not move so quickly that it becomes impossible to make Plone, its main consumer, work with it. * But neither will Zope 4 seek to retain backwards compatibility at any cost. As the basis of Plone 4, Zope 2.13 will see maintenance releases as long as Plone 4 is supported. * Zope 4 will not have a release cycle independent of Plone. Zope 4 only exists as a transitional path for Zope 2 based applications and experience has shown that Zope 2 releases not used in any Plone release do not receive the same level of ongoing maintenance. Development Process --- We want to encourage all features to be developed on separate feature branches so we can maintain a stable trunk. Before these feature branches are merged they should be posted to the mailing list for review. This process will necessitate a lot of merging, so I want to propose that we move to Git for development (something we found very helpful at our recent San Francisco Zope 4 sprint.) I don't have any opinion on where the canonical repository should be hosted - I know some people have strong opinions that this should be on Zope Foundation controlled hardware. If that's to be the case then we will need the svn.zope.org maintainers to setup a shared git repository on that machine. I think mirroring to github (and/or launchpad in future) will be the simplest way to provide an anonymously accessible and web browsable copy. Laurence ___ 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?
On 16 November 2011 12:28, Lennart Regebro wrote: > On Wed, Nov 16, 2011 at 12:53, Charlie Clark > wrote: >> Am 16.11.2011, 12:49 Uhr, schrieb Lennart Regebro : >> >>> 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. > > When I said skins I meant ++skins++. CMF Skins must die. While I think there is definitely scope for simplifying the mix of competing skin concepts in the Zope/CMF/Plone space, we need to be careful not to bite off more than we can chew. We still have a lot of CMF skin scripts and templates in Plone that I don't want to become a blocker for adopting Zope 4. This should be the first of several releases that progressively rationalise our software stack, lets not try and do it all at once. Laurence ___ 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?
On 16 November 2011 10:30, Christian Theune wrote: > Hi, > > I'd like to revert the removal of the ++skin++ traverser in Zope 4. > > As we're working on a replacement ZMI at a sprint currently (more > details about that in a bit) we'd like to leverage this feature. > > From my perspective, I value that Zope 2/4 has always made some choices > upfront that one could leverage right away. Especially as multiple > orthogonal components (like: your application and the ZMI) need to > leverage this plugin point, I'd rather have this provided by the framework. > > I couldn't find an argument anywhere why ++skin++ should be gone. It was removed in http://zope3.pov.lt/trac/changeset/122056 because it wasn't actually being used anywhere. I'm not completely averse to adding it back, but it does create confusion with the various different alternatives in Zope2 like CMF skins and plone.browserlayer. Laurence ___ 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 4 publisher/traversal, sprint topic
On 27 October 2011 14:34, Leonardo Rochael Almeida wrote: > Hi, > > Sorry for the cross-post, but I'd like to talk about a possible sprint > topic for the next DZUG sprint[1], and invite myself to it :-) We'll also be sprinting on Zope 4 before the Plone conference this coming Monday, Tuesday, Wednesday. There are a couple of places left, so if anyone else can make it do let me know. http://coactivate.org/projects/san-francisco-zope-sprint Laurence ___ 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] Hotfix for security vulnerability
On 24 October 2011 22:54, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On behalf of the Zope security response team, I would like to announce > the availability of a hotfix for a vulnerability inadvertently > published earlier today. > > 'Products.Zope_Hotfix_20111024' README > == > > Overview > - > > This hotfix addresses a serious vulnerability in the Zope2 > application server. Affected versions of Zope2 include: > > - - 2.12.x <= 2.12.20 > > - - 2.13.x <= 2.13.6 > > Older releases (2.11.x, 2.10.x, etc.) are not vulnerable. Can you confirm whether or not Zope 2.13.6 through 2.13.10 are affected? Laurence ___ 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] [collective.recipe.solrinstance] Example not working
On 17 October 2011 18:36, Hanno Schlichting wrote: > On Mon, Oct 17, 2011 at 11:19 AM, Andreas Jung wrote: >> I used the single-core example for the solrinstance recipe: > > I think someone reported the Solr core examples to be broken in the > latest releases. I don't use the core-variants myself, though. > > Without an issue tracker, it's hard to keep track of those reports. > > Should we migrate the recipe to github and get a free issue tracker? +1 Laurence ___ 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.sqlalchemy+py3 test failures.
On 29 September 2011 16:51, Chris Withers wrote: > It'd also be great if we could get support for SA 0.7+'s new events > system... I'm not convinced this will give any benefit. Currently we just require: >>> Session = scoped_session(sessionmaker(bind=engine, ... extension=ZopeTransactionExtension())) Instead we would require something like: >>> Session = scoped_session(sessionmaker(bind=engine)) >>> ext = ZopeTransactionExtension() >>> event.listen(Session, "after_attach", ext.after_attach) >>> event.listen(Session, "after_begin", ext.after_begin) >>> event.listen(Session, "after_flush", ext.after_flush) >>> event.listen(Session, "after_bulk_update", ext.after_bulk_update) >>> event.listen(Session, "after_bulk_delete", ext.after_bulk_delete) >>> event.listen(Session, "before_commit", ext.before_commit) Though this could become: >>> Session = scoped_session(sessionmaker(bind=engine)) >>> ZopeTransactionExtension(Session) I'm just not sure that it's worthwhile. Laurence ___ 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.sqlalchemy+py3 test failures.
On 29 September 2011 10:33, Chris McDonough wrote: > On Tue, 2011-09-27 at 12:40 -0400, Tres Seaver wrote: >> This bootstrap is from Jim's '2' branch of zc.buildout: >> >> http://svn.zope.org/zc.buildout/branches/2/bootstrap/bootstrap.py?rev=121484&view=auto >> >> It is designed to work with Py3k. > > I've replaced the bootstrap.py in the chrism-py3 branch of both the > transaction package and the zope.sqlalchemy packages with that one, and > everything looks good! > > I think we can probably merge both of these branches to their respective > trunks and make releases. I have the necessary powers to do it for > transaction; I'll try to track down elro to see if he's willing to do it > for zope.sqlalchemy. I've added chrism as an owner. Before we make a final release I'd like to revisit the savepoint release branches of transaction / zope.sqlalchemy. I'll bring this up in another mail. Laurence ___ 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] [BlueBream] Referring to same interface using zope.schema.Object
On 22 July 2011 13:32, Joshua Immanuel wrote: > Hello, > > On Fri, 2011-07-22 at 13:41 +0200, Jacob Holm wrote: >> On 2011-07-22 13:26, Brian Sutherland wrote: >> > This would be my first guess: >> > >> > class INode(Interface): >> > pass >> > >> > INode.parent = Object( >> > title=u"Parent node", >> > schema=INode >> > ) >> > >> > INode.children = List( >> > title=u'Child nodes', >> > value_type=Object(schema=INode) >> > ) >> > >> > > The method suggested by Brian works without any issues. :) No, there are issues. Take this example: >>> class ITest(Interface): ... title = schema.TextLine() ... >>> ITest.names > >>> ITest.names() ['title'] >>> ITest.description = schema.Text() >>> ITest.names() ['title'] The fields on an interface are not stored as attributes, but are accessible using item access, e.g: ITest['title']. You cannot assign that way though: >>> ITest['description'] = schema.TextLine() Traceback (most recent call last): File "", line 1, in TypeError: 'InterfaceClass' object does not support item assignment Adding to an interface requires messing with the '_InterfaceClass__attrs' attribute of the dictionary and is discouraged. Laurence ___ 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 )
[Zope-dev] Publisher, WSGI and possibility for simplification
Breaking this out as the thread has got overlong. On 4 July 2011 09:49, Sylvain Viollon wrote: > On Sun, 03 Jul 2011 01:09:17 -0400 > Chris McDonough wrote: > >> On Sun, 2011-07-03 at 03:41 +0200, Hanno Schlichting wrote: >> > > Hello, > >> > - Continue to remove functionality tailored for TTW development, >> > like SiteRoot, AccessRules, HelpSys and step-by-step most of the ZMI >> > - Document and use the WSGI publisher and remove obsoleted >> > functionality like the virtual host monster, error_log, >> > ZServer/medusa, zopectl/zdaemon >> >> Zope still needs to the virtual host monster (or something like it) >> even with the WSGI publisher; there's nothing equivalent in the WSGI >> world (unless you could repoze.vhm, which is essentially just the >> virtual host monster, and probably doesn't need to live in >> middleware; no one uses it except people who use repoze.zope2). >> > > I have my own WSGI implementation, since a while, that works > perfectly (infrae.wsgi), and I still do use the VirtualHostMonster > (you can trash all the other things). > > I agree that its code might not been the best in the world, but it > works for the moment and does what it says (I would love to see > shiftNameToApplication implemented with more than one pass). > > I will sad to learn that this goes away, if nothing replace it. I > kind of don't like the WSGI approach of cutting the database, > traversing, authorization, rewriting Zope 2 concepts into middleware > as I think they don't really fit the design of pipes provided by the > WSGI middleware concept (but I do use middlewares for other things > with Zope 2). I was interested to see that Pyramid seems to be experimenting with a non-wsgi approach now too for transaction integration (http://groups.google.com/group/pylons-devel/browse_thread/thread/f05c56072e43f214/3006cbaf0258c568.) I really don't have enough experience with WSGI to know which is the best way to do it. I took a brief look at the documentation at http://www.infrae.com/download/tools/infrae.wsgi where some of the motivations behind it are mentioned. The builtin Zope2 WSGI publisher is still very new, and seems to have some rough edges still when running in mod_wsgi (possibly due to conflicts with Zope registered signal handlers.) Is it only that you think that the Zope2 WSGI publisher is not ready yet, or are there other problems? I'd certainly support simplifying the publisher, it has grown very complex as more and more functionality has been grafted on over the years. In the long run I'd much rather see something that only used __getitem__ for traversal and never getattr. Laurence ___ 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 )
[Zope-dev] Zope2 Sprint. 31 October - 2 November, San Francisco
To make the most of all those air miles for people attending the Plone Conference, I want to have a Zope2 Sprint on the preceding days (overlapping with the training.) Topics to include: * Making Acquisition optional * Adding __parent__ pointers (see http://wiki.zope.org/zope2/SetParentAndNameInOFS) * Further WSGI integration When? Monday 31 October - Wednesday 2 November. Where? Somewhere in San Francisco. Venue to be confirmed, possibly a co-working space. Hopefully we'll have about 6-12 people for a small and fairly focussed sprint. If you're interested please sign up on the co-activate page at http://coactivate.org/projects/san-francisco-zope-sprint Laurence ___ 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] direction
On 6 July 2011 15:27, Sascha Welter wrote: > I'm sorry, I don't really understand the current line of discussion yet. > > I see a lot of discussion which part is going to be cut out and dropped, > or replaced. I haven't yet understood what's the end target for the > project. > > So, are you guys expecting to get Zope into a shape where it will > attract new users and be a viable player again? Or, isn't the line > currently that "nobody uses Zope for new projects anyway"? > > In case that we believe that no new users are attracted to Zope, > wouldn't that mean that resources should go to make Zope into a shape > that helps existing applications run on Zope and survive? Modernize the > code, but break as little as possible in the process. As someone said, > what's the use for a company that has invested a lot of money in a Zope > Product, if there is something called "Zope" around, but they can't use > it without a major rewrite? > > > In case all these changes are made to make Zope again into a shiny new > framework that will attract new users, what's the use? Wouldn't people > go to pyramid anyway? There they have all that stuff already - but right > *now*. > > Looking at the descriptions here, in that line of thought and in the > long run we'll end up with something like pyramid in a few years, only > with a lot more disgruntled former users and much more confusion about > the name. When you change the name in the end, you've come full circle > anyway. Zope in it's current form is not maintainable in the long run. There are too many alternative ways of achieving the same thing. Over the next few years we will need to start moving to Python 3, and the only way to make that port possible is by reducing the size of the codebase. As a Plone developer, my interest is in how we make Zope into something that enables Plone to continue evolving and developing, to port to Python 3 and increasingly use more standard WSGI components. Rewriting in Pyramid is not an option for us, large rewrites generally fail (even if they do produce excellent new technology along the way...) Of course if people who have legacy applications want to continue maintaining a 'Classic' Zope 2 in it's current form then they are free to do so, but it won't happen without investment on their part. I expect they will have similar concerns to the Plone developers, and may find the same reduction and evolution approach to Zope useful. Laurence ___ 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] direction
On 5 July 2011 20:21, Leonardo Rochael Almeida wrote: > Hi Hanno, > > On Tue, Jul 5, 2011 at 11:18, Hanno Schlichting wrote: >> On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli >> wrote: >>> I would've thought it would also be possible for those who rely on this to >>> maintain the relevant eggs as optional installations against Zope 2.x, no? >> >> The ZMI is not a package - we don't have a split into zope and >> zope.app in Zope2. Once there's no more ZMI, Products.PageTemplates >> stops using RestrictedPython and the OFS base classes don't inherit >> from Acquisition.Implicit anymore, it'll be really hard to keep the >> legacy development approach working. > > I guess this is the biggest point of contention. Why does the ZMI have > to go? Although both Plone and ERP5 strive to gradually replace ZMI > based configuration with "native" interfaces (native to Plone/ERP5), > isn't there value in having a minimal OFS browser with the ability to > Add/Delete/Copy/Cut/Paste objects as a fallback? It doesn't seem to > conflict with your stated goal: > > "I think what's going to stay is AccessControl, OFS (a bit lighter), > ZPublisher (WSGI), the ZODB, ZCatalog and all the wiring for a set of > Zope Toolkit libraries like components, events, browser pages and so > on. > > That's the kind of scope that should be possible to port to Python 3 > and actually modernize enough to be understandable.(...)" > > Or to put it differently, in which way does having a minimalistic OFS > browser for a ZMI conflicts or hinders Plone's objectives for the > Zope2 code base? > > If we still have that minimalistic ZMI, all players in our community > can decide how much effort they want to spend maintaining which legacy > pieces technology, depending on what makes economic sense to them, > without causing extra maintenance burden on the other players. I think the problem with the current ZMI is that it brings in a whole load of dependencies that we don't otherwise need - if it were minimalistic it wouldn't be a problem. I'm all for someone writing a very simple object browser though, it would make a great optional package. I'm certainly interested in moving away from OFS in the medium term towards the much simpler ZTK / Pyramid approach of __getitem__ traversal. Laurence ___ 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] direction
On 5 July 2011 11:22, Jonas Meurer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Am 05.07.2011 12:04, schrieb Hanno Schlichting: >> On Tue, Jul 5, 2011 at 11:56 AM, Martin Aspeli >> wrote: >>> On 5 July 2011 10:31, Hanno Schlichting wrote: So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or 5.0 or anything else doesn't make it any better at all. So 3.0 is the most sensible one :) >>> >>> Boy, that's going to be confusing. :) >>> I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the >>> defunct Zope 3, although I don't think there are any particularly good >>> options here. >> >> Zope2 4.0 would imply some sort of upgrade path from Zope 3 to this. >> That's as confusing as anything else and would lead to the question >> what happened to Zope2 3.0. >> >> Since we don't market Zope2 anymore, I think there's actually much >> less confusion from this than we'd fear. It's just an internal version >> number used in some buildout files, not something that has any >> particular meaning. > > I don't like either of these solutions. And I don't agree with Hanno, > that it's 'just an internal version number'. It will show up on > zope.org, launchpad.net, and many more places. > > I would rather bump the version number to 2.20 to highlight the major > changes, and keep the 2 as major for Zope2 versions. I agree with Jonas that any idea of giving a package named Zope2 a version number that is not 2.x is only going to lead to more confusion. For Zope2 we're used the x in 2.x.y being the major version now anyway, the next release should be 2.14. Lets stick with our convention until we have something that we really do want to promote to users outside the existing development community, I expect that will be a few years away yet. Laurence ___ 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] direction
On 4 July 2011 13:04, Leonardo Rochael Almeida wrote: > On the other hand, if we could get the ZTK version of this working > (the one that used /++vh-host and /++vh-root url segments) I think it > should be ok, and we could get rid of VHM completely. The BlueBream URL syntax is no better than the existing VHM syntax, it makes for insanely complex proxy configs. The repoze.vhm approach of using headers is much, much simpler. However we choose to integrate it (whether as middleware or some other way,) lets at least use the simple approach of setting headers or hard coding in paste/whatever config. Laurence ___ 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 )
[Zope-dev] Security Hotfix 20110622 released
Last week, the Zope and Plone security teams announced the discovery of a serious security issue affecting all recent versions of Zope and Plone, as well as the planned release of a Hotfix to address this issue to be made today, June 28th at 1500 UTC. The Plone and Zope security teams are announcing that this security hotfix is now available for download. For full instructions on how to get and install the Hotfix, go here: http://plone.org/products/plone-hotfix/releases/20110622 To find out more about the details of the issue, answers to common questions and which versions of Zope and Plone are affected, please see: http://plone.org/products/plone/security/advisories/20110622 Assistance in installing this hotfix is available free of charge via IRC in #plone-tuneup. If you don't have in-house server administrators or a service agreement supporting your website, you can find consultancy companies under the providers section of Plone.org - http://plone.org/support/network On behalf of the Zope and Plone security teams, Laurence ___ 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] Security announcement update
On 28 June 2011 14:40, Norbert Marrale wrote: > This should be clarified too: "You should, however, make sure that you > are running either Zope 2.10.13 or Zope 2.11.8 and PluggableAuthService > 1.5.5, 1.6.5 or 1.7.5 " > > Why must PluggableAuthService (+ its dependencies) even be installed? The Plone Hotfix for CVE-2011-0720 included patches to PluggableAuthService. If you use PluggableAuthService outside of Plone then you need to update to a release that includes that fix. If you don't run PluggableAuthService it is not required to install it. Laurence ___ 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 )
[Zope-dev] Security announcement update
This is an update on today's security hotfix release. The fix will be released at 15:00 UTC today, Tuesday 28th June, 2011 (11:00am US EDT.) Updated versions of Zope 2 containing the security fix will be released at the same time. For details on which versions of Zope and Plone are affected, please see: http://plone.org/products/plone/security/advisories/20110622 For installation instructions, please see: http://plone.org/products/plone-hotfix/releases/20110622 On behalf of the Zope and Plone security teams, Laurence ___ 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 )
[Zope-dev] Security announcement
On behalf of the Plone and Zope Security Teams I'd like to draw your attention to a security announcement that has just been published. This is a pre-announcement only, it does not contain any vulnerability details. Your sites are a safe today as they were yesterday. However, as the problem that has been found is so serious we are giving you advance warning that a patch is upcoming and recommending that you plan a maintenance period for your sites to coincide with the full announcement on Tuesday next week. Full details are available at http://plone.org/products/plone/security/advisories/pre-announcement-20110622 You can feel free to ask more questions on the plone-users mailing list or in the #plone IRC channel about details and how to protect yourself, but it is important to make a plan for this now. It is important to plan down-time at the time specified in that announcement or your site will potentially be at risk - following the release of a hotfix for the previous serious security vulnerability we received reports of automated attacks on unpatched sites. Laurence ___ 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] Sharing session between different zope servers
On 15 June 2011 19:05, Baiju M wrote: > On Wed, Jun 15, 2011 at 11:07 PM, Hanno Schlichting wrote: >> On Wed, Jun 15, 2011 at 7:26 PM, Baiju M wrote: >>> Is memcached a reliable storage for session data ? >>> >>> I would like to hear others experience with memcached >>> as a reliable storage for session data. >> >> It depends on what kind of reliability you need. Generally your >> sessions should be short-lived and memcached is fine for that. > > Well, what about a persistent session storage for 20 minutes > in memcached ? Do we have any control over when the keys are > evicted ? > > I am just reading few articles related to this: > http://sparklewise.com/?p=538 > http://en.wikipedia.org/wiki/Slab_allocation > http://code.google.com/p/memcached/wiki/MemcachedSlabAllocator If you don't supply the -M argument then memcached won't evict objects before their expiration time, but it may run out of memory. The new unlogged tables in Postgres 9.1 might be a great fit, though you'll still wipe sessions when you make changes to your infrastructure / restart stuff. But most sites can cope with that. Laurence ___ 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] [BlueBream] Reg. persisting data in ZODB via forms
On 9 June 2011 07:12, Joshua Immanuel wrote: > Hello Jonah, > > On Wed, 2011-06-08 at 22:25 -0700, Jonah Crawford wrote: >> Ah yes you do that in the zcml right after you define your object in a >> class :) > > I am not aware of the zcml configuration that can mark a class as > persistent. If you could explain, it would be helpful. ZCML is not relevant here. >> On Jun 8, 2011, at 10:23 PM, Joshua Immanuel wrote: >> > I was trying to add a non persistent object to the BTreeContainer. I >> > was of the notion that I don't need to make my object persistent >> > explicitly, as I am adding it to the persistent btree container. The >> > add operation was successful but the modify operation on my object >> > failed to persist. >> > Making my object persistent solved the issue. > > I derived my class from persistent.Persistent in order to make it > persistent. Deriving your class from Persistent is normally the right choice. Storing immutable non-persistent objects such as strings, ints, floats or tuples of them also works without surprises. Storing mutable non-persistent objects in the ZODB is considered advanced usage and you must inform the persistence machinery on any modification. The best way to do this is to re-assign the non-persistent object to it's parent persistent object, causing the parent to be marked as modified. Laurence ___ 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
On 8 June 2011 20:47, Joe Steeve wrote: > On Wed, 2011-06-08 at 14:48 +0100, Laurence Rowe wrote: >> A BTree efficiently stores a large number of key,value pairs because >> the storage is split across a number of persistent objects (buckets) >> each of which stores a part of the tree, so only the bucket that >> changes needs to be stored when a key,value is updated. See >> http://zodb.org/documentation/guide/modules.html#btrees-package and >> http://en.wikipedia.org/wiki/B%2B_tree > > Okay. So, if there are (say) 10 objects in a bucket. And, one of them > changes. Then, are all 10 objects serialized again? If they are not persistent objects themselves then yes. Laurence ___ 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
On 8 June 2011 10:05, Joe Steeve wrote:
> Hello Charlie,
>
> On Wed, 2011-06-08 at 10:48 +0200, Charlie Clark wrote:
>> 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.
>
> 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 :-/
This looks like self.context is not an instance of a Persistent
subclass. Only Persistent subclasses know how to register their
changes with the ZODB. You see the change on subsequent requests
because the object remains in the object cache, as soon as it's parent
Persistent instance is invalidated, or the server restarted the
changes will disappear. Storing mutable non-persistent objects in the
ZODB requires some care, specifically you need to register the change
on the object's persistent parent. The easiest way to do this is to
assign it to the parent again, e.g. parent['child-name'] = child.
My guess is that the ObjectModifiedEvent is dispatched to your
object's parent and causes something to change there, with the side
effect of storing your updated object.
Laurence
___
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] Metaclass resolution for InterfaceClass
On 1 May 2011 20:28, Laurence Rowe wrote: > While experimenting with my InterfaceClass subclass I noticed that it > was only being used when it was specified as the first of the bases. I > believe this is because InterfaceClass is not a subclass of ``type``, > so the normal metaclass derivation logic is not applied. The attached > patch implements that logic in InterfaceClass.__new__, picking from > the base metaclasses that metaclass which subclasses all other base > metaclasses. I've reported this as https://bugs.launchpad.net/zope.interface/+bug/791218 so it does not get lost. Laurence ___ 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 )
[Zope-dev] Metaclass resolution for InterfaceClass
While experimenting with my InterfaceClass subclass I noticed that it was only being used when it was specified as the first of the bases. I believe this is because InterfaceClass is not a subclass of ``type``, so the normal metaclass derivation logic is not applied. The attached patch implements that logic in InterfaceClass.__new__, picking from the base metaclasses that metaclass which subclasses all other base metaclasses. Laurence metaclass_resolution.diff Description: Binary data ___ 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] Adding a _frame argument to InterfaceClass.__init__ to make it subclassable
On 1 May 2011 01:06, Laurence Rowe wrote: > Hi, > > I'd like to apply the attached patch to zope.interface trunk to make > it more easily subclassable without having to copy and paste a chunk > of its __init__ into the subclass' __init__. On closer inspection, this doesn't seem to be necessary. With python 2.6 when creating a class __module__ is inserted as an attribute. Laurence ___ 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 )
[Zope-dev] Adding a _frame argument to InterfaceClass.__init__ to make it subclassable
Hi, I'd like to apply the attached patch to zope.interface trunk to make it more easily subclassable without having to copy and paste a chunk of its __init__ into the subclass' __init__. Motivating factor is: I need an Interface with a hook that gets called after InterfaceClass.__init__ to allow for: * Checking that field names supplied as tagged values from directives correspond to actual field names to detect typos. * Registering the Interface instance for further configuration to be executed by a zope.configuration action. (Subclass is http://dev.plone.org/plone/browser/plone.supermodel/branches/elro-directives/plone/supermodel/model.py#L52) Laurence InterfaceClass-frame.diff Description: Binary data ___ 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] [Zope2] Multiline response headers causing problems for proxies.
On 18 April 2011 17:01, Laurence Rowe wrote: > When using response.appendHeader, Zope appends the new value following > an ",\r\n\t" which splits the header over multiple lines. While this > behaviour is standards compliant, it causes problems for both Varnish > [1] and Nginx [2] which may then mangle the header value. > > In fact the HTTP 1.0 spec notes that splitting over multiple lines in > not recommended [3], though the HTTP 1.1 spec does not mention this > explicitly, though it does say [4]: > "Applications ought to follow "common form", where one is known or > indicated, when generating HTTP constructs, since there might exist > some implementations that fail to accept anything" > > Are there any objections to me applying the attached patch to Zope > 2.13 and trunk? > > Laurence > > [1] http://www.varnish-cache.org/trac/ticket/905 > [2] http://nginx.org/pipermail/nginx-devel/2011-April/000859.html > [3] http://tools.ietf.org/html/rfc1945#section-4.2 > [4] http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html > I've now applied this to 2.13 and trunk. If it causes any problems, let me know. Laurence ___ 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] [Zope2] Multiline response headers causing problems for proxies.
On 18 April 2011 19:36, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/18/2011 12:01 PM, Laurence Rowe wrote: >> When using response.appendHeader, Zope appends the new value following >> an ",\r\n\t" which splits the header over multiple lines. While this >> behaviour is standards compliant, it causes problems for both Varnish >> [1] and Nginx [2] which may then mangle the header value. >> >> In fact the HTTP 1.0 spec notes that splitting over multiple lines in >> not recommended [3], though the HTTP 1.1 spec does not mention this >> explicitly, though it does say [4]: >> "Applications ought to follow "common form", where one is known or >> indicated, when generating HTTP constructs, since there might exist >> some implementations that fail to accept anything" >> >> Are there any objections to me applying the attached patch to Zope >> 2.13 and trunk? > > +0. We likely need to test that your patch doesn't break stuff on other > maybe-not-compliant servers (older Apache, IIS). I don't think there is any risk of this. Plone's CacheFu has always generated the Cache-Control header as a single line, e.g. "Cache-Control:max-age=0, s-maxage=0, must-revalidate" and that has never caused a problem. The problem only rarely shows up because appendHeader is very rarely called, normally setHeader is used. In fact the only usage of it I could find of appendHeader in my egg cache or the entire Zope2 / Plone is in ZPublisher.HTTPResponse where it is called when gzipping the response (to add 'Accept-Encoding' to the Vary). Even then, it only causes a mulit-line header to be generated when you've already set Vary to something else (for instance Accept-Language.) For servers acting as pure proxies, the header value is opaque, so there is no risk. The only possible way a problem could arise is if they interpret the value in the header. Given that the only time this ever happens is with the Vary header, then only caching proxy servers need worry us. Given that they already cope just fine with the usual ", " delimited list of values in the Cache-Control header, I don't think compatibility issues need worry us here. Laurence ___ 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 )
[Zope-dev] [Zope2] Multiline response headers causing problems for proxies.
When using response.appendHeader, Zope appends the new value following an ",\r\n\t" which splits the header over multiple lines. While this behaviour is standards compliant, it causes problems for both Varnish [1] and Nginx [2] which may then mangle the header value. In fact the HTTP 1.0 spec notes that splitting over multiple lines in not recommended [3], though the HTTP 1.1 spec does not mention this explicitly, though it does say [4]: "Applications ought to follow "common form", where one is known or indicated, when generating HTTP constructs, since there might exist some implementations that fail to accept anything" Are there any objections to me applying the attached patch to Zope 2.13 and trunk? Laurence [1] http://www.varnish-cache.org/trac/ticket/905 [2] http://nginx.org/pipermail/nginx-devel/2011-April/000859.html [3] http://tools.ietf.org/html/rfc1945#section-4.2 [4] http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html appendHeader.patch Description: Binary data ___ 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 )
[Zope-dev] Ensuring at least min_length subwidgets are rendered for the MultiWidget
The attached patch ensures that when in input mode, the MultiWidget will render at least field.min_length subwidgets. This streamlines the add process, currently a user only finds out they need to add to a form when it is submitted and the error message is rendered. They must then make another request to actually get the add subform. I've not contributed much to z3c.form yet, so I wanted to check this approach looked reasonable before committing the patch. Laurence minwidgets.patch Description: Binary data ___ 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] CSRF protection for z3c.form
On 6 April 2011 22:24, Roger wrote: > Hi Laurence > >> Betreff: Re: [Zope-dev] CSRF protection for z3c.form >> >> On 6 April 2011 18:43, Roger wrote: >> > Hi Laurence >> > >> >> Betreff: Re: [Zope-dev] CSRF protection for z3c.form >> >> >> >> On 4 April 2011 19:16, Roger wrote: >> >> > Hi Shane >> >> > >> >> >> -Ursprüngliche Nachricht- >> >> >> Von: Shane Hathaway [mailto:sh...@hathawaymix.org] >> >> >> Gesendet: Montag, 4. April 2011 19:54 >> >> >> An: d...@projekt01.ch >> >> >> Cc: 'Laurence Rowe'; 'zope-dev'; stephan.rich...@gmail.com >> >> >> Betreff: Re: [Zope-dev] CSRF protection for z3c.form >> >> >> >> >> >> On 04/04/2011 10:22 AM, Roger wrote: >> >> >> > Just because you can write login forms with z3c.form this >> >> >> package has >> >> >> > nothing to do with authentication. That's just a form >> framework! >> >> >> > >> >> >> > Authentication is defently not a part of our z3c.form >> >> framework and >> >> >> > should not become one. >> >> >> > >> >> >> > Why do you think authentication has something to do with >> >> >> the z3c.form >> >> >> > library? Did I miss something? >> >> >> >> >> >> This thread is using the word authenticate differently >> than most >> >> >> other Zope-related discussions. Here, we are >> authenticating the >> >> >> *form*, not the user. We need to be sure that >> submitted form data >> >> >> was produced by an authentic form. >> >> >> Otherwise, a crafty site could cause the user's browser >> to invoke >> >> >> some action in the background. >> >> > >> >> > >> >> > I know what you mean. As long as this is not implemented in >> >> z3c.form >> >> > I'm fine Because I don't belive in this kind of protection >> >> since I did >> >> > some very fancy stuff with easyxdm. >> >> >> >> Roger, >> >> >> >> Could you please describe in more detail why you don't believe in >> >> this sort of protection? As far as I can see the easyxdv messaging >> >> stuff requires supporting javascript to be executed in the >> context of >> >> both documents, so modulo any javascript injection >> vulnerabilities, >> >> it has no impact on the efficacy of form authenticators. >> > >> > I think to protect the form is just a part of a concept. >> > Another part must be to prevent to inject JavaScript in >> user generated >> > content. If an application allows to post JS in a blog post >> or comment >> > etc. it should be possible to use easydmx to read and re-use the >> > secure form token. >> > (not approved but should work) >> > >> > One of my bigger concern is also that such a token will >> break a lot of >> > our tests which whould force us to use custom non security token >> > generating form classes. >> > >> > I'm fine in general for implement such a concept in z3c.form but it >> > should be optional. >> > Why not offer additional form classes or a mixin for support such >> > token? >> >> I intend to make it pluggable, either using an existing plug >> point or creating a new one. >> >> I think it's important that this can be easily retrofitted to >> all z3c.form based forms on a site, so I don't want to have >> to rely on all forms (which may come from other add-ons) >> needing to inherit from a particular base class. > > Ok, it starts making sense to me. > > What do you think about a class property like we us in fomr classes > like ignoreContext, ignoreRequest, ignoreReadonly: > > ignoreProtection = True/False > > and set it by default to True? Or even to False and we can simply > set it to True if test will fail because of changed form source? My current thinking is a modification of my first proposal above:: def update(self): super(Form, self).update() self.updateActions() self.authenticateSubmission() self.actions.execute() if self.refreshActions: self.updateActions() def authenticateSubmission(self): if self.actions.executedActions: authenticators = zope.component.getAdapters( (self, self.request, self.getContent()), interfaces.ISubmissionAuthenticator) for authenticator in authenticators: authenticator.authenticate() This would allow for multiple authenticators to be registered as named adapters, for instance PostOnly, CheckAuthenticationToken, CheckCaptcha. Laurence ___ 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] CSRF protection for z3c.form
On 6 April 2011 18:43, Roger wrote: > Hi Laurence > >> Betreff: Re: [Zope-dev] CSRF protection for z3c.form >> >> On 4 April 2011 19:16, Roger wrote: >> > Hi Shane >> > >> >> -Ursprüngliche Nachricht- >> >> Von: Shane Hathaway [mailto:sh...@hathawaymix.org] >> >> Gesendet: Montag, 4. April 2011 19:54 >> >> An: d...@projekt01.ch >> >> Cc: 'Laurence Rowe'; 'zope-dev'; stephan.rich...@gmail.com >> >> Betreff: Re: [Zope-dev] CSRF protection for z3c.form >> >> >> >> On 04/04/2011 10:22 AM, Roger wrote: >> >> > Just because you can write login forms with z3c.form this >> >> package has >> >> > nothing to do with authentication. That's just a form framework! >> >> > >> >> > Authentication is defently not a part of our z3c.form >> framework and >> >> > should not become one. >> >> > >> >> > Why do you think authentication has something to do with >> >> the z3c.form >> >> > library? Did I miss something? >> >> >> >> This thread is using the word authenticate differently than most >> >> other Zope-related discussions. Here, we are authenticating the >> >> *form*, not the user. We need to be sure that submitted form data >> >> was produced by an authentic form. >> >> Otherwise, a crafty site could cause the user's browser to invoke >> >> some action in the background. >> > >> > >> > I know what you mean. As long as this is not implemented in >> z3c.form >> > I'm fine Because I don't belive in this kind of protection >> since I did >> > some very fancy stuff with easyxdm. >> >> Roger, >> >> Could you please describe in more detail why you don't >> believe in this sort of protection? As far as I can see the >> easyxdv messaging stuff requires supporting javascript to be >> executed in the context of both documents, so modulo any >> javascript injection vulnerabilities, it has no impact on the >> efficacy of form authenticators. > > I think to protect the form is just a part of a concept. > Another part must be to prevent to inject JavaScript in > user generated content. If an application allows to post > JS in a blog post or comment etc. it should be possible to > use easydmx to read and re-use the secure form token. > (not approved but should work) > > One of my bigger concern is also that such a token will > break a lot of our tests which whould force us to use > custom non security token generating form classes. > > I'm fine in general for implement such a concept > in z3c.form but it should be optional. > Why not offer additional form classes or a mixin > for support such token? I intend to make it pluggable, either using an existing plug point or creating a new one. I think it's important that this can be easily retrofitted to all z3c.form based forms on a site, so I don't want to have to rely on all forms (which may come from other add-ons) needing to inherit from a particular base class. Laurence ___ 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] CSRF protection for z3c.form
On 6 April 2011 18:52, Roger wrote: > Hi Laurence > >> Betreff: Re: [Zope-dev] CSRF protection for z3c.form >> >> On 4 April 2011 16:53, Stephan Richter >> wrote: >> > On Monday, April 04, 2011, Laurence Rowe wrote: >> >> The authenticator is described on >> >> http://pypi.python.org/pypi/plone.protect, but basically >> it adds an >> >> HMAC-SHA signed token into the form submission. By validating this >> >> you know that the submission came from a form that your site >> >> rendered, rather than an opportunistic 'drive-by' attack >> from another site. >> > >> > So why don't we make this a built-in feature then? The >> token manager >> > (I think you call it the authenticator) needs to be smart, since it >> > needs to deal with stale tokens and similar issues, but >> otherwise we >> > could just add an authentication mechanism into z3c.form. >> > >> > Mmh, if the token gets stored in the session variable, then >> we do not >> > even have to worry about token management, since the >> session container >> > has already that logic. >> > >> > I have a feeling I am missing a level of complexity here... >> >> There should be no need to store anything in sessions, it >> really is as simple as ensuring that you include a signed >> token in the form submission that is separate from the user >> session identifier (as cookies get posted automatically on >> any form submission.) >> >> >> I'm happy to go with (3). I assume it is not common for z3c.form >> >> users to have non-button actions or customize the >> ButtonActionHandler? >> > >> > Not in my experience. >> >> In that case I will attempt to implement it in plone.z3cform >> first as that will allow me to just reuse the existing >> plone.protect stuff. My only concern really is how easy it >> will be to disable for individual forms - as I think it's >> important to have protection by default. I'm hoping that the >> following will work: >> >> * Register a ProtectedButtonActionHandler on >> z3c.form.form.Form (to be more specific than the default >> ButtonActionHandler registered on the IForm interface.) >> >> * Register the default ButtonActionHandler on a >> IUnprotectedForm interface, which individual forms can >> provide if they need to accept submissions from other sites. >> >> For a more general z3c.form protection scheme we can then >> look at making the zope2 dependencies in plone.protect >> optional. I would also like to change the token format of >> plone.protect to include the issue time, so secrets do not >> need to be rotated to invalidate old tokens, much as >> plone.session now does: >> http://pypi.python.org/pypi/plone.session > > Does this (optimized) session concept work with (robin arround) > load balanced servers? Yes, it has nothing to do with Zope sessions. You can share it between multiple systems by setting the same shared secret on each one. (In plone.session the secret is stored in the ZODB, so you only need to set a shared secret when you want to share login cookies between multiple plone sites or with other systems.) > Probably I don't understand some parts of the form token. > Does the form generate random tokens or allways the same? A token is generated containing the current user and the time when the form is rendered, or in the plone.session case when the user logs in. The token is securely signed using the secret, so it can be subsequently validated. The time is used to limit validity to say 12 hours (or less if you are feeling paranoid.) Laurence ___ 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] CSRF protection for z3c.form
On 4 April 2011 16:53, Stephan Richter wrote: > On Monday, April 04, 2011, Laurence Rowe wrote: >> The authenticator is described on >> http://pypi.python.org/pypi/plone.protect, but basically it adds an >> HMAC-SHA signed token into the form submission. By validating this you >> know that the submission came from a form that your site rendered, >> rather than an opportunistic 'drive-by' attack from another site. > > So why don't we make this a built-in feature then? The token manager (I think > you call it the authenticator) needs to be smart, since it needs to deal with > stale tokens and similar issues, but otherwise we could just add an > authentication mechanism into z3c.form. > > Mmh, if the token gets stored in the session variable, then we do not even > have to worry about token management, since the session container has already > that logic. > > I have a feeling I am missing a level of complexity here... There should be no need to store anything in sessions, it really is as simple as ensuring that you include a signed token in the form submission that is separate from the user session identifier (as cookies get posted automatically on any form submission.) >> I'm happy to go with (3). I assume it is not common for z3c.form users >> to have non-button actions or customize the ButtonActionHandler? > > Not in my experience. In that case I will attempt to implement it in plone.z3cform first as that will allow me to just reuse the existing plone.protect stuff. My only concern really is how easy it will be to disable for individual forms - as I think it's important to have protection by default. I'm hoping that the following will work: * Register a ProtectedButtonActionHandler on z3c.form.form.Form (to be more specific than the default ButtonActionHandler registered on the IForm interface.) * Register the default ButtonActionHandler on a IUnprotectedForm interface, which individual forms can provide if they need to accept submissions from other sites. For a more general z3c.form protection scheme we can then look at making the zope2 dependencies in plone.protect optional. I would also like to change the token format of plone.protect to include the issue time, so secrets do not need to be rotated to invalidate old tokens, much as plone.session now does: http://pypi.python.org/pypi/plone.session Laurence ___ 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] CSRF protection for z3c.form
On 4 April 2011 19:16, Roger wrote: > Hi Shane > >> -Ursprüngliche Nachricht- >> Von: Shane Hathaway [mailto:sh...@hathawaymix.org] >> Gesendet: Montag, 4. April 2011 19:54 >> An: d...@projekt01.ch >> Cc: 'Laurence Rowe'; 'zope-dev'; stephan.rich...@gmail.com >> Betreff: Re: [Zope-dev] CSRF protection for z3c.form >> >> On 04/04/2011 10:22 AM, Roger wrote: >> > Just because you can write login forms with z3c.form this >> package has >> > nothing to do with authentication. That's just a form framework! >> > >> > Authentication is defently not a part >> > of our z3c.form framework and should not become one. >> > >> > Why do you think authentication has something to do with >> the z3c.form >> > library? Did I miss something? >> >> This thread is using the word authenticate differently than >> most other Zope-related discussions. Here, we are >> authenticating the *form*, not the user. We need to be sure >> that submitted form data was produced by an authentic form. >> Otherwise, a crafty site could cause the user's browser to >> invoke some action in the background. > > > I know what you mean. As long as this is not implemented > in z3c.form I'm fine Because I don't belive in this > kind of protection since I did some very fancy stuff > with easyxdm. Roger, Could you please describe in more detail why you don't believe in this sort of protection? As far as I can see the easyxdv messaging stuff requires supporting javascript to be executed in the context of both documents, so modulo any javascript injection vulnerabilities, it has no impact on the efficacy of form authenticators. Laurence ___ 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] CSRF protection for z3c.form
On 4 April 2011 14:57, Stephan Richter wrote: > On Monday, April 04, 2011, Laurence Rowe wrote: >> I'd be interested to know how other z3c.form users approach CSRF protection >> and what approach they would recommend. > > Hi Lawrence, > > I am okay with (1), but find (3) ore attractive. Since I am not familiar with > the token solution to avoid CSRF attacks, can you briefly describe the > sequence > that is used to avoid those requests? Maybe we can some up with a tightly > integrated solution. I have no problem with modifying z3c.form to support such > a feature. Hi Stephen, The authenticator is described on http://pypi.python.org/pypi/plone.protect, but basically it adds an HMAC-SHA signed token into the form submission. By validating this you know that the submission came from a form that your site rendered, rather than an opportunistic 'drive-by' attack from another site. I'm happy to go with (3). I assume it is not common for z3c.form users to have non-button actions or customize the ButtonActionHandler? Laurence ___ 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 )
[Zope-dev] CSRF protection for z3c.form
I've been looking into how we might add CSRF protection to z3c.form forms as we will be including z3c.form in Plone 4.1. Currently in Plone, we use plone.protect to add an authentication token to our forms and then check the token in the methods that get called. (plone.protect is BSD licensed, but is Zope2 specific.) I think it's important for the integrator to be able to add an authentication policy to all z3c.form forms on a site, so I'd rather not rely on having all forms subclass some AuthenticatedForm. I can see a number of possible ways to implement this 1. Add a hook into z3c.form.form.Form along the lines of:: def update(self): super(Form, self).update() self.updateActions() self.authenticateSubmission() self.actions.execute() if self.refreshActions: self.updateActions() def authenticateSubmission(self): if self.actions.executedActions: authenticator = zope.component.queryMultiAdapter( (self, self.request, self.getContent()), interfaces.ISubmissionAuthenticator) if authenticator is not None: authenticator.authenticate() This would allow integrators to register an ISubmissionAuthenticator that would be called when there are actions to execute (so not when a form is just displayed.) 2. Similar to (1) but fire an event. This would allow multiple submission authenticators to be registered (e.g. for post-only as well as check-authenticator), but this makes it more difficult to restrict authenticators to only certain forms / requests / contexts. 3. Register a more specific version of z3c.form.button.ButtonActionsHandler which performs the check before executing the handler. This has the advantage of not requiring any changes to z3c.form, but the disadvantages that: only button actions are protected, and would be executed per action handler execution instead of once per submission. I'd be interested to know how other z3c.form users approach CSRF protection and what approach they would recommend. Laurence ___ 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 Tests: 109 OK, 24 Failed, 4 Unknown
On 31 March 2011 10:15, Gediminas Paulauskas wrote: > 2011/3/23 Laurence Rowe : >> On 23 March 2011 14:43, Tres Seaver wrote: >>> Multiple 'Content-Length' headers is definitely a Bad Thing. I filed a >>> bug, which Mark Ramm has promised to escalate: >>> >>> https://sourceforge.net/apps/trac/sourceforge/ticket/18486 >>> >>> I have a patch for setuptools which works around it: >>> >>> http://bugs.python.org/setuptools/issue123 >>> >>> I'm not sure how to work around the issue at the moment. >> >> I always add the following to my buildout.cfg to avoid problems with >> random third party servers: >> >> allow-hosts = >> *.python.org >> *.plone.org >> launchpad.net >> >> (launchpad.net is there only for mocker which does not have a pypi release). > > I have added the following sites to allow-hosts for SchoolTool, that > needs Sphinx, Pygments, PIL, reportlab, pyPdf, Paste. > > allow-hosts = > buildout.org > code.google.com > effbot.org > *.googlecode.com > pybrary.net > pygments.org > *.python.org > pythonpaste.org > *.pythonware.com > *.pocoo.org > reportlab.com > *.repoze.org > *.schooltool.org > > Not all sites are needed, but why block projects official downloads? Limiting your allowed hosts to the minimal set makes running buildout much faster as most of the network requests get blocked. Laurence ___ 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] SVN: Zope/trunk/ Adding support for ``IStreamIterator`` to WSGI publishing machinery.
On 26 March 2011 17:14, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 03/26/2011 12:53 PM, Malthe Borch wrote: >> Log message for revision 121131: >> Adding support for ``IStreamIterator`` to WSGI publishing machinery. >> >> Changed: >> U Zope/trunk/doc/CHANGES.rst >> U Zope/trunk/src/ZPublisher/WSGIPublisher.py >> U Zope/trunk/src/ZPublisher/tests/test_WSGIPublisher.py >> >> -=- >> Modified: Zope/trunk/doc/CHANGES.rst >> === >> --- Zope/trunk/doc/CHANGES.rst 2011-03-25 17:39:14 UTC (rev 121130) >> +++ Zope/trunk/doc/CHANGES.rst 2011-03-26 16:53:52 UTC (rev 121131) >> @@ -11,6 +11,10 @@ >> Bugs Fixed >> ++ >> >> +- Fix `WSGIResponse` and `publish_module` functions such that they >> + support the `IStreamIterator` interface in addition to `file` (as >> + supported by `ZServer.HTTPResponse`). >> + >> - Made sure getConfiguration().default_zpublisher_encoding is set correctly. >> >> - LP #713253: Prevent publication of acquired attributes, where the acquired >> >> Modified: Zope/trunk/src/ZPublisher/WSGIPublisher.py >> === >> --- Zope/trunk/src/ZPublisher/WSGIPublisher.py 2011-03-25 17:39:14 >> UTC (rev 121130) >> +++ Zope/trunk/src/ZPublisher/WSGIPublisher.py 2011-03-26 16:53:52 >> UTC (rev 121131) >> @@ -30,6 +30,7 @@ >> from ZPublisher.Publish import dont_publish_class >> from ZPublisher.Publish import get_module_info >> from ZPublisher.Publish import missing_name >> +from ZPublisher.Iterators import IStreamIterator >> >> _NOW = None # overwrite for testing >> def _now(): >> @@ -125,7 +126,7 @@ >> self.stdout.write(data) >> >> def setBody(self, body, title='', is_error=0): >> - if isinstance(body, file): >> + if isinstance(body, file) or IStreamIterator.providedBy(body): >> body.seek(0, 2) >> length = body.tell() >> body.seek(0) > > This part of the patch can't possibly work in the general case: nothing > in IStreamIterator promises that 'seek' and 'tell' are available. In plone.subrequest, I need similar functionality. I ended up checking for seek before calling it and special casing a plone.app.blob iterator. http://dev.plone.org/plone/browser/plone.subrequest/trunk/plone/subrequest/subresponse.py Perhaps we want an extended sub-interface for IFileStreamIterator which defines seek(), tell() and read()? Laurence ___ 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 Tests: 109 OK, 24 Failed, 4 Unknown
On 23 March 2011 14:43, Tres Seaver wrote: > Multiple 'Content-Length' headers is definitely a Bad Thing. I filed a > bug, which Mark Ramm has promised to escalate: > > https://sourceforge.net/apps/trac/sourceforge/ticket/18486 > > I have a patch for setuptools which works around it: > > http://bugs.python.org/setuptools/issue123 > > I'm not sure how to work around the issue at the moment. I always add the following to my buildout.cfg to avoid problems with random third party servers: allow-hosts = *.python.org *.plone.org launchpad.net (launchpad.net is there only for mocker which does not have a pypi release). Laurence ___ 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] ZPublisher: using zope.formlib and z3c.form in Zope 2
On 2 March 2011 11:29, yuppie wrote: > Laurence Rowe wrote: >> On 2 March 2011 10:00, yuppie wrote: >>> Martin Aspeli wrote: >>>> I don't know what setPageEncoding() does, though. >>> >>> It sets a response Content-Type header with the first charset >>> processInputs tries for decoding. >> >> Is the charset of the request necessarily the right choice for the >> response? In Plone we always serve UTF-8 encoded. > > getPreferredCharsets()[0] always returns 'utf-8' **if** UTF-8 is accepted. > > If 'utf-8' is not in getPreferredCharsets(), it is not very likely that > the browser speaks UTF-8 and processInputs will not even try to decode > with UTF-8. In that case it might be better to respond with an accepted > encoding. If you serve differently encoded pages then you should set Vary: Accept-Charset. But then without normalization you'd get an explosion of different page variations. Without the Vary, it means that a visitor can poison the cache by supplying (only) a weird charset in Accept-Encoding. The page would then be served in this encoding, cached downstream, and if other visitor's browsers don't support that charset then they have a problem. Laurence ___ 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] ZPublisher: using zope.formlib and z3c.form in Zope 2
On 2 March 2011 10:00, yuppie wrote: > Hi Martin! > > > Martin Aspeli wrote: >>> - After traversal and before calling the object >>> ZPublisher.Publish.publish should figure out if the object expects >>> zope.publisher behavior. Either we use a new interface for this or we >>> use zope.publisher.interfaces.browser.IBrowserPage: AFAICS in Zope 2 >>> land only zope.formlib and z3c.form based views implement IBrowserPage. >> >> Isn't this in zope.browserpage now? > > No. > >>> - plone.z3cform uses a modified version of processInputs and doesn't use >>> setPageEncoding. Can anybody explain why? I guess that are no z3c.form >>> specific reasons. Maybe the changes can be merged back to Zope? >> >> processInputs() in Five was very buggy. I thought I'd merged those >> changes into Zope 2? > > Well. You were the last person who touched both. But the changes are > quit different: > > http://svn.zope.org/Zope/trunk/src/Products/Five/browser/decode.py?rev=115280&view=log > http://svn.zope.org/plone.z3cform/trunk/plone/z3cform/z2.py?rev=109071&view=log > > Is there still anything in plone.z3cform that should be merged into Zope 2? > >> I don't know what setPageEncoding() does, though. > > It sets a response Content-Type header with the first charset > processInputs tries for decoding. Is the charset of the request necessarily the right choice for the response? In Plone we always serve UTF-8 encoded. Laurence ___ 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] string exceptions
On 25 February 2011 11:14, Godefroid Chapelle wrote: > Le 25/02/11 12:03, Hanno Schlichting a écrit : >>> I find a few string exceptions leftover in Zope 2.13 code. >>> > >>> > What practice has been followed until now regarding fixing those >>> > exceptions ? >> Just upgrade them to new-style exception classes. Since string >> exceptions cannot possibly work anymore, we cannot make things worse >> by fixing them. >> >> Hanno > > What about deciding to kill that code ? > > I guess it is a bit early because not enough people did migrate to 2.12 > or later. These statements now raise a TypeError instead of a string exceotion, which in most cases should be functionally equivalent. There's no guarantee that the code is dead. > Where should those fixes happen ? > > 2.13 branch and trunk I suppose This seems sensible. Laurence ___ 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] string exceptions
On 25 February 2011 11:09, Godefroid Chapelle wrote: > Le 25/02/11 12:03, Laurence Rowe a écrit : >> >> On 25 February 2011 10:58, Godefroid Chapelle wrote: >>> >>> Hi, >>> >>> I find a few string exceptions leftover in Zope 2.13 code. >>> >>> However, they are not allowed anymore in Python 2.6. >>> >>> I guess that the remaining string exceptions are in dead/semidead code. >>> >>> What practice has been followed until now regarding fixing those >>> exceptions ? >> >> According to this doc, >> >> http://docs.python.org/c-api/exceptions.html#deprecation-of-string-exceptions >> >> "String exceptions are still supported in the interpreter to allow >> existing code to run unmodified, but this will also change in a future >> release." >> >> It will of course be important to fix these before we move to Python >> 3.x, but I would expect that the dead/semidead code will not be >> ported. >> >> Laurence > > I just tried to run the code hereunder with Python 2.6.5: > > def main(): > raise "Abc" > > main() > > This is what I get : > > Traceback (most recent call last): > File "test.py", line 4, in > main() > File "test.py", line 2, in main > raise "Abc" > TypeError: exceptions must be old-style classes or derived from > BaseException, not str > > I am not sure what the documentation above means but it seems to be text > that was not fixed... Reported in http://bugs.python.org/issue11317 Laurence ___ 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] string exceptions
On 25 February 2011 11:03, Laurence Rowe wrote: > On 25 February 2011 10:58, Godefroid Chapelle wrote: >> Hi, >> >> I find a few string exceptions leftover in Zope 2.13 code. >> >> However, they are not allowed anymore in Python 2.6. >> >> I guess that the remaining string exceptions are in dead/semidead code. >> >> What practice has been followed until now regarding fixing those >> exceptions ? > > According to this doc, > http://docs.python.org/c-api/exceptions.html#deprecation-of-string-exceptions > > "String exceptions are still supported in the interpreter to allow > existing code to run unmodified, but this will also change in a future > release." > > It will of course be important to fix these before we move to Python > 3.x, but I would expect that the dead/semidead code will not be > ported. I take that back, that documentation is incorrect, they have indeed stopped working. Laurence ___ 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] string exceptions
On 25 February 2011 10:58, Godefroid Chapelle wrote: > Hi, > > I find a few string exceptions leftover in Zope 2.13 code. > > However, they are not allowed anymore in Python 2.6. > > I guess that the remaining string exceptions are in dead/semidead code. > > What practice has been followed until now regarding fixing those > exceptions ? According to this doc, http://docs.python.org/c-api/exceptions.html#deprecation-of-string-exceptions "String exceptions are still supported in the interpreter to allow existing code to run unmodified, but this will also change in a future release." It will of course be important to fix these before we move to Python 3.x, but I would expect that the dead/semidead code will not be ported. Laurence ___ 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] [ZODB-Dev] transaction as context manager, exception during commit
On 24 February 2011 10:17, Chris Withers wrote: > Hi Jim, > > The current __exit__ for transaction managers looks like this: > > def __exit__(self, t, v, tb): > if v is None: > self.commit() > else: > self.abort() > > ..which means that if you're using the transaction package as a context > manager and, say, a relational database integrity constraint is > violated, then you're left with a hosed transaction that still needs > aborting. > > How would you feel about the above changing to: > > def __exit__(self, t, v, tb): > if v is None: > try: > self.commit() > except: > self.abort() > raise > else: > self.abort() > > If this is okay, I'll be happy to write the tests and make the changes > provided someone does a release when I have... Looking at the way ZPublisher handles this, I think you're right. I think you might also need to modify the __exit__ in Attempt, which additionally handles retrying transactions that fail. Laurence ___ 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 )
[Zope-dev] Time for a z3c.blobfile release
There have been a couple of fixes to z3c.blobfile. Would one of the package owners (uoestermeier, nadako) be able to make a new release to pypi? Thanks! Laurence ___ 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 2: specifying Zope2 dependency
On 4 January 2011 17:42, Laurence Rowe wrote:
> On 4 January 2011 13:00, yuppie wrote:
>> Hi!
>>
>>
>> Zope trunk (2.14) no longer ships with these Products:
>>
>> Products.BTreeFolder2
>> Products.ExternalMethod
>> Products.MailHost
>> Products.MIMETools
>> Products.PythonScripts
>> Products.StandardCacheManagers
>>
>> There are no separate Zope 2.12 compatible eggs for these Products
>> because they are part of the Zope2 2.12.X eggs.
>>
>> Problem is: Several Products (e.g. CMF) exist that depend on these
>> Products and want to support Zope2 2.12, 2.13 and trunk. But AFAICS
>> there is no way to specify all dependencies correctly in setup.py. As a
>> workaround, CMF currently specifies the 'additional' Zope2 trunk
>> dependencies in buildout.cfg.
>>
>>
>> If there are no objections or better ideas, I'd like to add a
>> 'zope212_compat' extra to Zope 2.12, 2.13 and trunk. For Zope 2.12 and
>> 2.13 it would be empty, for trunk it would look like this:
>>
>> extras_require={
>> 'zope212_compat': [
>> 'Products.BTreeFolder2',
>> 'Products.ExternalMethod',
>> 'Products.MailHost',
>> 'Products.MIMETools',
>> 'Products.PythonScripts',
>> 'Products.StandardCacheManagers',
>> ],
>>
>> That would make it possible to specify the Zope2 dependency this way:
>>
>> install_requires=[
>> 'Zope2 [zope212_compat] >= 2.12.15',
>> ]
>>
>> If Products drop Zope 2.12 support, they can switch to this:
>>
>> install_requires=[
>> 'Zope2 >= 2.13.0',
>> 'Products.MailHost', # required Products
>
> You could release empty eggs for those folders. This is the approach
> we are taking with the separation of Products.CMFPlone from the Plone
> egg. This allows software to depend on ``Products.CMFPlone`` now but
> still be compatible with Plone 4.0. See:
> http://dev.plone.org/plone/browser/Products.CMFPlone/branches/4.0. (A
> Products.CMFPlone=4.0 pin will be included the versions.cfg for the
> next 4.0.x release.)
... empty eggs for those /packages/ ...
Laurence
___
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 2: specifying Zope2 dependency
On 4 January 2011 13:00, yuppie wrote:
> Hi!
>
>
> Zope trunk (2.14) no longer ships with these Products:
>
> Products.BTreeFolder2
> Products.ExternalMethod
> Products.MailHost
> Products.MIMETools
> Products.PythonScripts
> Products.StandardCacheManagers
>
> There are no separate Zope 2.12 compatible eggs for these Products
> because they are part of the Zope2 2.12.X eggs.
>
> Problem is: Several Products (e.g. CMF) exist that depend on these
> Products and want to support Zope2 2.12, 2.13 and trunk. But AFAICS
> there is no way to specify all dependencies correctly in setup.py. As a
> workaround, CMF currently specifies the 'additional' Zope2 trunk
> dependencies in buildout.cfg.
>
>
> If there are no objections or better ideas, I'd like to add a
> 'zope212_compat' extra to Zope 2.12, 2.13 and trunk. For Zope 2.12 and
> 2.13 it would be empty, for trunk it would look like this:
>
> extras_require={
> 'zope212_compat': [
> 'Products.BTreeFolder2',
> 'Products.ExternalMethod',
> 'Products.MailHost',
> 'Products.MIMETools',
> 'Products.PythonScripts',
> 'Products.StandardCacheManagers',
> ],
>
> That would make it possible to specify the Zope2 dependency this way:
>
> install_requires=[
> 'Zope2 [zope212_compat] >= 2.12.15',
> ]
>
> If Products drop Zope 2.12 support, they can switch to this:
>
> install_requires=[
> 'Zope2 >= 2.13.0',
> 'Products.MailHost', # required Products
You could release empty eggs for those folders. This is the approach
we are taking with the separation of Products.CMFPlone from the Plone
egg. This allows software to depend on ``Products.CMFPlone`` now but
still be compatible with Plone 4.0. See:
http://dev.plone.org/plone/browser/Products.CMFPlone/branches/4.0. (A
Products.CMFPlone=4.0 pin will be included the versions.cfg for the
next 4.0.x release.)
Laurence
___
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] SVN: zope.interface/branches/jinty-mem/src/zope/interface/interface.py Improve CPU performance of previous memory optimization
On 9 November 2010 18:35, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/09/2010 08:26 AM, Wichert Akkerman wrote:
>> On 11/9/10 14:22 , Brian Sutherland wrote:
>>> Log message for revision 118295:
>>> Improve CPU performance of previous memory optimization
>>>
>>> Changed:
>>> U zope.interface/branches/jinty-mem/src/zope/interface/interface.py
>>>
>>> -=-
>>> Modified: zope.interface/branches/jinty-mem/src/zope/interface/interface.py
>>> ===
>>> --- zope.interface/branches/jinty-mem/src/zope/interface/interface.py
>>> 2010-11-09 08:31:37 UTC (rev 118294)
>>> +++ zope.interface/branches/jinty-mem/src/zope/interface/interface.py
>>> 2010-11-09 13:22:27 UTC (rev 118295)
>>> @@ -51,6 +51,7 @@
>>> # infrastructure in place.
>>> #
>>> #implements(IElement)
>>> + __tagged_values = None
>>>
>>> def __init__(self, __name__, __doc__=''):
>>> """Create an 'attribute' description
>>> @@ -72,22 +73,27 @@
>>>
>>> def getTaggedValue(self, tag):
>>> """ Returns the value associated with 'tag'. """
>>> - return getattr(self, '_Element__tagged_values', {})[tag]
>>> + if self.__tagged_values is None:
>>> + return default
>>> + return self.__tagged_values[tag]
>>
>> You can even optimise this further:
>>
>> tv = self.__tagged_values
>> if tv is None:
>> return default
>> return tv[tv]
>>
>> that avoids a second attribute lookup. You may also want to benchmark
>> that versus using a __tagged_values={} on the class and doing a simple
>> return self.__tagged_values.get(tag, default_
>
> - -1: mutable class defaults are a bug magnet.
None is immutable so I don't think that is a problem in this case.
I think the is a possible threading issue with Element.setTaggedValue
and Specification.subscribe - if two threads called the method
concurrently, then one of the values might be lost. I think the
correct way to do it would be:
tv = self.__tagged_values
if tv is None:
tv = self.__dict__.setdefault('_Element__tagged_values', {})
tv[tag] = value
This does bring the name mangling back though.
Laurence
___
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] Functional areas of Zope
On 18 October 2010 12:51, Thomas Lotze wrote: > Hi all, > > at the Zope summit in September, we were talking about what Zope > actually is or should be and how to define the goal of the Zope > project. This led to the idea of identifying the functional areas > of Zope. I'd like to pursue this by starting a discussion about > Zope's functional areas among the developer community and hope to > come up with a number of commonly agreed-upon items. Wherever it > matters, I suggest limiting ourselves to discussing the ZTK in > order to keep things focussed. > > As functional areas (for some examples, see below), we consider > diverse, broadly defined tasks and problems that a web developer > is being faced with, and that a web framework ought to have an > answer for. We hope to be able to define better what Zope is and > is not and how it compares to other web frameworks by starting > from a set of functional areas and trying to state Zope's answer > to each of them. > > Another benefit from having a grip on functional areas of Zope > the project would be the possibility to organise the large and > grown set of individual packages that make up Zope's code. > > To get the discussion started, I'll give a few random examples of > functional areas that we thought of immediately: > > - software architecture (interfaces, components) > - data persistence (ZODB) > - URL resolution (object traversal) > - form generation (form libs for HTML forms, other possibilities?) > - resource handling (CSS, Javascript delivery) > - client-side programming framework (no good solution so far, people use > all sorts of Javascript technologies and programming styles) I would say that javascript and client side programming frameworks are out of scope for Zope the project. There are plenty of existing client side frameworks (jquery, YUI, etc.) with varying degrees of weight and functionality. We don't want to build another. Zope components may need to implement some rich functionality (form widgets for instance), in which case it may be worthwhile picking a particular javascript framework to use (Plone uses jquery). We also want to make it easy to communicate between client side javascript and server side python via JSON (bobo implmented some json help classes IIRC). Laurence ___ 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] PAS CookieAuthHelper and insufficient privileges
On 13 October 2010 17:16, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 10/11/2010 08:21 PM, Laurence Rowe wrote: >> I'm currently implementing single sign on across Plone sites but have >> run into a bit of an issue with the CookieAuthHelper. >> >> Unauthorized accesses are redirected to its login_path attribute even >> when a user is already logged in. Plone works around this with a >> require_login script that traverses to insufficient_privileges (rather >> than login_form) when the user is not anonymous. >> http://dev.plone.org/plone/browser/Plone/trunk/Products/CMFPlone/skins/plone_login/require_login.py >> >> I'd like to avoid having two redirects (one to require_login and then >> one to the remote login page). >> >> One option (as suggested in require_login.py) would be to have >> CookieAuthHelper traverse rather than redirect to the login_path so >> that sites could override the behaviour, though they would then >> presumably need to duplicate the functionality currently in >> CookieAuthHelper.unauthorized (which I must admit to only barely >> understanding...) >> http://zope3.pov.lt/trac/browser/Products.PluggableAuthService/trunk/Products/PluggableAuthService/plugins/CookieAuthHelper.py >> >> Instead, it would seem to make sense to move this functionality login >> / insufficient privileges functionality into the CookieAuthHelp >> itself. I could add an insufficient_privs_path and redirect there >> instead of login_path when a user is already authorized. >> >> Yet another option would be to let logged in unauthorized to percolate >> up and implement that page with an error view. >> >> Any opinions? I'm leaning towards adding an insufficient_privs_path as >> it seems simplest and least invasive. (When not set it would just use >> login_path as normal). > > Please do this kind of disruptive change in a *new* plugin, perhaps > subclassed from the existing one. The whole point of plugins in the > first place was to allow for folks with different needs to handle them > by replacement. I'd be interested to hear how other PAS users deal with this issue - showing an insufficient privileges page rather than a login form to already logged in users seems a common requirement. Would you consider adding an optional insufficient_privs_path to CookieAuthHelper a disruptive change? (Assuming it defaulted to the current behaviour when set to a default ''.) Making plone.session's SessionPlugin subclass CookieAuthHelper rather than work in concert with it would certainly be an option if that was thought preferable. (Keeping this thread on this list rather than starting a new one on Zope-PAS. Is the Zope-PAS list still alive or does it come under the list rationalization that's been discussed? Two comments from Wichert in the last year on checkin messages, no discussion.) Laurence ___ 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] PAS CookieAuthHelper and insufficient privileges
On 12 October 2010 08:39, Wichert Akkerman wrote: > On 10/12/10 02:21 , Laurence Rowe wrote: >> >> I'm currently implementing single sign on across Plone sites but have >> run into a bit of an issue with the CookieAuthHelper. >> >> Unauthorized accesses are redirected to its login_path attribute even >> when a user is already logged in. Plone works around this with a >> require_login script that traverses to insufficient_privileges (rather >> than login_form) when the user is not anonymous. >> >> http://dev.plone.org/plone/browser/Plone/trunk/Products/CMFPlone/skins/plone_login/require_login.py > > The result is still nasty since it means the unauthorized error will always > consider the user to be unauthenticated. I've implemented a workaround in > NuPlone to fix that, see > http://svn.plone.org/svn/collective/NuPlone/trunk/plonetheme/nuplone/skin/error.py > . Perhaps something based on that will work for you as well. That doesn't seem to be the case when I dropped a pdb into CookieAuthHelper.unauthorized: > /data/devel/plone/4.1/src/Products.PluggableAuthService/Products/PluggableAuthService/plugins/CookieAuthHelper.py(184)unauthorized() -> import pdb; pdb.set_trace() (Pdb) from AccessControl.SecurityManagement import getSecurityManager (Pdb) getSecurityManager().getUser() Laurence ___ 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 )
[Zope-dev] PAS CookieAuthHelper and insufficient privileges
I'm currently implementing single sign on across Plone sites but have run into a bit of an issue with the CookieAuthHelper. Unauthorized accesses are redirected to its login_path attribute even when a user is already logged in. Plone works around this with a require_login script that traverses to insufficient_privileges (rather than login_form) when the user is not anonymous. http://dev.plone.org/plone/browser/Plone/trunk/Products/CMFPlone/skins/plone_login/require_login.py I'd like to avoid having two redirects (one to require_login and then one to the remote login page). One option (as suggested in require_login.py) would be to have CookieAuthHelper traverse rather than redirect to the login_path so that sites could override the behaviour, though they would then presumably need to duplicate the functionality currently in CookieAuthHelper.unauthorized (which I must admit to only barely understanding...) http://zope3.pov.lt/trac/browser/Products.PluggableAuthService/trunk/Products/PluggableAuthService/plugins/CookieAuthHelper.py Instead, it would seem to make sense to move this functionality login / insufficient privileges functionality into the CookieAuthHelp itself. I could add an insufficient_privs_path and redirect there instead of login_path when a user is already authorized. Yet another option would be to let logged in unauthorized to percolate up and implement that page with an error view. Any opinions? I'm leaning towards adding an insufficient_privs_path as it seems simplest and least invasive. (When not set it would just use login_path as normal). Laurence ___ 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] How can I make the tests of zope.sqlalchemy running?
Those tests are designed to be run with the zope testrunner. try: $ python booststrap.py $ bin/buildout $ bin/test Laurence On 12 September 2010 14:29, Robin Lee wrote: > The output of a failed 'python setup.py test' is attached. > > > ___ > Zope-Dev maillist - zope-...@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 ) > > ___ 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] lxml dependency in Zope 2.12.10 KGS
I believe Sidnei is working on creating lxml windows releases. Hopefully we'll have a Windows lxml 2.2.8 release in the next week or so. http://permalink.gmane.org/gmane.comp.python.lxml.devel/5635 Laurence On 10 September 2010 15:01, Martin Aspeli wrote: > > > On 10 September 2010 14:26, Hanno Schlichting wrote: >> >> On Fri, Sep 10, 2010 at 3:17 PM, Martin Aspeli >> wrote: >> > If we *are* going to use a convenience pin, then surely the ability to >> > install on the world's most-used operating system has to be part of the >> > convenience. ;-) >> >> That's a lame argument. Windows is almost irrelevant for the market we >> are in - web server deployments. > > Erm, you think so? Maybe we should do a poll on how many Zope / Plone > developers use Windows on the desktop. Or look at how many people download > the Windows installer. You need a dev environment, not just deployment, and > a lot of people are on Windows. > >> >> Our own community is barely able to >> keep up providing the most basic Windows support and ensuring tests >> pass. As long as we don't have more community volunteers actually >> caring about Windows support, I won't let it be an argument to >> penalize the rest of the community. > > When the software breaks, people go elsewhere. I didn't say Windows support > was easy, or any fun. But we have to decide: do we care about people who > have made (or are forced to make) different technology choices than us, or > do we tell them their platform is unsupported? > >> >> > If we don't use it, we shouldn't pin it, IMHO. We found this problem >> > because >> > the Zope KGS was overriding another KGS where we had pinned lxml to >> > 2.2.4. I >> > don't think Zope has any business getting in the way of that. >> >> The KGS is a base KGS you can use. Nobody forces you to stick to it. >> In fact for every single deployment of your own you will need to >> extend it. I don't see a problem with the few people using Windows and >> not installing compilers on their platforms to change one version pin. > > I think you're missing the point: > > - We shouldn't pin software we don't use. It may be well intentioned, but > if we don't depend on it, we shouldn't take responsibility for it, or give > the perception that we take that responsibility. > > - If we do depend on it, we need to make sure it works on the platforms we > support. QA isn't something you do only when it's easy to do in your local > dev sandbox. > > - If we suddenly no longer support Windows, we better have the guts to come > out and say it, stop producing Windows eggs for Zope 2 stuff and explicitly > state that people cannot and should not use Windows for Zope development. I > hope that's not the case, though. ;) > > Martin > > ___ > Zope-Dev maillist - zope-...@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 ) > > ___ 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] DTML is dead, long live DTML ;-)
On 5 September 2010 02:49, Tim Hoffman wrote: >>> >> >> Please note that DTML is a dead (and horrid) technology. >> Martin > > But zpt is horrible for doing non html/xml based things ;-), What do you > think is good alternative in the zope eco system now > for templating other types of things (sql, python ...) ? If you don't need conditions or looping, then string.Template from the standard library is a reasonable choice. For templating SQL I would use SQLAlchemy, as you want appropriate quoting applied to your input. (You don't have to use it's ORM). Laurence ___ 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] import of zexp containing Page Template objects causes sudden zope death
On 29 August 2010 10:03, Chris Withers wrote: > Tim Hoffman wrote: >> on linux >> >> t...@chrome:~$ file /usr/bin/python2.5 >> /usr/bin/python2.5: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), >> dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped >> t...@chrome:~$ > > Right, so the linux boxes are 32-bit as I suspected: > > $ file /usr/local/bin/python2.6 > /usr/local/bin/python2.6: ELF 32-bit LSB executable, Intel 80386, > version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared > libs), not stripped > > $ file /usr/local/bin/python2.6 > /usr/local/bin/python2.6: ELF 32-bit LSB executable, Intel 80386, > version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux > 2.6.8, not stripped > >> os/x will work the same. > > Sadly not: > > $ file /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 > /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6: Mach-O > universal binary with 2 architectures > /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 (for > architecture ppc): Mach-O executable ppc > /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 (for > architecture i386): Mach-O executable i386 This is telling you that the executable contains versions for ppc and i386 (no x86_64, so no 64bit version). Another way to confirm this is at the python prompt with: import sys; sys.maxint > Nonetheless, why would a .zexp on a 32-bit architecture and import on > 64-bit cause sudden crash death when viewing /manage_main of a an > imported folder containing Page Templates?! > > Still in "wtf?!" mode... Your best bet is adding the breakpoint and stepping through with pdb until you hit the error (you can usually just hold down the return key after the first step...) Laurence ___ 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 )
[Zope-dev] zope.sqlalchemy 0.6 release
I've released zope.sqlalchemy 0.6 with the following changes: * Implement should_retry for sqlalchemy.orm.exc.ConcurrentModificationError and serialization errors from PostgreSQL and Oracle. (Specify transaction>=1.1 to use this functionality.) * Include license files. * Add ``transaction_manager`` attribute to data managers for compliance with IDataManager interface. Release available from http://pypi.python.org/pypi/zope.sqlalchemy Laurence ___ 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 )
[Zope-dev] zope.sendmail and critical transaction errors.
With Zope2's MailHost now using zope.sendmail, we're seeing some critical errors when sending mail when the mail server domain name is misconfigured. http://dev.plone.org/plone/ticket/10675 (these are triggered by a password reset mail, the registration mail is sent immediately). This is because zope.sendmail.delivery.MailDataManager sends mail in tpc_finish when using DirectMailDelivery. While MailDataManager makes sense for QueuedMailDelivery (msg.commit should never fail) for DirectMailDelivery it seems wrong. To fix this, DirectMailDelivery should use a commit hook - there are two options: * After Commit Hook Ensures mail is only sent once in event of a request being retried, but errors are swallowed so no feedback that there is a problem to the browser. * Before Commit Hook Mail me be sent multiple times in event of a request being retried due to a conflict error, but errors propagate to the browser. I think the Before Commit Hook option is probably best here. DirectMailDelivery should only be used for testing anyway, or at least only on very small sites in production - QueuedMailDelivery will scale better. For Zope 2.12 / Plone 4.0 we have the additional problem that Zope 2.12 is incompatible with zope.sendmail 3.7.x / trunk due to a zope.component 3.8 dependency. I think this issue is serious enough to warrant backporting this fix to the zope.sendmail 3.6.x branch. Patches attached for comment. Laurence aftercommit.diff Description: Binary data beforecommit.diff Description: Binary data ___ 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] deciding whether to do work in tpc_vote or tpc_finish
On 13 June 2010 11:18, Chris Withers wrote: > Laurence Rowe wrote: >> >> On 8 June 2010 12:59, Chris Withers wrote: >>> >>> Laurence Rowe wrote: >>>> >>>> it fails you will end up in an inconsistent state whatever. It's just >>>> that with the maildir implementation, it pretty much can't fail as it >>>> is only a rename and that should always succeed. Really, it should >>>> register as an after commit hook instead. >>> >>> How do I do that? >> >> transaction.get().addAfterCommitHook(callable, args, kwargs) > > Hmm, I realised from looking at the code this morning that this won't. > The reason being that there's no equivalent AfterAbortHook where I can abort > the messaging transaction in the event of transaction-package transaction > abort. """ After-commit hook -- Sometimes, applications want to execute code after a transaction is committed or aborted. For example, one might want to launch non transactional code after a successful commit. Or still someone might want to launch asynchronous code after. A post-commit hook is available for such use cases: use addAfterCommitHook(), passing it a callable and arguments. The callable will be called with a Boolean value representing the status of the commit operation as first argument (true if successfull or false iff aborted) preceding its arguments at the start of the commit (but not for substransaction commits). """ http://zope3.pov.lt/trac/browser/transaction/trunk/transaction/_transaction.py Laurence ___ 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] connection commit ordering
On 18 June 2010 14:32, Leonardo Rochael Almeida wrote: > Hi Laurence > > On Fri, Jun 18, 2010 at 08:06, Laurence Rowe wrote: >> On 18 June 2010 01:24, Leonardo Rochael Almeida wrote: >>> By the way, this issue is completely separate from the >>> two-phase-commit discussion that we had recently, since all the >>> connectors involved here are fully transactional. >> >> As you can see here: >> >> http://zope3.pov.lt/trac/browser/Zope/trunk/src/Shared/DC/ZRDB/TM.py >> >> def tpc_vote(self, *ignored): >> self._finalize = 1 >> >> def tpc_finish(self, *ignored): >> >> if self._finalize: >> try: self._finish() >> finally: self._registered=0 >> >> The transaction manager is only doing one phase commit. It sorts first >> as it commits in the second phase. If you change the sort order, you >> lose the guarantee of transactional integrity. > > For me this means that TM subclasses need to override tpc_vote and > implement a proper commit preparation [1] [2] to assure they are > correctly participating in the TPC dance. zope.sqlalchemy does this, but that brings a whole orm into the equation and does away with ZRDB legacy. > And if that is not the case, but you have, for example, more than one > MySQL connector, you are already in a situation where you can't > guarantee transactional integrity, so this discussion is actually > orthogonal to the sortOrder one. That's true, but don't you see this problem even with only a single ZODB and a single ZRDB connection? >> Perhaps a better way to solve this would be to include the zope >> transaction id in the table, then in the background thread only >> reindex the queued items with a tid <= the current tid of the >> connection. > > Possibly, but is there a way to know the id of a transaction that > hasn't been committed yet, to store it on MySQL? Besides, when working > with multiple mount points, you might have to store multiple TIDs, for > all storages involved, or else there should be a global transaction ID > that should be recorded everywhere, and I don't see the 'transaction' > package providing one. The ZODB storage's transaction id is set in tpc_begin, so you should be able to get it in tcp_vote or tpc_finish of the ZRDB data manager. Though doing so probably horribly complicates the ZSQLCatalog code. > In any case, does anyone oppose the existence of a .setSortKey() on > the TM class? I don't oppose it, but I also don't see how this will fix the problem unless you set the sort key to be greater than the ZODB's sort key. This strikes me as a very bad idea for a TM that is designed to tpc_finish before anything else. Laurence ___ 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] connection commit ordering
On 18 June 2010 01:24, Leonardo Rochael Almeida wrote: > By the way, this issue is completely separate from the > two-phase-commit discussion that we had recently, since all the > connectors involved here are fully transactional. As you can see here: http://zope3.pov.lt/trac/browser/Zope/trunk/src/Shared/DC/ZRDB/TM.py def tpc_vote(self, *ignored): self._finalize = 1 def tpc_finish(self, *ignored): if self._finalize: try: self._finish() finally: self._registered=0 The transaction manager is only doing one phase commit. It sorts first as it commits in the second phase. If you change the sort order, you lose the guarantee of transactional integrity. Perhaps a better way to solve this would be to include the zope transaction id in the table, then in the background thread only reindex the queued items with a tid <= the current tid of the connection. Laurence ___ 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] deciding whether to do work in tpc_vote or tpc_finish
On 8 June 2010 18:11, Jim Fulton wrote: > On Tue, Jun 8, 2010 at 1:00 PM, Laurence Rowe wrote: >> On 8 June 2010 14:38, Jim Fulton wrote: >>> This is intended as a broad response to the thread, rather than a >>> response to any specific post. :) >>> >>> I've been thinking of expanding the data manager API to add an >>> optional tpc_rollback method. If tpc_finish returns a value and a >>> data manager provided tpc_rollback and some other data manager fails >>> in tpc_finish, then tpc_rollback would be used to *try* to recover >>> from the other data managers failure. Note that even if tpc_rollback >>> is implemented, it might fail if the transaction can't be rolled back >>> (due, typically, to subsequent conflicting transactions). >> >> While I can imagine a ZODB implementation of tpc_rollback that could >> work in some circumstances for some storages, even then it seems it >> would be quite complex and perhaps unlikely to succeed - as soon as >> another connection read anything from the database you would be unable >> to tpc_rollback, unless you deferred truly committing the transaction >> to a tpc_truly_finished which would just bring you back where you >> started. > > No. It would behave exactly like (probably built on) undo, which > generates suitable invalidations. > > (Of course, undo itself weakens consistency to some degree.) For web applications, one consequence of this is that you could end up with stale pages cached in a proxy. This may well be preferable to the inconstancies following from a failure in tpc_finish though. If it were implemented, I guess it would be desirable for data managers implementing tpc_recover to be called before those implementing only tpc_vote/tpc_finish, which in turn should be sorted before those implementing only 1-phase-commit. If multiple data managers implemented tpc_recover, would a failure of one data manager's tpc_recover prevent other data manager's tpc_recover being run at all? I guess you want to end up in the 'least inconsistent' state, but it's difficult to know whether this would be achieved by attempting to tpc_recover on the other data managers or not. I guess my concern is that the benefits from implementing this should outweigh the cost in higher complexity. Laurence ___ 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] deciding whether to do work in tpc_vote or tpc_finish
On 8 June 2010 14:38, Jim Fulton wrote: > This is intended as a broad response to the thread, rather than a > response to any specific post. :) > > I've been thinking of expanding the data manager API to add an > optional tpc_rollback method. If tpc_finish returns a value and a > data manager provided tpc_rollback and some other data manager fails > in tpc_finish, then tpc_rollback would be used to *try* to recover > from the other data managers failure. Note that even if tpc_rollback > is implemented, it might fail if the transaction can't be rolled back > (due, typically, to subsequent conflicting transactions). While I can imagine a ZODB implementation of tpc_rollback that could work in some circumstances for some storages, even then it seems it would be quite complex and perhaps unlikely to succeed - as soon as another connection read anything from the database you would be unable to tpc_rollback, unless you deferred truly committing the transaction to a tpc_truly_finished which would just bring you back where you started. For other systems I can't think how it might be implemented - you can't unsend a mail or uncommit a committed transaction in a relational database. Laurence ___ 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] deciding whether to do work in tpc_vote or tpc_finish
On 8 June 2010 12:59, Chris Withers wrote: > Laurence Rowe wrote: >> >> it fails you will end up in an inconsistent state whatever. It's just >> that with the maildir implementation, it pretty much can't fail as it >> is only a rename and that should always succeed. Really, it should >> register as an after commit hook instead. > > How do I do that? transaction.get().addAfterCommitHook(callable, args, kwargs) > Since the data manager I'm working on is for a transcation message sending > implementation, maybe it should be an after commit thing too? > > My other thought was to have it commit the message send in tpc_vote, and > make sure it sorts before zope.sqlalchemy. That way, if the message send > fails, the "transaction" will be aborted, and that will include rolling back > the zope.sqlalchemy session rather than committing it. > > Views? In that case if the sqlalchemy commit fails, you still sent the message. Laurence ___ 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] deciding whether to do work in tpc_vote or tpc_finish
On 8 June 2010 12:48, Chris Withers wrote: > Christian Theune wrote: >> If >> >> you have more than one then it can happen that the first one committed, >> but the second one doesn't and then you can't properly roll back. > > Okay, but this is quite a common occurrence now. For example, many projects > will use zope.sendmail and zope.sqlalchemy together... > > I'd guess there are a few "transactional file on disk" components out there > that play in this area too... As zope.sendmail commits in tpc_finish, there is no additional issue using it with zope.sqlalchemy in 1pc than with a 2pc data manager. If it fails you will end up in an inconsistent state whatever. It's just that with the maildir implementation, it pretty much can't fail as it is only a rename and that should always succeed. Really, it should register as an after commit hook instead. When an after commit hook fails, the error is caught, logged, and then it continues. Laurence ___ 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] deciding whether to do work in tpc_vote or tpc_finish
On 8 June 2010 11:44, Chris Withers wrote: > Laurence Rowe wrote: >> >> Committing in tpc_vote is right so long as you ensure your data >> manager sorts last, and that there are no other data managers in the >> transaction which are using the same trick. > > Why does the latter part matter? > > (It is, of course, the situation I'm in, where zope.sqlalchemy is operating > in non-tpc mode (sqlite doesn't support tpc :-/) and now I'm writing another > data manager for a service that doesn't support tpc) Your options then are: * Use a database that supports two phase commit (you're using sqalchemy, so that should be trivial). * Queue up changes for the other 1pc system in the first, batching updates to the second. While this moves the problem to the batch process, it's easier to solve there as you can just add timestamps to the data, and then know if any particular row was successfully pushed into the second system or not in event of a power cut. * Trust that any sqlite transaction will always be committed successfully and add a data manager variant to zope.sqlalchemy that commits in tpc_finish. You'll never get a write conflict error in SQLite (it uses locking instead of MVCC, see http://www.sqlite.org/lang_transaction.html and http://www.sqlite.org/lockingv3.html), but you might end up in an inconsistent state in event of a power cut or perhaps when you fill up the disk. Laurence ___ 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] transaction_manager attribute of transaction.interfaces.IDataManager
On 8 June 2010 11:25, Chris Withers wrote: > Laurence Rowe wrote: >> >> transaction_manager = zope.interface.Attribute( >> """The transaction manager (TM) used by this data manager. >> >> This is a public attribute, intended for read-only use. The value >> is an instance of ITransactionManager, typically set by the data >> manager's constructor. >> """) >> >> This seems to be used only in the tests, I guess it would be useful if >> you were using multiple transaction managers in a single thread. > > Can you think fo examples where that would happen? Perhaps if you wanted to use an event based (as opposed to threaded) server. Laurence ___ 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] transaction_manager attribute of transaction.interfaces.IDataManager
On 8 June 2010 09:45, Chris Withers wrote: > Hi All, > > What is this attribute actually used for? > > I see it present on IDataManager but I notice that zope.sqlalchemy's > SessionDataManager doesn't have this attribute, with no apparent ill effect. transaction_manager = zope.interface.Attribute( """The transaction manager (TM) used by this data manager. This is a public attribute, intended for read-only use. The value is an instance of ITransactionManager, typically set by the data manager's constructor. """) This seems to be used only in the tests, I guess it would be useful if you were using multiple transaction managers in a single thread. I've now added it to zope.sqlalchemy's data manager. Laurence ___ 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] deciding whether to do work in tpc_vote or tpc_finish
On 8 June 2010 09:51, Chris Withers wrote: > Hi All, > > I need to write a data manger that interacts with a transactional system > that doesn't support two phase commit. > > Looking for inspiration, I went to look at zope.sqlalchemy and > zope.sendmail. > > In the non-tpc situation, the former does the "commit" in tpc_vote while > the latter does it in tpc_finish. > > Which is "right"? What are the tradeoffs involved? Committing in tpc_vote is right so long as you ensure your data manager sorts last, and that there are no other data managers in the transaction which are using the same trick. See: https://mail.zope.org/pipermail/zodb-dev/2007-May/010996.html For zope.sendmail, committing in tpc_finish makes sense, especially when using QueuedMailDelivery because enqueuing the message in the maildir is guaranteed to succeed (the file is just renamed on commit). Any failure here would lead to a critical error and inconsistent state between the transactional resources. Laurence Laurence. ___ 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: Proposed new style for documenting and testing ZTK packages
On 17 April 2010 10:41, Lennart Regebro wrote: > On Sat, Apr 17, 2010 at 11:18, yuppie wrote: >> How can we make sure docs and code don't get out of sync? Do we have to >> run unittests *and* build the docs before each checkin? Will someone >> make sure buildbots and nightly tests report broken docs as well? > > Hm... As long as you use the >>> syntax and none of the > ..test-block:: syntax of sphinx, the sphinx docs can be tested as a > part of the standard testruns, but I guess part of this proposal was > so we could easily use the testblock syntax as it has the possibility > to hide setup etc easier. And then I don't know the best way to > integrate it, but it would definitely be a drawback if you need two > different testruns to run all the tests... > > Also I think it should be the responsibility of the one who does a > release to make sure that we can build HTML docs and that the > formatting isn't *too* broken. > Preferably these docs should also be uploaded to packages.python.org, > maybe there can be a makefile step for that in the docs? It's important that documentation is tested as part of the standard test run, that means when you change something you know to update the docs. repoze.bfg seemed to make an attempt at this, though it is currently disabled. http://svn.repoze.org/repoze.bfg/trunk/repoze/bfg/tests/test_docs.py Laurence ___ 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] Possible DateTime timezone-related regression in Zope 2.12
2010/1/10 : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Martin Aspeli wrote: >> Wichert Akkerman wrote: >>> On 2010-1-10 04:36, Martin Aspeli wrote: so in your test, `DateTime(md.CreationDate())` will always be the current time, but with an implicitly added 'GMT+0' while `DateTime()` will be the current time in your local time zone. so if i'm not mistaken, on plone 4.0 the test with fail for you an me (in 'GMT+x' time zones) and pass in the u.s. fun! :) Does anyone know if this change was deliberate, or what may have happened? >>> Have you looked at >>> http://zope3.pov.lt/trac/log/Zope/trunk/lib/python/DateTime?rev=95999 >>> >>> > for hints? >> >> Yes, there are various timezone related changes, e.g. >> >> http://zope3.pov.lt/trac/changeset/81213/Zope/trunk/lib/python/DateTime >> >> > http://zope3.pov.lt/trac/changeset/85830/Zope/trunk/lib/python/DateTime >> >> It's hard to know whether this was an intended change or not, and >> if so, how to deal with the breakage in a way that's compatible >> with 2.10 and 2.12. >> >> I blame Laurence. :-p > Better blame DateTime :-) > Fixing one issue in DateTime is likely to trigger another new bug. > The DateTime is just fragile. I believe the current behaviour is intentional to preserve backwards compatibility. See the discussion starting here: https://mail.zope.org/pipermail/zope-dev/2007-October/030042.html Maybe it was 'fixed' on 2.10 branch some time later. Laurence ___ 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] Where best to intercept a request to send a 304 response in Zope 2
2009/12/31 Martin Aspeli : > Hi, > > A few of us are playing with some caching tools, trying to get to a more > sane and less monkey patch-laden approach than CacheFu > (Products.CacheSetup), for use with Zope 2.12. > > It is relatively easy to set response headers, e.g. in an > IPubBeforeCommit event handler. > > However, we also need to be able to intercept a request to send a 304 > response if the underlying object has not been modified. > > CacheFu monkey patches ZPT rendering to avoid the actual rendering if a > 304 response is being sent, returning an empty string instead. I'd > rather not have such patches, though, and anyway this only work with > things rendered as ZPTs. It also doesn't avoid any pre-work that a view > may do before rendering its template, if indeed it has one. > > Another thought was to use IPubAfterTraversal, at which point we have > the object to publish and security checks have been completed. However, > ZPublisher.Publish goes straight from that into mapply(). > > Can anyone think of a good way to do this? Maybe we need to add some > kind of condition around mapply(), e.g. to do not nothing if there's a > 304 response header, or some other marker? I think this is analogous to 404 Not Found errors. It should be possible to handle them with the combination of: * raise a NotModified exception in an IPubAfterTraversal handler * in a NotModified exception view, setStatus 304 Not Modified an return an empty string. Laurence ___ 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] shrinking the ZTK: a proposed solution
2010/1/5 Hermann Himmelbauer : > Am Dienstag 05 Januar 2010 14:37:51 schrieb Martijn Faassen: >> Hermann Himmelbauer wrote: >> > Am Dienstag 05 Januar 2010 11:58:38 schrieb Martijn Faassen: >> >> Hermann Himmelbauer wrote: >> >>> But I have to further state that I'm locked into Zope 3.4.0 as the >> >>> support for Python 2.4 was dropped, so I can't upgrade to the current >> >>> ZTK. >> >> >> >> This is a surprise to me. I thought we still supported Python 2.4 >> > >> > That's a surprise to me, too: I remember endless discussions about >> > dropping support for Python 2.4 on this list, let me see: >> > >> > https://mail.zope.org/pipermail/zope-dev/2009-April/036387.html >> > >> > I thought the outcome was somehow that Python 2.4 support was dropped? >> >> I recall the conclusion was not to do that yet. > > That's good news for me - don't know why I assumed that. Note that ZODB is dropping python 2.4 support in 3.10. https://mail.zope.org/pipermail/zodb-dev/2009-December/013084.html Laurence ___ 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.filerepresentation
2009/10/1 Martin Aspeli : > Hanno Schlichting wrote: >> The standard file implementation has no knowledge of its size, as this >> is sometimes impossible to get, when dealing with stream based >> file-like objects. Do we really need to have files to know their size? > > Well, for the writeFile() stuff maybe we don't. Thinking through my use > cases again, I can't see a need for passing the content type in, and > encoding can be set if we support setting the '.encoding' property. > > It's kind of important to be able to indicate the size and MIME type for > a read operation, though. In this case, I want to be able to put that > information into the Content-Type and Content-Length headers. The > IStreamData stuff in Zope 2 also wants to know the length before it > starts streaming. > > In some cases, it may not be possible to know, in which case we can fall > back on len(data), but in other cases, the length is known > (plone.namedfile and z3c.blobfile keep track of it, for example), in > which case having a way to ask the adapter means it can be done much > more efficiently. To find the length of a file: f.seek(0,2) # 0 bytes from the end of the file size = f.tell() # position in file. Laurence ___ 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] z3c.saconfig engine creation configuration
Malthe Borch wrote: > On MySQL, it's necessary to supply to ``pool_recycle`` parameter on > engine creation, else the connection dies after some timeout and the > pool is unable to hand out a session. > > The result of this is that the first request fails whenever the > connection has been dropped. > > Attached is a patch that allows supplying these pool-related > configuration options directly in the ZCML directive (db:engine). > > \malthe I would rather we did not hardcode the defaults from SQLAlchemy into the engine directive (I guess they could change in future). Instead use a default of None and only supply the parameter if the config option is set. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.traversing/trunk/src/zope/traversing/ Moved the publicationtraverse module from zope.app.publication and added tests.
Jim Fulton wrote: > I don't agree. The semantics are different. For example, you often > want to traverse to things in a template that you don't want to expose > via URL. We currently (or last time I checked) expose ++resource+ > +name in URLs and this is a bug. What use is a resource without being URL accessible? It's used fairly often in Plone products to expose static css / js / images. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Why does restrictedTraverse() in Zope 2 not respect IPublishTraverse adapters?
Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Martin Aspeli wrote:
>
>> There's currently a funny inconsistency in Zope's Traversable class. If
>> you have a URL like http://localhost:8080/path/to/@@aview/foo, and
>> @@aview implements IPublishTraverse (and, I presume, if there's a custom
>> IPublishTraverse adapter for any other path component), URL traversal
>> will work fine, but calling to.restrictedTraverse('@@aview/foo') or some
>> variant thereof will fail, because (un)restrictedTraverse() does not
>> respect custom IPublishTraverse adapters.
>
> 'restrictedTraverse' is not (and never has been) the same as URL
> traversal. For instance:
>
> - - URL traversal does no security checking until it finds the published
> object.
>
> - - URL traveresal manages the '__before_publishing_traverse__' hooks.
>
>
> If you want your adapter to be respected by *both*, it needs to
> implement the appropriate interfaces for both.
>
>> I can kind of see why it's done like this since it's called
>> I*Publish*Traverse, but it is a pain.
>>
>> Note that namespace traversal (like ++skin++) works fine with
>> restrictedTraverse().
>>
>> I don't think it'd be hard to implement this, but:
>>
>> - is this a bug?
>
> No.
>
>> - is there a reason not to do this?
>
> - -1 to adding any more majyk to the over-complicated Z3-style traversal
> dance inside Zope2, especially as it would involve a bunch of subtle
> behavior changes which would be hard to explain.
>
> For maximum portability across Z2 / Z3 / BFG, you could just do the same
> thing and implement __getitem__ on any object you want to be traversable
> by either the publisher or APIs like (un)restrictedTraverse, and forego
> the over-complicated component-laden traversal dance. ;)
Minimal example demonstrating this with a view in zope2:
>>> from zope.component import getSiteManager
>>> from Testing.makerequest import makerequest
>>> from zope.publisher.browser import IBrowserView
>>> from Acquisition import Explicit
>>> from zope.component import getSiteManager
>>> app = makerequest(app)
>>> smgr = getSiteManager()
>>> class Foo(Explicit):
... def __init__(self, context, request):
... self.context, self.request = context, request
... def __getitem__(self, key):
... return int(key)
...
>>> smgr.registerAdapter(Foo, (None, IRequest), IBrowserView, name='foo')
>>> app.unrestrictedTraverse('@@foo/12345')
12345
Laurence
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Using views for exceptions in Zope 2.12?
Sidnei da Silva wrote: > On Sat, May 9, 2009 at 12:52 PM, Chris Withers wrote: >> Hmm, so I would I register different views for a KeyError versus an >> AttributeError? > > I believe you need to make KeyError implement an interface to be able > to register a view for it. What use would be a view for KeyError > anyway. *wink* > It's perfectly possible to register a view for a class instead of an interface. (Not that I am familiar with the new views for errors stuff). Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
2009/4/27 Chris McDonough : > On 4/27/09 3:27 PM, Laurence Rowe wrote: >> >> Martin Aspeli wrote: >>> >>> Laurence Rowe wrote: >>>> >>>> Martin Aspeli wrote: >>>>> >>>>> Hi, >>>>> >>>>> First - a quick question: can we treat __name__ and id/getId()/_setId() >>>>> as the same, always? OFS.SimpleItem has some support for letting id and >>>>> name be the same, but the link is lost once both __name__ and id are >>>>> set. Why isn't __name__ just a property that reflects self.id ? >>>> >>>> I would prefer this to be the other way around -- getId() / _setId() >>>> should operate on __name__. It will be easier to drop OFS support in the >>>> future if pickles store the real __name__ and __parent__ attributes. We >>>> will presumably require a migration now anyway to add __parent__ >>>> pointers. >>> >>> It kind of already does that if 'id' isn't set. But when 'id' is set, >>> they diverge. >>> >>> Also note that according to ILocation, __name__ is a TextLine, which >>> implies unicode. unicode ids are a no-no in Zope 2. >> >> I doubt it would be all that difficult to change the publisher to handle >> unicode path segments. > > This would be the only sane thing to do if Zope was being created today. > > It's a lot saner to store Unicode object identifiers than string ones, and > if you've got that it's a no-brainer to use Unicode path segments too. But > if you did one and not the other, it would be a worthless change. My point here is that if we modify the publisher then maybe we can start storing unicode __name__ attributes. Unicode container keys work just fine now so long as they contain only ascii characters. >>> The current solution I've put into dexterity is to let __name__ be a >>> property that gets and sets id, but assumes its value is unicode. It'll >>> fail if the unicode string can't be encoded to ASCII, though. > > That's certainly keeping with the spirit of the default "bad identifier" > regex in OFS, but it does feel a little weird to need to never use > high-order characters in ids (even if you did need to make them utf-8 > encoded). I had to work around this for one very large application that > wanted to use Zope as a filesystem storage and it was no fun at all (in > fact, it would have been sanest to not use Zope for that). > >> This is what I'm worried about. If new code uses __name__ instead, then >> it opens up the possibility to share ZODB content between Plone and >> lightweight systems like repoze.bfg, as well as making it easier for >> Plone to migrate to a cleaner content model. Plone has been around for >> eight years now, I sincerely hope we are not still stuck on >> OFS.SimpleItem for another eight years! > > I wouldn't worry much about trying to preserve compatibility between Zope 2 > and Zope 3/bfg at this level; it's highly unlikely that *any* Plone content > object will work out of the box on any system other than Zope2 (or at least > without a large chunk of Zope2 sitting around) due to abuses of things like > "self.REQUEST" in Archetypes. But I could be wrong. You don't have to write Archetypes to use Plone though. Tools like plone.app.content allow you to write sane, lightweight content types with zope.schema today. You need to bring in a lot of baggage in your base classes for things to be compatible with the CMF layer, but on the storage layer at least things are starting to look fairly sane. The acquisition changes in Zope 2.12 give us the possibility of writing clean new code without having to rewrite everything at once. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
