Am 11.08.2009, 20:06 Uhr, schrieb yuppie :
> I propose to split up CMFCatalogAware in CatalogAware, WorkflowAware and
> OpaqueItemManager mixins. All the interfaces provided by these base
> classes should be optional for CMF content. PortalFolderBase e.g. is not
> catalog or workflow aware, so it
Hi!
Hanno Schlichting wrote:
> I don't know how such a feature removal or deprecation would be
> handled on the CMF level.
AFAICS IWorkflowAware and IOpaqueItemManager methods (as defined in CMF
2.2) were added to CMFCatalogAware because at that time events were not
available and it was easier
Charlie Clark a écrit :
> Am 10.08.2009, 08:45 Uhr, schrieb toutpt :
>
>
>> Thank you Charlie for this answer and this "Read The Fucking
>> Interfaces" .
>>
>
> Well, although it's a truism that if you read the code you'll find the
> answer, it does also take a while to get used to read
Am 10.08.2009, 08:45 Uhr, schrieb toutpt :
> Thank you Charlie for this answer and this "Read The Fucking
> Interfaces" .
Well, although it's a truism that if you read the code you'll find the
answer, it does also take a while to get used to reading the code of any
particular project. But a
Am 10.08.2009, 09:30 Uhr, schrieb Jens Vagelpohl :
> No. See http://www.unicom.com/pw/reply-to-harmful.html for some
> information why it's not a god idea.
While I understand the technical problems, I don't think reply to all is
actually much better and we do occasionally get posts to the list,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 9, 2009, at 21:03 , Charlie Clark wrote:
> From my previous answer to this which I forgot to send to the list
> as well
> - can we change the list settings so that answers go to it by default?
No. See http://www.unicom.com/pw/reply-to-harmf
Charlie Clark a écrit :
> Am 09.08.2009, 04:48 Uhr, schrieb Martin Aspeli :
>
>
self_base = aq_base(self)
for name in self_base.__dict__.keys()
obj = getattr(self, name)
if ICallableOpaqueItem.providedBy(obj):
items.append((obj.getId(), obj))
>>
Am 09.08.2009, 04:48 Uhr, schrieb Martin Aspeli :
>>> self_base = aq_base(self)
>>> for name in self_base.__dict__.keys()
>>>obj = getattr(self, name)
>>>if ICallableOpaqueItem.providedBy(obj):
>>> items.append((obj.getId(), obj))
> That's just *nuts*!
From my previous answer to thi
Wichert Akkerman wrote:
> On 2009-8-8 11:53, Hanno Schlichting wrote:
>> On Sat, Aug 8, 2009 at 12:14 AM, Charlie Clark
>> wrote:
>>> Is the patch for Plone or CMF?
>> It's for Plone, I guess. The "problem is solved" in Plone 4.0 itself
>> (via monkey-patching CMF).
>>
>>> If it's for CMF then yo
On 2009-8-8 11:53, Hanno Schlichting wrote:
> On Sat, Aug 8, 2009 at 12:14 AM, Charlie Clark wrote:
>> Is the patch for Plone or CMF?
>
> It's for Plone, I guess. The "problem is solved" in Plone 4.0 itself
> (via monkey-patching CMF).
>
>> If it's for CMF then you should consider simply submittin
On Sat, Aug 8, 2009 at 12:14 AM, Charlie Clark wrote:
> Is the patch for Plone or CMF?
It's for Plone, I guess. The "problem is solved" in Plone 4.0 itself
(via monkey-patching CMF).
> If it's for CMF then you should consider simply submitting a patch or
> opening a branch. But before you write a
Am 07.08.2009, 22:17 Uhr, schrieb toutpt :
> experimental.opaquespeedup is good but not enough for me. The load tests
> results are not enough, I want to be more 'aggressive' and
> experimental. For me this package is backward compatible and do a
> catalog query instead of parsing all attributes.
On Fri, Aug 7, 2009 at 9:17 PM, toutpt wrote:
> experimental.opaquespeedup is good but not enough for me. The load tests
> results are not enough, I want to be more 'aggressive' and
> experimental. For me this package is backward compatible and do a
> catalog query instead of parsing all attribute
David Glick a écrit :
> On Aug 3, 2009, at 1:46 PM, toutpt wrote:
>
>> Hi,
>>
>> I m currently profiling the code of Plone to find performance issue and
>> fix them (i m sure there are a lot).
>>
>> There are things I don't understand very well, so sorry if I m wrong.
>>
>> The code of CMFCatalogAw
Hanno Schlichting a écrit :
> On Mon, Aug 3, 2009 at 11:09 PM, toutpt wrote:
>
>> I don't really understand why all these improvements are not merged
>> inside plone3.X and CMF and are marked up as 'experimental'.
>>
>
> The opaque items issue at hand is not a simple and clear "bug fix". On
On Mon, Aug 3, 2009 at 11:09 PM, toutpt wrote:
> I don't really understand why all these improvements are not merged
> inside plone3.X and CMF and are marked up as 'experimental'.
The opaque items issue at hand is not a simple and clear "bug fix". On
the Plone level we have decided to no longer su
Hanno Schlichting a écrit :
> On Mon, Aug 3, 2009 at 10:46 PM, toutpt wrote:
>
>> I m currently profiling the code of Plone to find performance issue and
>> fix them (i m sure there are a lot).
>>
>
> Did you try to install all the experimental.* (opaquespeedup,
> contentcreation, catalogqu
On Mon, Aug 3, 2009 at 10:46 PM, toutpt wrote:
> I m currently profiling the code of Plone to find performance issue and
> fix them (i m sure there are a lot).
Did you try to install all the experimental.* (opaquespeedup,
contentcreation, catalogqueryplan) packages that have been done over
the las
On Aug 3, 2009, at 1:46 PM, toutpt wrote:
> Hi,
>
> I m currently profiling the code of Plone to find performance issue
> and
> fix them (i m sure there are a lot).
>
> There are things I don't understand very well, so sorry if I m wrong.
>
> The code of CMFCatalogAware.opaqueItems parse every a
Hi,
I m currently profiling the code of Plone to find performance issue and
fix them (i m sure there are a lot).
There are things I don't understand very well, so sorry if I m wrong.
The code of CMFCatalogAware.opaqueItems parse every attributes of
plonesite and evaluate this for each attribute:
20 matches
Mail list logo
