Hi,
Am Mittwoch, den 30.11.2005, 15:52 +0100 schrieb Philipp von
Weitershausen:
> Andreas Jung wrote:
> > Let's say it this way: it's safer than with Zope 2.8.3 but it is still not
> > supported :-)
>
> >From where I'm standing, with Zope 2.8.4 it's as safe as with Zope 2.9
> (which actually *req
hello all,
i'm running into a wierd zope/plone error. it is the same error as the
"RESPONSE eaten" post at:
http://mail.zope.org/pipermail/zope-dev/2003-November/020952.html
i asked the poster for help since there were no followups, but unfortunately he
would not help me and told me he was not
+1
On Dec 1, 2005, at 1:49 PM, Florent Guillaume wrote:
I've improved the logging of ConflictError in Zope 2.9 and trunk.
http://svn.zope.org/?rev=40454&view=rev
Now you'll get two things:
- logs at level BLATHER for each conflict, but it may be retried
- log at level ERROR when the conflict
On Thu, Dec 01, 2005 at 02:03:51PM -0500, Tres Seaver wrote:
> > Do people want this also for 2.8? Note that it changes the log format,
> > so may break third party tools that parse logs.
>
> +1.
+1 from me too, the added information is worth potential tool breakage
IMO. Just put an obvious note
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Florent Guillaume wrote:
> I've improved the logging of ConflictError in Zope 2.9 and trunk.
>
> http://svn.zope.org/?rev=40454&view=rev
>
> Now you'll get two things:
> - logs at level BLATHER for each conflict, but it may be retried
> - log at leve
I've improved the logging of ConflictError in Zope 2.9 and trunk.
http://svn.zope.org/?rev=40454&view=rev
Now you'll get two things:
- logs at level BLATHER for each conflict, but it may be retried
- log at level ERROR when the conflict can't be retried anymore and is
returned to the browser as
I'm happy to announce that I've finally managed to document the
internationalization (i18n) features that Five has brought to the Zope 2
world since version 1.1:
http://worldcookery.com/files/fivei18n
This short tutorial compares current Zope-2-based solutions to the i18n
problem with the Zope 3
On 12/1/05, Chris Withers <[EMAIL PROTECTED]> wrote:
> In this case, I think zopeschema.xml should be documentation enough,
> especially as any product author wanting to use this feature is going to
> have to write a component.xml at least ;-)
Actually, a product author isn't required to write a c
On Nov 30, 2005, at 2:18 PM, Chris Withers wrote:
Gary Poster wrote:
Zope 2 depends on Zope 3, via Five. Zope 3 does not depend on
Zope 2.
A very good point, but one which makes me feel that Zope 2
shouldn't be merged in with Zope 3 ;-)
Actually, yes, all of my points were made to that
Summary of messages to the zope-tests list.
Period Wed Nov 30 12:01:02 2005 UTC to Thu Dec 1 12:01:02 2005 UTC.
There were 8 messages: 8 from Zope Unit Tests.
Tests passed OK
---
Subject: OK : Zope-2_6-branch Python-2.1.3 : Linux
From: Zope Unit Tests
Date: Wed Nov 30 22:15:17 EST 2
Fred Drake wrote:
I don't know that there's any real documentation for this. Feel free
to add some.
In this case, I think zopeschema.xml should be documentation enough,
especially as any product author wanting to use this feature is going to
have to write a component.xml at least ;-)
chee
Andreas Jung wrote:
For people it might be more comfortable to have a on-the-fly migration
somehow under the hood...however this leads to ugly migration code in
the sources (Zope is full of such scary code). Personally I prefer a
dedicated
migration step.
+ lotz
Chris
--
Simplistix - Con
Martijn Jacobs wrote:
catalog. The estimation about the amount of objects, with only the leave
nodes as 'SimpleItem' objects will be 30.000.
30,000 is nothing.
The production catalog on one of my projects has 220,000 objects in it,
and I still wouldn't class that as "huge".
cheers,
Chris
Evan Simpson wrote:
It was asserted, last time this came up, that this is compliant with the
ISO8601 spec, but my own research shows this to be false. If someone
can point me to a truly authoritative source that supports the current
behavior, I would appreciate it, but that would not change the
I'm probably missing something, hence my asking.
If GenericSetup is generic, why is it in the CMF repository?
Sure, bundle it with CMF, like BTreeFolder2 used to be, but why not also
release it seperately and have it in its own repo?
cheers,
Chris
Yvo Schubbe wrote:
Log message for revisio
15 matches
Mail list logo
