Previously yuppie wrote:
> But the way lookups are delegated to other site managers seems to be
> highly optimized and making use of internal apis of five.lsm. So it
> might not be possible to fix this in five.lsm, in which case Hanno's
> proposal would provide a solution.
That is exactly the c
Hi!
Alec Mitchell wrote:
On 4/3/07, yuppie wrote:
AFAICS all CMF tool interfaces are valid utility interfaces. The fact
they are currently implemented as content space tools is just an
implementation detail. Using the utility I don't care how it is
implemented. Why should I?
All issues repor
On 4/3/07, yuppie <[EMAIL PROTECTED]> wrote:
Hi!
Alec Mitchell wrote:
> On 4/1/07, yuppie wrote:
>> Philipp von Weitershausen wrote:
>> > You're suggesting to introduce yet another package that's destined
>> to go
>> > a way at some point, while the same functionality is already available,
>>
Hi!
Alec Mitchell wrote:
On 4/1/07, yuppie wrote:
Philipp von Weitershausen wrote:
> You're suggesting to introduce yet another package that's destined
to go
> a way at some point, while the same functionality is already available,
> it only needs to be un-deprecated...
I don't agree. CMF
On 4/1/07, yuppie <[EMAIL PROTECTED]> wrote:
Hi!
Philipp von Weitershausen wrote:
> Hanno Schlichting wrote:
>> I would say that all of Acquisition is dark implicit magic and something
>> I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2
>> I also expect the need to make
Hi!
Philipp von Weitershausen wrote:
Hanno Schlichting wrote:
I would say that all of Acquisition is dark implicit magic and something
I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2
I also expect the need to make the Zope 3 code Acquisition aware. One
prime example ar
Tres Seaver wrote:
I'm not sure what impact that would have for the already-converted code
which used to use the API. I can see value both in leaving it
converted, as showing the Zope3-ish way, as well as in reverting some or
all of it. For instance, perhaps we should consider reverting just
th
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
Hanno Schlichting wrote:
I would say that all of Acquisition is dark implicit magic and something
I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2
I also expect the need to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> Hanno Schlichting wrote:
>> I would say that all of Acquisition is dark implicit magic and something
>> I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2
>> I also expect the need to make the Zo
Hanno Schlichting wrote:
I would say that all of Acquisition is dark implicit magic and something
I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2
I also expect the need to make the Zope 3 code Acquisition aware. One
prime example are browser views, which I need to mix in
Hi,
I'll just offer one alternative solution for disussion, which could
avoid reverting all the changes we made.
Kapil Thangavelu wrote:
> We believe that these recent changes have introduced implicit magic into
> a standard Zope3 api to fit Zope2 acquisition. There should be an
> explicit separa
Martin Aspeli wrote:
We believe that these recent changes have introduced implicit magic
into a standard Zope3 api to fit Zope2 acquisition. There should be
an explicit separate api if we want acquisition wrapped context-aware
utilities. As an example of a symptom caused by the implicit
imp
Kapil Thangavelu wrote:
A few of us (Alec Mitchell, Godefroid Chapelle, Balazs Ree, Rocky Burt,
Daniel Nouri, Rob Miller, Vincenzo Di Somma, and myself) have been
discussing this in depth at the Sorrento Sprint. We've reached consensus
on how we hope to resolve the issues arising from the re
13 matches
Mail list logo