Zope-Dev December 2004

zope-dev@zope.dev

34 participants
28 discussions

Zope Service on Windows
by Christian Theune 18 Dec '04

18 Dec '04

Howdi. I just checked in how I finally got Zope 2.7.x to run as a service on Windows again. Setting the PYTHONPATH environment actually even makes more sense here as the CreateProcess API call won't take the sys.path into the new python, but the environment variables. This now also plays with the import of sitecustomize.py correctly. I still wonder why this seems to behave differently in 2.7 as in 2.8. The 2.8 currently works as a service out of the box. I don't see the actual difference. Anybody tell me. I'm scared. Also: I'd like to know if this solution for 2.7 is acceptible or not. It works for me but I'm everything but a windows guru. Cheers, Christian PS: See http://cvs.zope.org/Zope/skel/bin/Attic/zopeservice.py.in.diff?r1=1.1.2.8&r… for the change. -- gocept gmbh & co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - ct(a)gocept.com - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development

5 7

Re: Why third_party/docutils?
by Tres Seaver 17 Dec '04

17 Dec '04

Andreas Jung wrote: > > > --On Freitag, 17. Dezember 2004 11:34 Uhr -0500 Tres Seaver > <tseaver(a)zope.com> wrote: > >> Andreas Jung wrote: >> >> I don't get this. Why couldn't we just delete the *entire* stripped-down >> 'docutils' package and replace it with the *whole* package *in exactly >> the same location*? E.g. (assuming we had not already munged things): >> >> $ cd Zope-2.7-branch/lib/python/docutils >> $ find . -type "f" | grep -v CVS | xargs cvs rm -f >> $ cvs commit -m " - Blow away stripped down docutils." >> $ tar xzf /tmp/docutils-the-whole-enchilada.tar.gz >> $ find . -type "f" | grep -v CVS | xargs cvs add >> $ cvs commit -m " - Add current docutils." > > > If you unpack Docutils as a whole in lib/python then you will a structure > > lib/python/docutils/docutils > ^^^^^^ > This is the directed where > docutils import usually start. > > If you do adjust sys.path to lib/python/docutils/docutils then every code > that tries to import the docutils package will fail because it tries to > import > from lib/python/docutils instead from lib/python/docutils/docutils. I don't > know why this is so hard to understand or are we talking about different > things? OK, then suppose we vendor import the docutils tarball into a different location, e.g.: $ cd /tmp $ tar xzf docutils-the-whole-enchilada.tar.gz $ cd dodcutils $ cvs -d :ext:cvs.zope.org:/cvs-repository import \ Libraries/docutils docutils docutils-0_xxx and then symlink the actual package portion in the CVS repository into Zope/lib/python? For SVN, we would spell that somewhat differently, but the idea would be the same. The major goal is to remove the need to jigger either the Python search path or the sitecustmize.py package; both of those practices step on territory which is intended to belong to the system admin, rather than the software. Tres. -- =============================================================== Tres Seaver tseaver(a)zope.com Zope Corporation "Zope Dealers" http://www.zope.com

1 0

2.7 and 2.8 roadmap
by Tim Hicks 17 Dec '04

17 Dec '04

Hi, just wondering what the plans are for zope 2.7 and 2.8. Specifically: 1) When is the recent release of 2.7.4b2 expected to be followed up with a 'final' (or indeed another beta) release? 2) I have seen mutterings about a 2.7.5 release, but I'm not sure why this should be necessary as I thought all 'dot releases' were only supposed to provide bug-fixes. Seeing as we're still on beta for 2.7.4, shouldn't any outstanding fixes go into that? 3) Are there plans for another 2.8 (alpha or beta) release in the near future? Is there a timeline for this? Are ZC or anyone else hanging out for this? Personally, I'm pretty keen to be able to persist new style classes (for use with the email.Message.Message class). The wiki at <http://dev.zope.org/Wikis/DevSite/Projects/Zope2.8/FrontPage> seems a little out of date. Just interested. cheers, tim

3 4

Re: [Zope-dev] Why third_party/docutils?
by Alan Milligan 17 Dec '04

17 Dec '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 And while we're talking about docutils, the delivered Reporter warning/error functions write directly to STDOUT. We have ReST functionality in Zpydoc, and we get loads and loads and loads of crap 'invalid unindent' messages streamed to STDOUT from the Zpydoc demo site. Zope is supposedly a background server, there is very little need to be doing this. Anyone for turning this down??? Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBwpIXCfroLk4EZpkRAgpjAJ9L49MfYuuXKEkaI2VQRfXWgJ/d1gCeIq+d wXwjrOhHMdGfvU0/HITJrZQ= =6Qnj -----END PGP SIGNATURE-----

2 1

RE: [Zope-dev] Re: SOAP Support for ZOPE
by Alan Milligan 17 Dec '04

17 Dec '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I fully support Brian on this one. We are a big user of XML-RPC. I'm also more than interested in SOAP and WSDL in general as we're going to need to integrate such services in the future. However, we MUST create a proper plugin framework. I do not wish to be surprised and appalled in the future by installing a SOAP product and finding it's destroyed our XML-RPC functionality! I also want to add that whilst an XML-RPC GET request is not defined in the RFC, in practice we find this not to be the case (refer patches for this dubious feature posted on this list a couple of months ago). Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBwpEHCfroLk4EZpkRAl56AJ0bet2rPCSVH2K+TXnZyORbfzmZygCgwaPY HoBZTDMMmTAhkptRYPo7DGU= =2zgd -----END PGP SIGNATURE-----

1 0

RE: [Zope-dev] Re: SOAP Support for ZOPE
by Aruna Kathiria 16 Dec '04

16 Dec '04

Hi Brian: I discussed with Michel Pelletier and he will help to produce a patch that exactly implements your proposal that we'll send to you for your review. Then we'll just provide an outside Product that calls the registration function. Thanks a lot for your suggestions... Aruna Kathiriya -----Original Message----- From: zope-dev-bounces(a)zope.org [mailto:zope-dev-bounces@zope.org] On Behalf Of Brian Lloyd Sent: Thursday, December 16, 2004 11:14 AM To: zope-dev(a)zope.org Subject: RE: [Zope-dev] Re: SOAP Support for ZOPE Hi all - having had to implement a monkey patch product before to enable SOAP, I'd like to make a few observations and a suggestion: - It is a pain to do anything with SOAP because the publisher has a hard-coded idea that anything xml must be xml-rpc - There is currently no easy way around this w/o monkey patching, which then leaves you vulnerable to future changes to the publisher - Opinions on the state of SOAP support in the Python world are far from unanimous - I think it would be premature to put a particular implementation into Zope proper - That said, Zope should make it possible for Cignex and others to provide SOAP support as add-on products without unreasonable contortions So the suggestion: I think we'd be in a better place if we: - Fix the publisher to at least recognize a SOAP request vs. an xml-rpc request - Provide some kind of 'registration hook' so that a Product can register with the publisher to handle SOAP requests - Have the publisher hand off where appropriate to a registered SOAP handler if installed, else return an HTTP NotImplemented or similar if there is no SOAP handler - Apply the KISS rule: only one product can register to the be the SOAP handler, and resist turning this into any kind of grand-unified-pluggable-publisher architecture ;) This would be minimally disruptive to the Zope core, while enabling people interested in SOAP to evolve different solutions without everybody having to buy into a particular approach or implementation right now. Brian Lloyd brian(a)zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com > -----Original Message----- > From: zope-dev-bounces(a)zope.org [mailto:zope-dev-bounces@zope.org]On > Behalf Of Tres Seaver > Sent: Wednesday, December 15, 2004 1:22 PM > To: zope-dev(a)zope.org > Subject: [Zope-dev] Re: SOAP Support for ZOPE > > > Florent Guillaume wrote: > > Richard wrote: > > > >>On Wed, 15 Dec 2004 06:54 am, Aruna Kathiria wrote: > >> > >>>I did some work regarding SOAP support on ZOPE and published this > >>>document on zope.org. > >> > >>Is there really no interest in getting SOAP support into the Zope > >>core? I've got a guy working on some Microsoft Word stuff at the > >>moment, and he was dumbfounded when he discovered that Zope doesn't > >>support SOAP. In his words, "everyone supports SOAP". Sigh :) > > > > > > There is probably interest, but it needs motivated people like Aruna > > and you to push it. > > > > > >>Are there any objections to getting Aruna's patches into the 2.8 > >>codebase? I'd be willing to do the work - but note I know > >>practically nothing about SOAP - I just want to be able to use it. > > > > > > One problem is that Aruna's approach introduces dependencies to > > external > > modules: fpconst, and a patched SOAPy. If these can be resolved, why > > not. > > Because of those dependencies, I think support "in the core" is not > feasible. However, I believe that it should be possible to create a > product which solves those issues. This product would either need to > monkey-patch the publisher (as outlined by John Zinit earlier in the > thread) or else register a new kind of server, which could be > configured (like the WebDAV source server) to listen on its own port. > > For an example of such a Product, see "ZServerSSL", > http://sandbox.rulemaker.net/ngps/zope/zssl/ > > Tres. > -- > =============================================================== > Tres Seaver tseaver(a)zope.com > Zope Corporation "Zope Dealers" http://www.zope.com > > _______________________________________________ > Zope-Dev maillist - Zope-Dev(a)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 ) > _______________________________________________ Zope-Dev maillist - Zope-Dev(a)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 )

1 0

Functional testing enhancement suggestion
by Lennart Regebro 16 Dec '04

16 Dec '04

I'm doing quite a bit of functional testing now, and although it's good for making sure there are no errors, I find it slightly lacking in the two otehr uses of tests: Debugging, and test driven development. The reason is simple: When a page publishing fails, it's hard to figure out WHY. What I'd want is a traceback of the error. Of course, these are gonna be big and ugly, being publishing tracebacks and all, but it's better than just getting to know that "503 != 200", something that I'm pretty well aware of. ;-) So, I tried to find if I could get the exception, or traceback or exc_info, or something similar from the returned RESPONSE object, but I failed. I do get an HTML-formatted traceback in the Body, but that's not very useful as it's completely unreadable. If isn't there, could we add it? Currently I do from zExceptions.ExceptionFormatter import format_exception t, v, tb = sys.exc_info() tb = format_exception(t, v, tb, as_html=0) response._text_traceback = '\n'.join(tb) in the exception handling of Test.py's publish_module(). That works fine, and only affects testing, which seems like a good idea. Of course, it could also be added in HTTPResponse.exception(), but that method is horrendously big and complex already. I also added the following method to my testcase: def assertResponse(self, response, status): if not response.getStatus() == status: tb = getattr(response._response, '_exc_info', None) if tb: raise self.failureException, tb and now, when I run the functional tests, instead of doing a "self.failUnlessEqual(response.getStatus(), 200)" and getting the error message "AssertionError, 503 != 200" I do "self.asserResponse(response, 200)" and get a traceback of what actually caused the error! Very handy! Thoughts? Opinions? The suggested changes above are small, only affects testing (as it's in Test.py and functional.py only) and is completely backwards compatible. Zope 2.8 even, maybe? ;-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/

1 0

Roundtrip-safe DAV
by Emiliano Heyns 16 Dec '04

16 Dec '04

Hello people, I'm currently working with some content editors that would like to keep their current WYSIWYG tools and use them in combination with Zope/Plone, and using the DAV interface seemed like the best approach, and it does indeed mostly work. One of the larger problems we face using this approach is that quite a few products expose objects via DAV that are not roundtrip-safe; getting-then-putting will result in unwanted behaviour in some cases, and for other objects I don't see much value in allowing them to be accessed over DAV (like the contents of acl_users). I wrote the attached monkey patch to address this (be kind, I'm pretty new to Python), and Sidnei da Silva (author of DavPack) suggested I post the patch on these lists to see if there was an interest into this approach. What it does is disable DAV access for non-collection resources in general and then selectively turns it on for some (non-exhaustive) list. Folderish objects are enabled by default but can be turned off. Objects/classes can also disable or enable themselves by explicitly setting __dav_resource__ to 0 or 1. I'm not suggesting this particular list is the correct one. Thoughts? With kind regard, Emiliano Heyns

5 8

posting
by Kenny Chamber 16 Dec '04

16 Dec '04

How long after posting should it take for a message to appear on the list? ----------------------- Kenny Chamber http://gem-hs.org/contact.html

2 1

Events in the core
by Florent Guillaume 15 Dec '04

15 Dec '04

I'd like to revive this discussion about having events in the core. Sidnei even mentionned getting them in Zope directly, http://dev.zope.org/Wikis/DevSite/Proposals/IncludeEventsInCore I'm all for it, and would really help many people. It would be awesome if a minimal implementation could be compatible with Zope 2.7.4, maybe as an addon product. But there needs to be a few hooks in the core (object create/move/clone/delete). Could we try to move together on this ? For the record, CPS has to monkey-patch many things to have its events work, and now that many others want events (Plone for starters), it would be nice to have a common framework, a Zope3-ish framework if possible. Florent Tres wrote: > Sidnei da Silva wrote: > > > Is there any concrete plan for adding Events to CMF? It would be > > really nice if we could somehow use Five for that, but given all the > > constraints, what options we have? > > Events are the major new feature planned ATM for CMF 1.6. My intent for > them was to use the "thrown-over-the-wall" Zope 2 event products as a basis: > > - http://cvs.zope.org/Products/Event > > - http://cvs.zope.org/Products/EventListenerTool > > as the basis for a CMFEvent product. Those tools are used in production > in very large sites, and have been pounded pretty hard. Note that the > listener tool allows you to define interface-based subscriptions, which > invoke arbitrary scripts: that is a pretty powerful combination. > > We would then modify the current content classes to pubish events > (following the Zope3 pattern as closely as possible) rather than > directly notifying the workflow, or cataloguing themselves, and make the > appropriate tools subscribers via the listener tool. > > > I've implemented a very simple event registry, highly based on Zope3 > > events, which I think would be more than enough for most of the use > > cases. Would anyone be interested in adding this into CMF while we > > wait for the day some Zope3 stuff gets merged into Zope2? > > > > Doctest attached. The implementation is about the same number of lines > > as the doctest *wink*. > > The tools above are "placeful" ("local" in the Zope3 sense), which seems > to be more Zope2 / CMF like than the global one (they allow > subscriptions to persist across restarts, for one thing). -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg(a)nuxeo.com

4 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Zope-Dev December 2004