Re: [Zope-dev] How to include a
On Mon, 2009-05-25 at 15:48 +0200, Hermann Himmelbauer wrote:
> Hi,
>
> [...]
>
> What I'd like to have now is to include some other CSS-file with
> media="print".
> The zc.resourcelibrary code seems not to be able to handle this, so I'm
> curious how to do this:
>
> 1) Simply write this directly into my page template
> 2) Hack zc.resourcelibrary, e.g. add a ZCML-directive "media"
> 3) Use some other package I'm unaware of
>
> Any suggestions?
4)
Just have it included as is and add the following section:
@media print {
@import url (print.css);
}
--
Christian Theune · c...@gocept.com
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1
Zope and Plone consulting and development
signature.asc
Description: This is a digitally signed message part
___
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] XML-RPC does not work under the paster process
On Mon, 2009-05-25 at 17:08 +0200, Michael Haubenwallner wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Christian Theune wrote: > > [...] > > > > Nevertheless: passing in 0 seems to be the safe bet in general and I > > wonder what is actually breaking. I haven't seen a traceback be attached > > at either bug. Also, those bugs should probably be marked as duplicates. > > > > You are right, looking at the problem again i suggest to add this change > to zope.publisher.xmlrpc Uhhhm. Why are we changing this? IMHO passing 0 should work and I don't see what the actual breakage is. > - --- src/zope/publisher/xmlrpc.py(revision 100356) > +++ src/zope/publisher/xmlrpc.py (working copy) > @@ -46,10 +46,14 @@ > 'See IPublisherRequest' > # Parse the request XML structure > > - -# XXX using readlines() instead of lines() > - -# as twisted's BufferedStream sends back > - -# an empty stream here for read() (bug) > - -lines = ''.join(self._body_instream.readlines()) > +# XXX using readline() instead of readlines() > +# as readlines() is not working with > +# paster.httpserver > +line = 1 > +lines = '' > +while line != '': > +line = self._body_instream.readline() > +lines += line > self._args, function = xmlrpclib.loads(lines) I'm fine with the patch. I just don't understand why we need it. :/ Here's a small readability suggestion: lines = '' while True: line = self._body_instream.readline() if not line: break lines += line I think assigning assigning an unused value can lead to confusions and the head-controlled loop obfuscates whats actually going on. Cheers, Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ 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] SVN: zope.app.pagetemplate/tags/3.7.0/src/zope/app/pagetemplate/tests/test_simpleviewclass.py Coverage.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > On Monday 25 May 2009, Tres Seaver wrote: >> Log message for revision 100382: >> Coverage. > > On a tag? My bad: I switched a checkout to the tag to make a release. Note that I then further borked the tag by recopying the trunk there. I have since erased the tag and recopied from the trunk at the original revision. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKG0vw+gerLs4ltQ4RAnW6AJ9cMZNSFU5Aiw5XvKfkcfrF3jUS2ACeOnhT Yg0AnDllgXjc7cA/sE/xLBA= =po29 -END PGP SIGNATURE- ___ 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] RFC: zope.app.pagetemplate.engine dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: > Resolution #3 > = > > Whereas: > > - In Zope2, the 'Products.PageTemplates.Expressions' module depends > on the 'zope.app.pagetemplates.engine' module, but only uses its > 'ZopeEngine' class; > > - Zope2 further supplies its own context class (to avoid using the Zope3 > security model); > > - one remaining bit of non-overridden functionality is the Zope3- > proxified 'getFunctionNamespace' wrapper, which probably won't work > at all as intended; > > - the other bit is the use of the AdapterNamespaces bit, which feeds > into the 'getFunctionNamespace' bit; > > therefore be it resolved: > > - that we forego using the 'ZopeEngine' class completely in Zope2, > providing instead a forked / simplified implementation. Done. Zope2 no longer imports / depnds on zope.app.pagetemplate directly at all. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKG0ef+gerLs4ltQ4RAs+NAJ9auYhR7cdjhueap2XBJHzdSNPc+ACggh9Q pEzQbdFdU6nABlVpO5HoLfU= =A4h8 -END PGP SIGNATURE- ___ 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.app.http/trunk/ - Replaced the dependency on zope.deprecation with BBB imports
Hi Tres > Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/ > - Replaced the dependency on zope.deprecation with BBB imports > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Stephan Richter wrote: > > On Monday 25 May 2009, Shane Hathaway wrote: > >> +- Replaced the dependency on zope.deprecation with BBB imports > > > > As a general question, how will people know that an import > location changed? > > - - By reading changelogs. > > - - By running the "indirect imports checker" script on their code. Sound interesting, what's an "indirect imports checker" script? Regards Roger Ineichen _ END OF MESSAGE ___ 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.app.http/trunk/ - Replaced the dependency on zope.deprecation with BBB imports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > On Monday 25 May 2009, Shane Hathaway wrote: >> +- Replaced the dependency on zope.deprecation with BBB imports > > As a general question, how will people know that an import location changed? - - By reading changelogs. - - By running the "indirect imports checker" script on their code. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKG0by+gerLs4ltQ4RAjlEAKCjfN7dp0PpWvJ4R2CD1V0FqyBHdgCdHVCZ RTj+r6K1y24r5ZN0AZnP6t8= =7AWh -END PGP SIGNATURE- ___ 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.app.http/trunk/ - Replaced thedependency on zope.deprecation with BBB imports
Hi Stephan > -Ursprüngliche Nachricht- > Von: zope-dev-boun...@zope.org > [mailto:zope-dev-boun...@zope.org] Im Auftrag von Stephan Richter > Gesendet: Dienstag, 26. Mai 2009 02:33 > An: zope-dev@zope.org > Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/ > - Replaced thedependency on zope.deprecation with BBB imports > > On Monday 25 May 2009, Shane Hathaway wrote: > > +- Replaced the dependency on zope.deprecation with BBB imports > > As a general question, how will people know that an import > location changed? Some people think it's better to have a nice clean log then deprecation warnings on server startup. I still don't understand the reason if there is any. Probably others can explain why we skip the deprecation warnings which is a hugh win for migration tasks. Regards Roger Ineichen _ END OF MESSAGE ___ 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.app.http/trunk/ - Replaced the dependency on zope.deprecation with BBB imports
On Monday 25 May 2009, Shane Hathaway wrote: > +- Replaced the dependency on zope.deprecation with BBB imports As a general question, how will people know that an import location changed? Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" ___ 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] RFC: zope.app.pagetemplate.engine dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Tres Seaver wrote: >> Resolution #2 >> = >> >> Whereas: > [removing evaluateInlineCode] > > zope.app.catalog: old-fashioned HTTP log test. Not very important. > zope.app.publication: the same > zope.app.exception: the same > > zope.app.session: actually turns on evaluateInlineCode in test setup for > some reason. A discussion topic. > > zope.app.zptpage: actual code and tests that mess around with > evaluateInlineCode. A discussion topic > > zope.app.session seems to be almost wholly moved to zope.session, > leaving some ZMI stuff behind. I think this means we can safely ignore > zope.app.session. > > zope.app.zptpage is the most interesting. It maintains an > evaluateInlineCode attribute and passes it along to > zope.app.pagetemplate. Of course it also is there to support the ZMI. > Since it's unlikely anyone actually has *useful* ZPT pages with inline > code, as nobody is programming with the ZMI anyway, I propose we just > rip this support out of here. But this can be done later when we see > things break. > > +1 for removing it. Ah, the code refered to 'zope.app.pythonpage', but should have been talking about 'zope.app.zptpage'. It should be simple for that package to pick up the implementation of 'evaluateCode' and add it to a custom 'ZopeContext' derivative which it uses when evaluating the page. >> Resolution #3 >> = > > I'm fine with this, though haven't done any real analysis. :) This is a "back to the future" change (or feels like it, anyway). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKGvvR+gerLs4ltQ4RAgOEAKDLvaaqnviDYek692cnSER/qqlFiACgmhB8 AIiZKBXxgJ/5pZFW41vAQ10= =/cMi -END PGP SIGNATURE- ___ 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] RFC: zope.app.pagetemplate.engine dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: > Resolution #1 > = > > Whereas: > > - The 'zope.app.pagetemplate.engine' module pulls in nothing from > 'zope.app' packages except some antique testing support in doctest; > > - that module is potentially useful outside the scope of the Zope3 ZMI; > > therefore be it resolved: > > - that we move the 'engine' module to 'zope.pagetemplate', along with > its supporting scaffolding, and clean up the tests. Done, and released in the following: - http://pypi.python.org/pypi/zope.pagetemplate/3.5.0 - http://pypi.python.org/pypi/zope.app.pagetemplate/3.7.0 I also had to release an updated 'zope.app.publisher', in order to get the tests for 'zope.app.pagetemplate' to pass: the older version was depending on being able to import the 'engine' module from the old location: http://pypi.python.org/pypi/zope.app.publisher/3.8.1 Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKGvqk+gerLs4ltQ4RAtQVAKCCaozyXLF8zz9P7sTG/EbeFZdpeQCfRawJ wevk9XNVT7RGFRKfYV6nFJA= =tbs9 -END PGP SIGNATURE- ___ 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] RFC: zope.app.pagetemplate.engine dependencies
Tres Seaver wrote: > Resolution #1 > = +1 > Resolution #2 > = > > Whereas: [removing evaluateInlineCode] zope.app.catalog: old-fashioned HTTP log test. Not very important. zope.app.publication: the same zope.app.exception: the same zope.app.session: actually turns on evaluateInlineCode in test setup for some reason. A discussion topic. zope.app.zptpage: actual code and tests that mess around with evaluateInlineCode. A discussion topic zope.app.session seems to be almost wholly moved to zope.session, leaving some ZMI stuff behind. I think this means we can safely ignore zope.app.session. zope.app.zptpage is the most interesting. It maintains an evaluateInlineCode attribute and passes it along to zope.app.pagetemplate. Of course it also is there to support the ZMI. Since it's unlikely anyone actually has *useful* ZPT pages with inline code, as nobody is programming with the ZMI anyway, I propose we just rip this support out of here. But this can be done later when we see things break. +1 for removing it. > Resolution #3 > = I'm fine with this, though haven't done any real analysis. :) Regards, Martijn ___ 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] RFC: zope.app.pagetemplate.engine dependencies
Chris McDonough wrote: > On 5/25/09 12:37 PM, Tres Seaver wrote: >> >> Debate, anyone? > > +1. +1, you? ;) Hanno ___ 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] Zope Tests: 5 OK, 3 Failed
Zope Tests Summarizer wrote: > Summary of messages to the zope-tests list. > Period Sun May 24 12:00:00 2009 UTC to Mon May 25 12:00:00 2009 UTC. > There were 8 messages: 8 from Zope Tests. > > Test failures > - > > Subject: FAILED (failures=1) : Zope-trunk-alltests Python-2.4.6 : Linux > From: Zope Tests > Date: Sun May 24 20:57:53 EDT 2009 > URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011790.html > > Subject: FAILED (failures=1) : Zope-trunk-alltests Python-2.5.4 : Linux > From: Zope Tests > Date: Sun May 24 20:59:55 EDT 2009 > URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011791.html > > Subject: FAILED (failures=1) : Zope-trunk-alltests Python-2.6.1 : Linux > From: Zope Tests > Date: Sun May 24 21:01:55 EDT 2009 > URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011792.html These have been my fault, but Stefan fixed the problem already :) Hanno ___ 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] package dependency refactoring progress report
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shane Hathaway wrote: > Ok, I've replaced all the zope.deprecation imports I added with BBB. > What does BBB stand for anyway? "Backward compatibility": we started using it as an easy-to-find marker in code some time back. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKGs6q+gerLs4ltQ4RAnpmAJ47Mp0Sq2jTMHhMIHN7CZUciqlSEQCffmzd OojorvtM5cvb9++J7ce6/ls= =g20Z -END PGP SIGNATURE- ___ 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] RFC: zope.app.pagetemplate.engine dependencies
On 5/25/09 12:37 PM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Resolution #1 > = > > Whereas: ..snip.. > Debate, anyone? +1. - C ___ 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] package dependency refactoring progress report
Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Shane Hathaway wrote: >> Martijn Faassen wrote: >>> It's interesting to see zope.deprecation is a new dependency. We could >>> consider changing these deprecations to simple imports if this is >>> possible... >> Certainly, but what is the right way to deprecate code, then? I'm not >> very happy about including zope.deprecation either, since it uses the >> sys.modules trick just like zope.deferredimport, but those deprecation >> warnings are important, aren't they? > > Not so much, IMO. I think we can leave simple BBB imports in place, > warning-free, forever (with a '#BBB' comment so that people don't delete > them as unused imports). Ok, I've replaced all the zope.deprecation imports I added with BBB. What does BBB stand for anyway? Shane ___ 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] RFC: zope.app.pagetemplate.engine dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Resolution #1 = Whereas: - - The 'zope.app.pagetemplate.engine' module pulls in nothing from 'zope.app' packages except some antique testing support in doctest; - - that module is potentially useful outside the scope of the Zope3 ZMI; therefore be it resolved: - - that we move the 'engine' module to 'zope.pagetemplate', along with its supporting scaffolding, and clean up the tests. Resolution #2 = Whereas: - - The 'evaluateInlineCode' support in the 'engine' module has no tests; - - its comments indicate that it exists to support 'zope.app.pythonpage', which doesn't even import the module; - - third-party consumers of the feature have a recently-released version of the egg which they can continue using indefinitely; therefore be it resolved: - - that we remove the code entirely, documenting the backward incompatibility in a new feature release. Resolution #3 = Whereas: - - In Zope2, the 'Products.PageTemplates.Expressions' module depends on the 'zope.app.pagetemplates.engine' module, but only uses its 'ZopeEngine' class; - - Zope2 further supplies its own context class (to avoid using the Zope3 security model); - - one remaining bit of non-overridden functionality is the Zope3- proxified 'getFunctionNamespace' wrapper, which probably won't work at all as intended; - - the other bit is the use of the AdapterNamespaces bit, which feeds into the 'getFunctionNamespace' bit; therefore be it resolved: - - that we forego using the 'ZopeEngine' class completely in Zope2, providing instead a forked / simplified implementation. Debate, anyone? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKGsle+gerLs4ltQ4RAgNKAJwOyvPTdkV40l6YaE7LgXNvts9eagCdHlRF WYPBpVkAXT7nBhX9hSTj9rY= =5xWq -END PGP SIGNATURE- ___ 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] How to include a
Hey, Hermann Himmelbauer wrote: [snip] > 1) Simply write this directly into my page template > 2) Hack zc.resourcelibrary, e.g. add a ZCML-directive "media" > 3) Use some other package I'm unaware of hurry.resource (an improved take on zc.resourcelibrary's idea) can't do this right now either, but I suspect it's more hackable than zc.resourcelibrary. Let me know if you want to hack on it. Regards, Martijn ___ 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] XML-RPC does not work under the paster process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: > On Wed, 2009-03-18 at 13:12 +0100, Michael Haubenwallner wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Michael Haubenwallner wrote: >>> When using paste.httpserver instead of twisted.wsgi server >>> zope.publisher.xmlrpc.XMLRPCRequest.processInputs() hangs when reading 0 >>> Bytes from the request (wsgi.input ). >>> >>> As i found the zope.publisher.http.HTTPInputStream.readlines() signature >>> was changed 3 years ago >>> from readlines(self, hint=None) >>> to readlines(self, hint=0) >>> http://svn.zope.org/Zope3/trunk/src/zope/publisher/http.py?rev=66941&r1=66940&r2=66941 >>> >>> Do you think we could revert the change? >>> >>> Bugs reported: >>> zopeproject: https://bugs.launchpad.net/zope3/+bug/283089 >>> grokproject: https://bugs.launchpad.net/grok/+bug/332063 >>> >> Bump - maybe my description was too complicated, but the issue is serious: >> >> XMLRPC is broken at least with paste.httpserver >> >> Any input on the implications of reverting the change in revision #66941? > > I've looked at the various APIs of actual objects that need to consume > the size hint parameter (cStringIO, StringIO, file, socket._fileobject). > > All of them should be fine getting a 0 as an argument, but file and > cStringIO will break if they get `None` instead of 0: > > Type| readlines() | readlines(None) | readlines(0) > +-+-+-- > file| works | TypeError | works > StringIO| works | works | works > cStringIO | works | TypeError | works > socket._fileobject [1]_ | works | works | works > > .. [1] I've only looked at the code and reasoned about this. > > What I'm puzzled about is that the commit message of 66491 mentions > compatibility to StringIO but that would have worked just fine with > `None`. So this either actually means "compatibility with file" or > "compatibility with cStringIO". > > Nevertheless: passing in 0 seems to be the safe bet in general and I > wonder what is actually breaking. I haven't seen a traceback be attached > at either bug. Also, those bugs should probably be marked as duplicates. > You are right, looking at the problem again i suggest to add this change to zope.publisher.xmlrpc - --- src/zope/publisher/xmlrpc.py (revision 100356) +++ src/zope/publisher/xmlrpc.py(working copy) @@ -46,10 +46,14 @@ 'See IPublisherRequest' # Parse the request XML structure - -# XXX using readlines() instead of lines() - -# as twisted's BufferedStream sends back - -# an empty stream here for read() (bug) - -lines = ''.join(self._body_instream.readlines()) +# XXX using readline() instead of readlines() +# as readlines() is not working with +# paster.httpserver +line = 1 +lines = '' +while line != '': +line = self._body_instream.readline() +lines += line self._args, function = xmlrpclib.loads(lines) The fix was proposed by jens Klein, see https://bugs.launchpad.net/zope3/+bug/283089/comments/3 If noone objects i will add it to the zope.publisher 3.4 branch and make a release (3.4.8). The fix is needed at least for Grok to make XMLRPC work with paster.httpserver. Regards Michael - -- http://blog.d2m.at http://planetzope.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKGrR4l0uAvQJUKVYRAh1hAKCJDDSM/MDeuuzOn9jddnZWsfI2IACgnWOi lMnwK3vbJcAYu5miFKXjAH8= =Fxqf -END PGP SIGNATURE- ___ 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] package dependency refactoring progress report
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shane Hathaway wrote: > Martijn Faassen wrote: >> It's interesting to see zope.deprecation is a new dependency. We could >> consider changing these deprecations to simple imports if this is >> possible... > > Certainly, but what is the right way to deprecate code, then? I'm not > very happy about including zope.deprecation either, since it uses the > sys.modules trick just like zope.deferredimport, but those deprecation > warnings are important, aren't they? Not so much, IMO. I think we can leave simple BBB imports in place, warning-free, forever (with a '#BBB' comment so that people don't delete them as unused imports). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKGqrL+gerLs4ltQ4RAmntAJoC0m6i4JKNLStPhFjxSzafVwi5WQCePYIt aFTuMo+AEkc/j06AmEvZVRY= =PgZh -END PGP SIGNATURE- ___ 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] How to include a
Hi, I'm currently to make my application printer-friendly, thus I'd like to include a print-CSS file. Currently, I include CSS-files like that: This creates the following code: What I'd like to have now is to include some other CSS-file with media="print". The zc.resourcelibrary code seems not to be able to handle this, so I'm curious how to do this: 1) Simply write this directly into my page template 2) Hack zc.resourcelibrary, e.g. add a ZCML-directive "media" 3) Use some other package I'm unaware of Any suggestions? Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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] Zope Tests: 5 OK, 3 Failed
Summary of messages to the zope-tests list. Period Sun May 24 12:00:00 2009 UTC to Mon May 25 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Test failures - Subject: FAILED (failures=1) : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Sun May 24 20:57:53 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011790.html Subject: FAILED (failures=1) : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Sun May 24 20:59:55 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011791.html Subject: FAILED (failures=1) : Zope-trunk-alltests Python-2.6.1 : Linux From: Zope Tests Date: Sun May 24 21:01:55 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011792.html Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Sun May 24 20:47:37 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011785.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sun May 24 20:49:41 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011786.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Sun May 24 20:51:45 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011787.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Sun May 24 20:53:46 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011788.html Subject: OK : Zope-trunk Python-2.6.1 : Linux From: Zope Tests Date: Sun May 24 20:55:52 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011789.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 )
Re: [Zope-dev] package dependency refactoring progress report
Shane Hathaway wrote: > Martijn Faassen wrote: >> It's interesting to see zope.deprecation is a new dependency. We could >> consider changing these deprecations to simple imports if this is >> possible... > > Certainly, but what is the right way to deprecate code, then? We've just started to do imports instead, with a BBB comment. The idea is that tools exist (or almost-exist) that can report on indirect imports; the test runner has such an extension, though I believe it's still sitting on a branch. The idea is also that plain imports are better understood by random Python programmers. >> Knowing there are no cycles besides the zope.container one, this graph >> starts to look comprehensible, that's good. :) > > It's still really big though. Hmph. Yes. I think zope.container and zope.site are interesting candidates to look at removing as dependencies. I saw one dependency on getSite in zope.app.publisher (the rest are test dependencies)... I wish we could separate zope.site into two packages somehow. One would just contain the interfaces describing how to get to a site, and a way to easily *test* with sites, a testing module (I have some code sitting around that could help there). The other would actually implement a site in relation to containers. This work might be a good opportunity as well to think about renaming the word "site" to something else, as "site" isn't that great a word for a local component registry. The only direct dependency on zope.container (not through zope.site) is in zope.app.publisher.xmlrpc, in ZCML (see other discussion about zope.xmlrpcview, another reason to split this off :). The dependency of zope.app.pagetemplate on zope.dublincore is also relatively weak. Regards, Martijn ___ 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] package dependency refactoring progress report
Shane Hathaway wrote: > Martijn Faassen wrote: >> I'm not sure about zope.rest; there's already a z3c.rest which likely >> does something quite different, and I think a "zope.rest" package should >> actually *talk* about REST. What about "zope.httpview" instead? > > Well, no, I don't think it's generic enough to call that. zope.app.http > is almost a webdav implementation, except I'm not sure it implements > enough to actually work with most webdav clients. Maybe we'll leave this behind in zope.app.* space for the moment and focus on the others, then? >> Another note, I think we should consider splitting off >> zope.app.publisher.xmlrpc, which looks quite independent from the rest, >> into its own package. So: >> >> zope.app.publisher -> zope.view, zope.xmlrpcview > > I've pondered this split before, but AFAICT it would only increase the > number of dependencies, so I've been waiting for the graph to shrink > before talking about it. It would allow a whole chunk of code to be cut out for those people who don't care about XMLRPC or don't even want to enable it on their server. The reason I bring it up now is because this split would be best done while we are moving things out of zope.app.publisher anyway. If we did it afterwards, we'd need a backwards compatibility dependency from zope.view on zope.xmlrpcview. Regards, Martijn ___ 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] package dependency refactoring progress report
Martijn Faassen wrote: > I'm not sure about zope.rest; there's already a z3c.rest which likely > does something quite different, and I think a "zope.rest" package should > actually *talk* about REST. What about "zope.httpview" instead? Well, no, I don't think it's generic enough to call that. zope.app.http is almost a webdav implementation, except I'm not sure it implements enough to actually work with most webdav clients. > Another note, I think we should consider splitting off > zope.app.publisher.xmlrpc, which looks quite independent from the rest, > into its own package. So: > > zope.app.publisher -> zope.view, zope.xmlrpcview I've pondered this split before, but AFAICT it would only increase the number of dependencies, so I've been waiting for the graph to shrink before talking about it. Shane ___ 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] package dependency refactoring progress report
Martijn Faassen wrote: > It's interesting to see zope.deprecation is a new dependency. We could > consider changing these deprecations to simple imports if this is > possible... Certainly, but what is the right way to deprecate code, then? I'm not very happy about including zope.deprecation either, since it uses the sys.modules trick just like zope.deferredimport, but those deprecation warnings are important, aren't they? > Knowing there are no cycles besides the zope.container one, this graph > starts to look comprehensible, that's good. :) It's still really big though. Hmph. Thanks for the new graphs! Shane ___ 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 )
