Philipp von Weitershausen wrote:
I think that after eggifying Zope 3 in 3.4 and introducing some features
in Zope 2.11 that makes us not depend on Zope2isms like Acquisition
(while they'd still be available for those who want to use them), we
should invest into the Zope 5 vision: explode Zope
Chris Withers wrote:
Philipp von Weitershausen wrote:
I think that after eggifying Zope 3 in 3.4 and introducing some
features in Zope 2.11 that makes us not depend on Zope2isms like
Acquisition (while they'd still be available for those who want to use
them), we should invest into the Zope 5
Simon Hang wrote:
How about below changes?
There aren't many of us who know the zope.server code that well,
unfortunately. This is one of the reasons we want to get out of the
server business.
That said, it would *much* easier to understand what you're trying to do
if you provided
Thanks Philipp, here is the unified diffs.
--- httptask.py.orig Fri Jan 06 02:15:48 2006+++ httptask.py Thu Sep 21 17:31:17 2006@@ -126,6 +126,15 @@ else: close_it = 1 elif version == '1.1':+ #modified by Simon
+ thisflag = False+ for each in self.accumulated_headers:+ if each.lower() ==
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
Chris Withers wrote:
Philipp von Weitershausen wrote:
AFAIK, getUtilitiesFor is not supposed to order these in any way.
While the returned iterator does find them in a reproduceable order
due to the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
Tres Seaver wrote:
How should I do things such that they can do that?
I'm just wondering whether you really need the disabling feature.
I've wanted it.
Okay :).
My major beef with the way we are *using* ZCML
On Sep 21, 2006, at 9:15 AM, Tres Seaver wrote:
I've wanted it. My major beef with the way we are *using* ZCML now is
that we expect package authors to provide policy-laden
configuration for
their packages (sensible defaults) but provide no means for the
admin
to reuse that configuration
On Thursday 21 September 2006 09:15, Tres Seaver wrote:
I've wanted it. My major beef with the way we are *using* ZCML now is
that we expect package authors to provide policy-laden configuration for
their packages (sensible defaults) but provide no means for the admin
to reuse that
On Sep 21, 2006, at 11:31 AM, Stephan Richter wrote:
On Thursday 21 September 2006 09:15, Tres Seaver wrote:
I've wanted it. My major beef with the way we are *using* ZCML
now is
that we expect package authors to provide policy-laden
configuration for
their packages (sensible defaults)
On Thursday 21 September 2006 11:52, Jim Fulton wrote:
I have a feeling that xpath is overkill.
I still think that for ZCML XPath is a good approach. People are familiar with
it and our designers could just use it presumably.
It alsoi won't work for actions defined in Python.
I think this is
Hi Adam
Hi Roger,
Tuesday, September 19, 2006, 12:08:20 PM, you wrote:
Update - Final is guarded by review_result == 'accepted'
Update - Issue is guarded by transitionName == 'update_issue'
Update - Review is guarded by transitionName == 'update_review'
RI Is this (Update - Final)
Philipp,
Sorry for being lazy, and thanks for the tips. Here is my update version.
--- httptask.py.orig Fri Jan 06 02:15:48 2006+++ httptask.py Fri Sep 22 09:13:48 2006@@ -126,6 +126,11 @@ else: close_it = 1 elif version == '1.1':+ #modified by Simon
+ if 'connection: close' in (header.lower() for
12 matches
Mail list logo
