"Luciano Ramalho" <[EMAIL PROTECTED]> writes:
> One of the first questions anyone needs answered when studying a new
> framework is "Where is the canonical reference for the API?".
>
> Try googling for "zope 3 api documentation"... [1]
>
> Everyone coming to a new framework expects the API documen
Stephan Richter <[EMAIL PROTECTED]> writes:
> On Sunday 08 July 2007 11:38, Christian Theune wrote:
>> Am Sonntag, den 08.07.2007, 11:31 -0400 schrieb Stephan Richter:
>> > On Sunday 08 July 2007 10:02, Christian Theune wrote:
>> > > Log message for revision 77624: More work on bug 98287:
>> > >
I recently ran into a gotcha using classes as zope.testing layers. My
layer class didn't define tearDown so it's base class tearDown method
was called when my layer was supposed to be torn down.
It seems like a minor pain to me to have to define tearDown, testSetUp,
and testTearDown in a layer wh
Martijn Faassen <[EMAIL PROTECTED]> writes:
> I think one of the main limitations of the current catalog (and
> hurry.query) is efficient support for sorting and batching the query
> results. The Zope 3 catalog returns all matching results, which can
> then be sorted and batched. This will stop be
Christian Zagrodnick <[EMAIL PROTECTED]> writes:
> On 2007-03-07 17:54:35 +0100, Ross Patterson <[EMAIL PROTECTED]> said:
>
>> Christian Zagrodnick <[EMAIL PROTECTED]> writes:
>>
>>> Hoi
>>>
>>> the Zope 3.3 branch tests f
Christian Zagrodnick <[EMAIL PROTECTED]> writes:
> Hoi
>
> the Zope 3.3 branch tests fail here:
>
>
> Error in test test_persistentDeclarations
> (zope.app.interface.tests.test_interface.PersistentInterfaceTest)
> Traceback (most recent call last):
> File "/sw/lib/python2.4/unittest.py", line 260
It would be very useful to establish dependencies between subscriber
registrations which would be used to determine the order in which the
subscriber factories or handlers are called and resutls returned.
We'll need the following in our examples::
>>> foo = []
>>> def handleFoo(context):
In the design I've been doing with the CA I keep running into
a... "design pattern" (for lack of a better term) where I want to
retrieve persistent objects using exactly the kind of registry lookup
that the CA provides. In the past I would have used a catalog to
perform such lookups with sufficien
In the design I've been doing with the CA I keep running into
a... "design pattern" (for lack of a better term) where I want to
retrieve persistent objects using exactly the kind of registry lookup
that the CA provides. In the past I would have used a catalog to
perform such lookups with sufficien
Ross Patterson <[EMAIL PROTECTED]> writes:
> Ross Patterson <[EMAIL PROTECTED]> writes:
>
>> zope.app.interface.PersistentInterface gets used properly for
>> persistent modules containing classes that subclass
>> zope.interface.Interface when those modul
Ross Patterson <[EMAIL PROTECTED]> writes:
> zope.app.interface.PersistentInterface gets used properly for
> persistent modules containing classes that subclass
> zope.interface.Interface when those modules are are managed and
> registered through managers and registries from
zope.app.interface.PersistentInterface gets used properly for
persistent modules containing classes that subclass
zope.interface.Interface when those modules are are managed and
registered through managers and registries from zodbcode. However,
similar persistent modules are broken when managed an
I've submitted some new tests and a fix for
zope.app.interface.PersistentInterfaceClass in:
http://www.zope.org/Collectors/Zope3-dev/747
I have commit priveleges to the svn repo, but I'd love to get some
review before commiting. baijum from #zope3-dev suggested I post
here. Below is a copy of t
13 matches
Mail list logo
