Re: [Zope] zopectl does not terminate
Tres Seaver wrote: - abort the current transaction - sync its database connection (to pick up the changed objects) I'm pretty sure the abort has done the sync for quite some time now... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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 )
Re: [Zope] zopectl does not terminate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: Tres Seaver wrote: - abort the current transaction - sync its database connection (to pick up the changed objects) I'm pretty sure the abort has done the sync for quite some time now... Nope, see: http://svn.zope.org/ZODB/trunk/src/ZODB/Connection.py 'sync()' calls 'self.transaction_manager.abort()', actually. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJwNz7+gerLs4ltQ4RArhUAJ0fyhrGauOor35ailUIcjfRQNd9zACeOt+5 f/7g2A2lUZmxo6tyom/OFO8= =c63W -END PGP SIGNATURE- ___ 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] Question about InvariantsValidator on a GroupForm (z3c.form)
Hi all,
i'm having a problem getting an InvariantsValidator working on a grouped form
using z3c.form. Imagine the following setup:
class GroupOne(Group):
fields = Fields(IMyForm).select('second_attribute', 'third_attribute')
class GroupTwo(Group):
fields = Fields(IMyForm).select('fourth_attribute', 'fifth_attribute')
class MyForm(GroupForm, Form):
fields = Fields(IMyForm).select('first_attribute')
groups = (GroupOne, GroupTwo)
Now, the z3c.form.validator.Data object passed to my InvariantsValidator only
contains the 'first_attribute'. I think this is caused by line 190 in field.py:
def validate(self, data):
fields = self.form.fields.values()
Why is this method only looking for form.fields and not aggregating form.fields
and possible form.groups?
Is it an unsupported use case, or am i just not getting it?
Thanks,
Oliver
___
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 )
Re: [Zope-dev] [zope.testbrowser] r84900
Malthe, On Mon, 2009-03-09 at 19:57 +0300, Malthe Borch wrote: Code snippet: def open(self, url, data=None): See zope.testbrowser.interfaces.IBrowser url = str(url) This string coercion is unfortunate, because ``mechanize`` accepts a (mechanize-) request-object in place of a URL string here. Using a custom request object allows us to do such things as setting the REQUEST_TYPE header string, which is not possible throught the standard API. Changeset comment: - Remove vendor import of mechanize. - Fix bug that caused HTTP exception tracebacks to differ between version 3.4.0 and 3.4.1. - Workaround for bug in Python Cookie.SimpleCookie when handling unicode strings. - Fix bug introduced in 3.4.1 that created incompatible tracebacks in doctests. This necessitated adding a patched mechanize to the source tree; patches have been sent to the mechanize project. Not sure which of the above this coercion is trying to solve, but perhaps it could be solved in a way that didn't break the mechanize functionality. Did this get resolved by any means? As it didn't spur any discussion at all, you might want to at least file a bug tracker issue for that problem. 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] [zope.testbrowser] r84900
2009/3/18 Christian Theune c...@gocept.com: Did this get resolved by any means? As it didn't spur any discussion at all, you might want to at least file a bug tracker issue for that problem. It has now been filed as https://bugs.launchpad.net/zope3/+bug/344680. \malthe ___ 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.component/trunk/ Merge the 'tseaver-wo_zope_deferredimport' branch:
Hi, On Tue, 2009-03-10 at 04:18 +0300, Dan Korostelev wrote: 2009/3/5 Martijn Faassen faas...@startifact.com: Chris Withers wrote: Martijn Faassen wrote: I think we can only make the correct determination if we get an idea of the performance implications. If it turns out the C code brings significant speedups in real-world applications, we should create a zope.hookable with a Python + C implementation. Even if it does bring significant speedups, why does it need to be a seperate package? It doesn't, but it's already a package that could be easily turned into something with proper documentation (it's mostly there, just hidden), and one of the goals was to reduce C dependencies in zope.component, not add C code to it. Let's decide that and make a release of zope.component so we could move forward on adapting other packages to recent removal of BBB interfaces. Here's three variants: * Move pure python implementation to zope.hookable as a fallback. * Move C implementation to zope.component and drop zope.hookable dependency at all. * Just drop zope.hookable dependency, providing only pure python version of hookable. I'm -1 on version 3. Whether to keep it as a separate module IMHO depends on the usefulness of the C implementation. If we drop it then we can IMHO live without the standalone package. If we keep two implementations then I'd move both of them to a separate package. 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] ZPT attributes and
On Tue, 2009-03-10 at 10:50 -0400, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Malthe Borch wrote: 2009/3/10 Fred Drake fdr...@gmail.com: The change would need to be in zope.tal. True. I'm ambivalent; while it makes sense to me in isolation, the affect on existing templates is undesirable, and compatibility is a huge deal for this bit of machinery. I agree, but it would be interesting to gauge the usage of this functionality (e.g. if everyone could put a breakpoint in the right place, run their apps and check). Actually, I think this is a bug; why would the empty string not be printed? If we can agree it's a bug, then I guess it should be fixed as part of the general maintenance of the package. At any rate, if we did change/fix the behavior, a warning should probably be issued. If an attribute == then log a warning such as The behavior of this has changed. Make sure your templates are updated. It seems like we ought to start emitting the warnings first, and then fold in the new behavior as the default later. Maybe we could allow some kind of configuration to enable the newer behavior sooner. Ack. Not being able to produce empty attributes is a bug. Fixing it might break apps. Adding an option to enable it first and then moving this to a default setting later is a good way to go, IMHO. I'm not sure how to time the move, though. One option would be to release a bugfix with the option as non-default and a feature release with the option as default. 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] ZPT attributes and
2009/3/18 Christian Theune c...@gocept.com: I'm not sure how to time the move, though. One option would be to release a bugfix with the option as non-default and a feature release with the option as default. That's a good approach. What kind of configuration should enable it; an environment variable or a module global? \malthe ___ 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] ZPT attributes and
On Wed, 2009-03-18 at 10:55 +0300, Malthe Borch wrote: 2009/3/18 Christian Theune c...@gocept.com: I'm not sure how to time the move, though. One option would be to release a bugfix with the option as non-default and a feature release with the option as default. That's a good approach. What kind of configuration should enable it; an environment variable or a module global? Module global please. The global can then be also set using e.g. a configuration option in other programs, like making it configurable from zope.conf. -- 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] zope.password
On Wed, 2009-03-11 at 17:27 +0100, Martijn Faassen wrote: Hi there, Stephan Richter wrote: [snip] In my opinion going for an extra here just to avoid this is speculating a bit too much right now. Do we really have users that want to use zope.password and really don't want zope.component and zope.schema? If so, we'll hear from them when they speak up and *then* declare an extra or take some other action. +1. I want more of our decisions to go into this direction. It is a sign that we turn the # of packages knob as well. I agree with you in the case against extras. It appears though that Dan has a concrete use case for using zope.password in a Pylons app where he isn't interested in zope.component, so I'm +1 on the extra in this case. We'll see whether this leads to difficulties. Luckily the zope.component and zope.schema libraries are typically around anyway so it doesn't make reasoning about the graph that much harder. I remember that at the sprint we used to identify packages which are always good. E.g. zope.interface is a declared no-brainer to add to your dependencies. The other two that keep popping up that we *might* wanna white-list are zope.schema and zope.component. In addition this would need documentation as well. 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] ZPT attributes and
2009/3/18 Roger Ineichen d...@projekt01.ch: This means to me that an empty value for id or name doen't start with [A-Za-z] and is invalid because is must start with [A-Za-z]. or not? Correct, but should enforce these requirements? I think ZPT should just have predictable, expected behavior, but not make too much fuss about syntax. I agree though, that object() or False should probably raise exceptions. \malthe ___ 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] ZPT attributes and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roger Ineichen wrote:
Hi Malthe
Betreff: [Zope-dev] ZPT attributes and
Currently, if an attribute expression evaluates to any value
that's boolean False, it's omitted (e.g. 0, , object()). I
think that's unexpected. Instead, attributes should only be
omitted when the expression evaluates to ``None``.
I think this is better then render empty strings. see below...
How do folks feel about changing this behavior in
``zope.pagetemplate``.
Probably anything else then should be skipped. There is no
logic why object() or False should get rendered as .
Non-true values have special semantics for certain attributes
('checked', 'selected', I think).
I only whould expect that an empty string whould get rendered
as . And probably we should check the HTML specification and
make sure that we only render empty strings for attributes where
they are allowed.
see:
http://www.w3.org/TR/html401/types.html#type-name
ID and NAME tokens must begin with a letter ([A-Za-z]) and
may be followed by any number of letters, digits ([0-9]),
hyphens (-), underscores (_), colons (:), and periods (.).
This means to me that an empty value for id or name
doen't start with [A-Za-z] and is invalid because is must start
with [A-Za-z]. or not?
- -1 on making ZPT / chameleon responsible for enforcing that requirement:
that would be the application's job.
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJwNuY+gerLs4ltQ4RAnvLAJ41d/7G0sHnH7GfX/CV9v+Dw6ksAQCgw+ZC
LfHPVXRoCkejJLyCvLjdvyU=
=ClnO
-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] zope.password
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: On Wed, 2009-03-11 at 17:27 +0100, Martijn Faassen wrote: Hi there, Stephan Richter wrote: [snip] In my opinion going for an extra here just to avoid this is speculating a bit too much right now. Do we really have users that want to use zope.password and really don't want zope.component and zope.schema? If so, we'll hear from them when they speak up and *then* declare an extra or take some other action. +1. I want more of our decisions to go into this direction. It is a sign that we turn the # of packages knob as well. I agree with you in the case against extras. It appears though that Dan has a concrete use case for using zope.password in a Pylons app where he isn't interested in zope.component, so I'm +1 on the extra in this case. We'll see whether this leads to difficulties. Luckily the zope.component and zope.schema libraries are typically around anyway so it doesn't make reasoning about the graph that much harder. I remember that at the sprint we used to identify packages which are always good. E.g. zope.interface is a declared no-brainer to add to your dependencies. The other two that keep popping up that we *might* wanna white-list are zope.schema and zope.component. That woould imply the transitive closure of their dependencies, which would be: - - zope.event - - zope.i18nmessageid - - zope.interface - - zope.component - - zope.schema We would need to finish trimming off the zope.component extras, first. Once done, those pacakges are all essentially libraries, and could be managed as a chunk. In addition this would need documentation as well. Fleshing out the in-package narrative docs for those packages (or perhaps for the set?) would be pretty valuable, too. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJwNge+gerLs4ltQ4RAtV8AKC0+44VxwGBq4n65uwM+ry4xRQfsQCfbQTQ klc7Xe1goO+nSPfaAflpl48= =2+XJ -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] ZPT attributes and
Hi Malthe Betreff: [Zope-dev] ZPT attributes and Currently, if an attribute expression evaluates to any value that's boolean False, it's omitted (e.g. 0, , object()). I think that's unexpected. Instead, attributes should only be omitted when the expression evaluates to ``None``. I think this is better then render empty strings. see below... How do folks feel about changing this behavior in ``zope.pagetemplate``. Probably anything else then should be skipped. There is no logic why object() or False should get rendered as . I only whould expect that an empty string whould get rendered as . And probably we should check the HTML specification and make sure that we only render empty strings for attributes where they are allowed. see: http://www.w3.org/TR/html401/types.html#type-name ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens (-), underscores (_), colons (:), and periods (.). This means to me that an empty value for id or name doen't start with [A-Za-z] and is invalid because is must start with [A-Za-z]. or not? Regards Roger Ineichen \malthe ___ 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 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] ZPT attributes and
Hi Tres
Betreff: Re: [Zope-dev] ZPT attributes and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roger Ineichen wrote:
Hi Malthe
Betreff: [Zope-dev] ZPT attributes and
Currently, if an attribute expression evaluates to any
value that's
boolean False, it's omitted (e.g. 0, , object()). I think that's
unexpected. Instead, attributes should only be omitted when the
expression evaluates to ``None``.
I think this is better then render empty strings. see below...
How do folks feel about changing this behavior in
``zope.pagetemplate``.
Probably anything else then should be skipped. There is no logic
why object() or False should get rendered as .
Non-true values have special semantics for certain attributes
('checked', 'selected', I think).
Good point
I only whould expect that an empty string whould get
rendered as .
And probably we should check the HTML specification and
make sure that
we only render empty strings for attributes where they are allowed.
see:
http://www.w3.org/TR/html401/types.html#type-name
ID and NAME tokens must begin with a letter ([A-Za-z]) and may be
followed by any number of letters, digits ([0-9]), hyphens (-),
underscores (_), colons (:), and periods (.).
This means to me that an empty value for id or name doen't
start with
[A-Za-z] and is invalid because is must start with [A-Za-z]. or not?
- -1 on making ZPT / chameleon responsible for enforcing that
requirement:
that would be the application's job.
Hm, that's a good point too. I see what you are thinking.
My motivation is, it is valid to skip attributes with empty
values for an element in an XML document. (not sure)
If this is true, then there is no reason why a default empty
values should get rendered.
As far as I know it is valid to skip attributes for empty values
but for some attributes it is not valid to use empty values.
And the bad thing, some attributes need empty values like
you suggested with checked= etc, oh my ;-)
Regards
Roger Ineichen
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJwNuY+gerLs4ltQ4RAnvLAJ41d/7G0sHnH7GfX/CV9v+Dw6ksAQCgw+ZC
LfHPVXRoCkejJLyCvLjdvyU=
=ClnO
-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 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: 6 OK
Summary of messages to the zope-tests list. Period Tue Mar 17 12:00:00 2009 UTC to Wed Mar 18 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Tue Mar 17 21:23:50 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011289.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Tue Mar 17 21:25:55 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011290.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Tue Mar 17 21:27:55 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011291.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Tue Mar 17 21:29:55 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011292.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Tue Mar 17 21:31:55 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011293.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Tue Mar 17 21:33:57 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011294.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] XML-RPC does not work under the paster process
-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 socket._fileobject object). 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=66941r1=66940r2=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? 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 iD8DBQFJwOU0l0uAvQJUKVYRAnILAKCOSnA3YfUXilqoTD74/ukemGPkyACgil0O 1F0ZmR11vhodC33S6Wcg0z0= =JX17 -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] Windows binary egg for zope.interface 3.5.1?
Hi. Chris Withers wrote: Got zope.interface 3.5.1. Any chance someone could roll and release a Windows binary egg for this? I just uploaded binary Windows eggs for Python 2.4, 2.5 and 2.6. 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] XML-RPC does not work under the paster process
Hi Michael Betreff: Re: [Zope-dev] XML-RPC does not work under the paster process -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 socket._fileobject object). 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=66941r 1=66940r2=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? We should also add a good test case where we can see what happens. Regards Roger Ineichen 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 iD8DBQFJwOU0l0uAvQJUKVYRAnILAKCOSnA3YfUXilqoTD74/ukemGPkyACgil0O 1F0ZmR11vhodC33S6Wcg0z0= =JX17 -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 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] ZPT attributes and
On Wed, Mar 18, 2009 at 7:59 AM, Roger Ineichen d...@projekt01.ch wrote: As far as I know it is valid to skip attributes for empty values but for some attributes it is not valid to use empty values. Let's not use the term valid in this context, as it's pretty overloaded here. In the general case, there's no way to know what string values can be dropped silently, and it's wrong to assume that it can be done safely. Using a special value (None, a.k.a. nothing in templates) is the only reasonable indicator that an attribute should be dropped. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ 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.password
Christian Theune wrote: I remember that at the sprint we used to identify packages which are always good. E.g. zope.interface is a declared no-brainer to add to your dependencies. The other two that keep popping up that we *might* wanna white-list are zope.schema and zope.component. To whitelist zope.component would be quite interesting. As I recall, there was a time when all packages that depended on zope.component were required to be in the zope.app namespace. I don't object to the idea, though. We're using zope.schema and zope.component almost like language features. 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] ZPT attributes and
On Wed, Mar 18, 2009 at 07:31:36AM -0400, Tres Seaver wrote:
Roger Ineichen wrote:
Hi Malthe
Betreff: [Zope-dev] ZPT attributes and
Currently, if an attribute expression evaluates to any value
that's boolean False, it's omitted (e.g. 0, , object()).
object() is true in boolean contexts.
I
think that's unexpected. Instead, attributes should only be
omitted when the expression evaluates to ``None``.
I think this is better then render empty strings. see below...
How do folks feel about changing this behavior in
``zope.pagetemplate``.
Probably anything else then should be skipped. There is no
logic why object() or False should get rendered as .
Non-true values have special semantics for certain attributes
('checked', 'selected', I think).
True values also.
This is a feature of TAL in HTML mode and should be preserved
input type=checkbox tal:attributes=checked some_bool_expr /
Marius Gedminas
--
http://pov.lt/ -- Zope 3 consulting and development
signature.asc
Description: Digital 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 )
