Re: [Zope-dev] z3c.form 2.0
Laurent Mignon laurent.mig...@softwareag.com writes: Stephan Richter wrote: On Tuesday 10 February 2009, Laurent Mignon wrote: With the replacement of zope.app.component import with zope.site, it's no more possible to use z3c.form with Zope2 / Plone :-( Thanks for getting our attention on this. I consider this a show-stopper for 2.0. Dan, let's think about something creative that allows us to use the new and old way, maybe through a special import statement like that: try: import zope.site except ImportError: import zope.container or something like that. Regards, Stephan Thanks also for your attention, the problem was in my buildout configuration as suggested by 'Dan Korostelev' Adding the following lines to my buildout solves the problem: additional-fake-eggs = zope.schema = 3.4.0 zope.location = 3.4.0 ZODB3 = 3.8.1 It would be nice if we could move these to an extends= file, so that people don't have to maintain this list in their own buildouts. -- http://danielnouri.org ___ 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 )
[Zope] Re: Problems with buildout and zope.interface
Christian Scholz writes: I am trying right now to convince people to use buildout and ZCA for the Open Grid Protocol project but it turns out that it's not working as expected. So maybe somebody on here can help me :-) The setup is Mac OSX 10.5.4 with Python 2.5.1 installed and apparently a zope.interface egg inside the standard install of Python of version 3.3.0. (you can see the contents of the lib dir her: http://pastebin.com/d3f5fb455) On some machines it now seems that this version is used instead of using a newer one the system wide installed one is used (for some reason not on my own machine), so the for instance the testrunner script looks like this: http://pastebin.com/d1a1024d2 The solution to this one is quite simple: Use virtualenv with --no-site-packages and then use bin/python to run bootstrap.py -- Daniel Nouri http://danielnouri.org ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: Problems with buildout and zope.interface
Christian Scholz: Daniel Nouri wrote: The solution to this one is quite simple: Use virtualenv with --no-site-packages and then use bin/python to run bootstrap.py Ok, thanks. How do I deploy such a thing? I guess virtualenv then has to run by the one setting up his development sandbox? What files can/need to be in subversion? (I never used virtualenv before, only buildout). So my main question is probably: Is there a way to automate the process of installing and running virtualenv similar to what bootstrap.py does for buildout so that people do not need to care about the virtualenv part? This shell script should help: #!/bin/sh sudo easy_install virtualenv virtualenv . --no-site-packages bin/python bootstrap.py -- Daniel Nouri http://danielnouri.org ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: how to unindex an non existing (deleted)object
robert rottermann writes: Sometimes a catalog query returns brains that point to non existing objects. how can I remove such brains from the index programmatically without using the portal_catalag/advanced/update tab? brain.aq_parent._catalog.uncatalogObject(brain.getPath()) Daniel ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-dev] Re: What happened to the infrae.subversion and py eggs?
Reinout van Rees [EMAIL PROTECTED] writes: Tres Seaver schreef: Daniel Nouri wrote: 1.0dev-r27844 seems to be gone from PyPI. Such a version should *never* have been released to PyPI (any egg / source dist with an SVN revision number in its filename is *not* suitable for sharing with the wider world). I've made it a habit *not* to enable the option in setup.cfg that adds those svn revision numbers to the version. It is enabled by default in all/most of the ZopeSkel-generated packages that I use. That single change forces me to maintain a proper version number in the setup.py (0.9 dev 3 for development versions). That is the spot where you make a change anyway when doing a release. It is wy too easy to forget to remove the subversion revision option from setup.cfg (and having to enable it again after the release). For making releases, I create a tag and remove the setup.cfg file from that tag. No need to remove it from trunk. Also see [1] and [2]. And I agree with Wichert that for non-public packages, these development snapshot releases can be useful. [1] http://peak.telecommunity.com/DevCenter/setuptools#managing-continuous-releases-using-subversion [2] http://peak.telecommunity.com/DevCenter/setuptools#making-official-non-snapshot-releases Daniel ___ 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 )
[Zope-dev] Re: Five and browser-oriented components
Malthe Borch [EMAIL PROTECTED] writes: On Z2, certain imports need to come from Products.Five, to play nicely with ZPublisher and friends. I'd like to ask for the motivation for not patching it onto the existing classes and/or modules. The effect of having Z2-developers import from Products.Five is that they must opt out on packages that make use of templates, browser views, formlib, ... --- and it adds needless complexity. IMO, any implicitness here will eventually slap you in your face, cause bugs, and be hard to figure out. I already dislike the way that e.g. FiveFormLibMixin implicitly changes my request to be more conform with formlib . This has caused confusion and pain for me in the past. Therefore, I'd argue that we should, in contrary to what you suggest, make the Zope 2 compatibility layer more explicit in the form of utility functions, instead of more implicit. Because it makes things more transparent and easier to debug. One concrete argument against patching the Zope 3 view page template in Five to be Zope 2 conform is that this would stand in the way of legitimate use of pure Zope 3 views in Zope 2 applications, which is something that's quite feasible today. We don't to lock ourselves into a situation where Z3 templates in Z2 assume that the view is acquisition wrapped. Daniel ___ 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 )
[Zope-dev] Re: Five and browser-oriented components
Malthe Borch [EMAIL PROTECTED] writes:
Daniel Nouri wrote:
Therefore, I'd argue that we should, in contrary to what you suggest,
make the Zope 2 compatibility layer more explicit in the form of utility
functions, instead of more implicit. Because it makes things more
transparent and easier to debug.
You might be right; but it's a very bad place to be, stuck in the
middle of two frameworks. We're duplicating code all over the place,
and while this has obvious inherent qualities, it also wears us out as
a community.
I think I found a useful pattern for how to work with z3c.forms to avoid
duplication. For each page that has forms, I make two views; one is the
Products.Five.BrowserView view that's looked up by the publisher and is
registered with ZCML. The other is my z3c.form.form.Form that does the
actual work and renders my content area. The relationship between these
two forms is similar to that of forms and subforms.
Here is an example of how this looks like in practice:
class MyForm(z3c.form.form.Form):
template = Z3ViewPageTemplateFile('form.pt')
fields = z3c.form.Fields(ISomething)
@button.buttonAndHandler(_('Apply'), name='apply')
def handle_apply(self, action):
data, errors = self.extractData()
# ...
class PloneView(Products.Five.BrowserView):
__call__ = Z2ViewPageTemplateFile('main.pt')
form = MyForm
def contents(self):
z2.switch_on(self)
return self.form(self.context.aq_inner, self.request)()
Here, main.pt is the part that renders main_template and pulls in
view/contents into the content area.
z2.switch_on() is a compatibility function that fiddles a bit with the
Zope 2 request to make it work with z3c.form (and also calls Five's
decodeInput).
Of course, PloneView is generic enough to be subclassed at this point:
class MyFunnyView(PloneView):
form = MyFunnyForm
What's the advantage of this separation?
- You don't have to worry about Acquisition in your form code, which
will make out the bigger part of your code. The implications of
Five's BrowserView being derived from Acquisition.Explicit has often
left me confused. (Death to self.context.aq_inner!)
- You can reuse form code between Zope 2 and Zope 3.
- Your forms can be rendered in any part of your page, like in
portlets.
- No subclassing of classes in z3c.form is necessary to use the forms
in Zope 2. (In contrast to Five's current way of subclassing
formlib.)
Daniel
___
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 )
[Zope-dev] Re: What happened to the infrae.subversion and py eggs?
Maurits van Rees [EMAIL PROTECTED] writes:
Luckily for demonstration purposes this at least fails in a
virtualenv:
===
$ bin/easy_install infrae.subversion==1.0dev_r27844
Searching for infrae.subversion==1.0dev-r27844
Reading http://pypi.python.org/simple/infrae.subversion/
Reading https://svn.infrae.com/buildout/infrae.buildout/trunk/
No local packages or download links found for infrae.subversion==1.0dev-r27844
error: Could not find suitable distribution for
Requirement.parse('infrae.subversion==1.0dev-r27844')
===
So has that version of the egg been removed from the cheeseshop? And
can it be brought back? I have buildouts that are pinned to that
version for stability and I would like those to work half a year from
now (or in fact tomorrow) in case I have to rebuild those buildouts on
a new server. You never know when that meteor will hit your data
center. ;-)
1.0dev-r27844 seems to be gone from PyPI. I'm CCing Sylvain who I
believe made the last release. Maybe we can even convince him to make a
proper release, not an SVN snapshot. :-)
Of course, we should also make sure that the latest version works
properly with its pinned py dependency.
Daniel
___
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 )
[Zope-dev] Re: AW: [Checkins] SVN: z3c.jbot/ Initial import.
Philipp von Weitershausen wrote: btw, I think since we use buildout, it's not possible to implement mixed Zope3/Five packages bacause setup has to define the Five packages too. right? In general, it makes the reuse of a package difficult if it depends on Zope 2 stuff (incl. Five). As Malthe explains, the implementation does not depend on Five, the tests do. Is he supposed to put the Five dependent tests into a different package? I think there's little to gain from that, and the added burden of having two packages. And, I don't see why patching a base class that both Zope 3 and Zope 2 share is a magic dependency. Daniel ___ 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 )
[Zope-dev] Re: products not found when initializing zodb
Wichert Akkerman wrote: (I've filed this at https://bugs.launchpad.net/zope2/+bug/147201 as well) For a Plone site I am using a separate ZODB for the catalog so I can tune it a bit. I do this using the standard method in zope.conf: zodb_db catalog mount-point /plone.org/portal_catalog container-class Products.CMFPlone.CatalogTool.CatalogTool zeoclient server 127.0.0.1:5010 storage 2 name catalogstorage var /srv/plone.org/buildout/parts/instance1/var /zeoclient /zodb_db This works perfect in a normal Zope2 instance. But when I use buildout CMFPlone is stored in a separate directory that is listed in a products line in zope.conf: instancehome /srv/plone.org/buildout/parts/instance1 products /srv/plone.org/buildout/products products /srv/plone.org/buildout/parts/productdistros products /srv/plone.org/buildout/parts/plone the result is that Zope no longer starts: Error: The object named by Products.CMFPlone.CatalogTool.CatalogTool could not be imported Traceback (most recent call last): File /srv/plone.org/buildout/parts/zope2/lib/python/Zope2/Startup/datatypes.py, line 94, in importable_name package = __import__(n, g, g, component) ImportError: No module named CMFPlone IIRC, patching Zope2/Startup/zopeschema.xml to use string as the datatype for container-class instead of .python_dotted_path fixes the problem. (To find out where container-type is used in Python code, grep for container_type.) Daniel ___ 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 )
[Zope-dev] Re: Zope2 and eggs
Wichert Akkerman wrote: I wanted to share a bit of experience I just had with use of eggs in Zope2. For a project I am working on I want to use the zope.sendmail package in a Zope2 environment managed using buildout. I added zope.sendmail to the eggs list in the buildout configuration and ran buildout. This pulled in a large part of the Zope3 packages. This produced conflicts between those packages and the ones included in Zope2 which resulted in a pretty boken instance: easy_install has a --no-deps option. Maybe that's supported in buildout? Daniel ___ 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 )
[Zope-dev] Re: Zope2 and eggs
Wichert Akkerman wrote: Previously Daniel Nouri wrote: Wichert Akkerman wrote: I wanted to share a bit of experience I just had with use of eggs in Zope2. For a project I am working on I want to use the zope.sendmail package in a Zope2 environment managed using buildout. I added zope.sendmail to the eggs list in the buildout configuration and ran buildout. This pulled in a large part of the Zope3 packages. This produced conflicts between those packages and the ones included in Zope2 which resulted in a pretty boken instance: easy_install has a --no-deps option. Maybe that's supported in buildout? That's a bit of a workaround though. It's a hack, yes. Ideally Zope2 should be an egg which somehow tells buildout/setuptools that it also provides the various zope.* packages it includes at the moment. Similar to the providers-mechanism which packaging systems like dpkg and rpm implement perhaps. Provides and (semi-) virtual packages are going to be essential to deal with swappable components as well. I didn't realize you were working *with* the Zope 2 egg that Philipp created. I don't have any experience with that, still what you're proposing makes much sense to me. Daniel ___ 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 )
[Zope-dev] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)
Martin Aspeli wrote: Ian Bicking wrote: If you use the easy_install script in the workingenv bin/, then you don't have to activate the environment. Very similar to buildout, workingenv scripts contain their path/environment. Right, thanks for pointing that out. I should also mention that, with ploneenv[1], you can run bin/runzope or bin/zopectl without having to activate the workingenv first. Daniel [1] http://danielnouri.org/blog/devel/zope/ploneenv-intro.html ___ 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 )
[Zope-dev] Re: RFC: Eggifying Zope's extension mechanism (Products)
whit wrote:
Philipp von Weitershausen wrote:
Rocky Burt wrote:
On Thu, 2007-25-01 at 05:07 -0800, Martin Aspeli wrote:
I do wonder what would happen if you had both
lib/python/Products/CMFCore
and Products/CMFCore, though. Would there be an explicit preference
or would
Zope fail to start up with a conflict? I think I'd prefer the
latter, in
fact, so that people don't end up modifying/upgrading the wrong code by
accident!
Well, we could probably add conflict-detection to the entry point
handlers for Zope (ie so any two packages that try to register as the
same project would cause an error). But regarding Products/CMFCore and
lib/python/Products/CMFCore conflicting... that would be up to the
standard pythonpath mechanism of the python interpreter (whichever is
first on the path wins).
Zope 2 itself manipulates Products.__path__ to add INSTANCE/Products
(or any other directory specified in zope.conf) as a directory which
can contain further products (the original Products package lives at
ZOPE/lib/python/Products). pkg_resources uses the same mechanism for
namespace packages (that's what the
pkg_resources.declare_namespace('Products') call is all about); it
appends to __path__.
Therefore, Zope will treat /path/to/the/CMFCore-egg/Products as
another directory that contains a product (in this case just one,
CMFCore). Thus the standard product override rules apply when the same
product is installed in multiple directories.
I updated the proposal text with this information.
I imagine it would be pretty trivial to write something that would
generate a setup.py from an svn:externals property so you could create a
Products distribution in one fell swoop, especially since the entry
point section of the setup.py can handle config parser output.
As an example, I'd like to point to my 'install-plone.py' script again,
which does it the other way around. There, the Products/ directory in
SVN pulls in the Products via svn:externals, and the only thing that
remains is 'Products/__init__.py' with the namespace declaration. This
is of course less than ideal for controlling versions (although the
svn:externals might just as well point to a tagged bundle), but maybe
good enough for the 'legacy' (can we call Products that?) code that we have.
BTW, compare the difference in size between that script[1] and
ploneout[2]. I should mention that it does less than ploneout (it
doesn't download Zope 2, but that'd be trivial to add) and it could be
argued that it's less flexible for some definition of flexible. (Sorry
for being OT here.)
[1] http://danielnouri.org/svn/scratch/Plone/trunk/install-plone.py
[2] http://svn.plone.org/svn/plone/ploneout/trunk/
--
Daniel Nouri
Infrae × http://infrae.com
___
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 )
[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
I only know the answer for a few of these... Martin Aspeli wrote: - In my workingenv (i.e. when I've done source bin/activate) I had some trouble using 'paster', because it couldn't find various eggs, e.g. ZopeSkel, Paste, PasteScript, PasteDeploy and Cheetah. What's annoying is that I had to do each one of these manually, i.e. I ran 'easy_install ZopeSkel' and it found the egg (without any trip to the cheese shop), but then it complained about PasteScript, so I did 'easy_install PasteScript', but then it complained about PasteDeploy etc. This is while I'm running 'paster create'. Did I do something wrong? I think I read somewhere that workingenv can re-use my system PYTHONPATH which may or may not be useful workingenv has the --site-packages option which includes all site packages available at install time. I'm not sure what's going on in your case though, because those dependencies should certainly be tracked down normally, no? - Once I got it up, I used 'paster create -t plone' to create a new project in parts/instance/src/my.package. Is this good practice? I believe you're not supposed to put anything into parts/. parts/ is buildout's playground. - How am I meant to update my plone bundles? I tried running ./bin/buildout -v again, but that wiped my parts/instance directory! It came back, but lacking things like Products/ ... Welcome to the wonderful world of buildout. *scnr* ;-) Daniel ___ 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 )
[Zope-dev] Re: RFC: The future of Products.Five(green eggs and zope)
Tres Seaver wrote: Daniel Nouri wrote: whit wrote: snap We still have to handle the Products issue for add ons(mcdonc, donde estamos con Basketos?). But if Basket is added to 2.11, this might not be such a big deal. From what I know, Basket has been abandoned and there's even no good reason for using it. Inside a workingenv you can just go and install egged Products without problems. Basket gives Zope the framework to tickle the 'initialize' entry point in eggs, which is *not* unnecessary AFAIK. 'intialize' will be called for eggs that use the Products namespace package. If the Product lives outside of Products, it must use the 'five:registerPackage' directive so that its 'initialize' is called. One thing to note is that if you install such an egg that has a Products namespace system-wide, it will be 'initialize'd in every Zope instance. So it's advisable to 1) not use the Products namespace package and rely on 'five:registerPackage' if you need 'initialize' and 2) use workingenv or zc.buildout to install the eggs. Daniel ___ 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 )
[Zope-dev] Re: [z3-five] RFC: The future of Products.Five(green eggs and zope)
Chris McDonough wrote: On Oct 31, 2006, at 11:30 AM, Daniel Nouri wrote: Tres Seaver wrote: Daniel Nouri wrote: whit wrote: snap We still have to handle the Products issue for add ons(mcdonc, donde estamos con Basketos?). But if Basket is added to 2.11, this might not be such a big deal. From what I know, Basket has been abandoned and there's even no good reason for using it. Inside a workingenv you can just go and install egged Products without problems. Basket gives Zope the framework to tickle the 'initialize' entry point in eggs, which is *not* unnecessary AFAIK. 'intialize' will be called for eggs that use the Products namespace package. If the Product lives outside of Products, it must use the 'five:registerPackage' directive so that its 'initialize' is called. I know nothing of five:registerPackage, but Basket's model doesn't care whether or not a package is in the Products namespace. It has two modes: DWIM mode, which calls initialize for all packages in eggs which have a zope2.initialize entry point, and a non-DWIM mode under which you must spell out the packages that should be initialized in a separate INI file (this is akin to using ZCML to spell out each of them). Note that in the model that basket uses, an egg might contain more than one Product as well. The egg contains a 'zope2.initialize' entry point for each product which the egg contains. I've pasted the Basket readme to the end of this email, which explains all of this. I've tried out Basket and failed. I think it doesn't work for Zope 2.9 and newer. However, having installed other Python packages through easy_install before, I also found it a bit unintuitive to use (in theory). I think Basket is overdoing it. Zope 2 doesn't need such a specialized egg story. If we can install eggs the normal way (easy_install) and they work and we can use known techniques (zcml slugs) to include them in an instance, at least *I* am happy. Entry points are definitely great and I do hope that they'll replace zcml slugs soon. That'll have to work for Zope 2 packages too (so five:registerPackage becomes unnecessary) and I think there we can learn from Basket. One thing to note is that if you install such an egg that has a Products namespace system-wide, it will be 'initialize'd in every Zope instance. So it's advisable to 1) not use the Products namespace package and rely on 'five:registerPackage' if you need 'initialize' and 2) use workingenv or zc.buildout to install the eggs. I think the reason that Phillip put entry points in the egg spec is just for this sort of thing. I'm not sure if they're being used now for Zope 2 eggs (or if there even is such a thing), but imo they probably should be. AFAIK, for both Zope 2 and Zope 3 you have to put a zcml slug into package-includes. (For Zope 2 only if you live outside Products though.) Check out Whit's blog entry [1] if you haven't done so. He explains how to set up a workingenv inside a Zope 2 instance. I recently played with a script that installs Plone by setting up a Zope instance combined with a workingenv, and pulling all necessary Products and packages in as eggs [2]. [1] http://bfhammer.blogspot.com/2006/09/bootstrapenvironment.html [2] http://lists.plone.org/pipermail/framework-team/2006-October/000784.html ___ 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 )
[Zope-dev] Re: Five: Feature freeze and release fest tomorrow
Can we put the one line testbrowser patch in, please? Without it,
testbrowser never gets to see Cookie headers, which I consider quite a
PIA. Currently, I'm including the patched version of Five's testbrowser
module in a test for the PasswordResetTool Product here:
http://dev.plone.org/collective/browser/PasswordResetTool/trunk/tests/utils/testbrowser.py
The patch:
Index: testbrowser.py
===
--- testbrowser.py (revision 66810)
+++ testbrowser.py (working copy)
@@ -35,6 +35,7 @@
headers.sort()
headers.insert(0, ('Status', %s %s % (status, reason)))
headers = '\r\n'.join('%s: %s' % h for h in headers)
+headers += '\r\n' + '\r\n'.join(real_response._cookie_list())
content = real_response.body
return testing.PublisherResponse(content, headers, status, reason)
Daniel
___
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 )
