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:
Hi!
Andreas Jung wrote:
> I am currently migrating our CMS from CMF 1.X to CMF 2.1.
>
> The following error is raised because the original content classes
> are not derived from CMFCatalogAware.
[...]
> # Module Products.CMFCore.CMFCatalogAware, line 280, in dispatchToOpaqueItems
> # Module Prod
On 29.06.09 08:43, David Glick wrote:
>
>
>
> From
> http://dev.plone.org/old/plone/browser/plone.app.discussion/trunk/plone/app/discussion/comment.py#L83
> and
> following lines it would appear you can do the latter.
Thanks - adding the related hooks returning () solves the problem. The
strange
On Jun 28, 2009, at 11:40 PM, Andreas Jung wrote:
>
> Hi there,
>
> I am currently migrating our CMS from CMF 1.X to CMF 2.1.
>
> The following error is raised because the original content classes
> are not derived from CMFCatalogAware.
>
> # Module Products.HaufeCMS.DataLevel.Folder, line 170, in
Hi there,
I am currently migrating our CMS from CMF 1.X to CMF 2.1.
The following error is raised because the original content classes
are not derived from CMFCatalogAware.
# Module Products.HaufeCMS.DataLevel.Folder, line 170, in addDocument
# Module Products.BTreeFolder2.BTreeFolder2, line 4
Hi there,
others and I have been pushing the usage of local components in Five. As
a result it looks like the CMF 2.1 will use the CA to look up its tools.
Woohoo! (Kudos to Jens and all the others!)
There's one problem with all this which I admit I have failed to
communicate better (certain
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6 Jan 2007, at 12:57, Andreas Jung wrote:
On 5 Jan 2007, at 20:51, Andreas Jung wrote:
I finished my work (including some test).
Any objections merging the changes back to the trunk?
If the tests pass, no. At least from me ;)
I merged the
--On 5. Januar 2007 21:22:24 +0100 Jens Vagelpohl <[EMAIL PROTECTED]>
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5 Jan 2007, at 20:51, Andreas Jung wrote:
I finished my work (including some test).
Any objections merging the changes back to the trunk?
If the tests pass, no.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5 Jan 2007, at 20:51, Andreas Jung wrote:
I finished my work (including some test).
Any objections merging the changes back to the trunk?
If the tests pass, no. At least from me ;)
jens
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On 20. Dezember 2006 19:34:22 +0100 Andreas Jung
<[EMAIL PROTECTED]>
wrote:
>
>>
>> If you look at the current FSPageTemplate code, there was already an
>> attempt to find and transfer enoding information with the response by way
>> of adding
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On 21. Dezember 2006 20:14:59 +0100 Dieter Maurer <[EMAIL PROTECTED]>
wrote:
> Andreas Jung wrote at 2006-12-20 19:34 +0100:
>> ...
>> Right. The pt_render() should return unicode only. Let's assume
>> FSPageTemplates would use unicode internal
Andreas Jung wrote at 2006-12-20 19:34 +0100:
> ...
>Right. The pt_render() should return unicode only. Let's assume
>FSPageTemplates would use unicode internally and a customized copy (an
>instance of ZopePageTemplate) wouldn't then we would definitely run
>into UnicodeDecode errors. That's why
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On 19. Dezember 2006 09:58:37 +0100 Jens Vagelpohl <[EMAIL PROTECTED]>
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> On 19 Dec 2006, at 09:45, Andreas Jung wrote:
>> Jup. However I am not completely sure about all impacts :-)
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19 Dec 2006, at 09:45, Andreas Jung wrote:
Jup. However I am not completely sure about all impacts :-)
If I understand the description correctly, the real change is in how
the "surrogate" page template object representing the filesystem page
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On 19. Dezember 2006 09:34:13 +0100 Jens Vagelpohl <[EMAIL PROTECTED]>
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> On 18 Dec 2006, at 13:52, Andreas Jung wrote:
>> What has to be done:
>>
>> - FSPageTemplate._readFile() shou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18 Dec 2006, at 13:52, Andreas Jung wrote:
What has to be done:
- FSPageTemplate._readFile() should convert 'data' to unicode and
pass it to pt_edit() instead of using write()
- a filesystem-based PT should be able to specify its encoding
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
You might have noticed that I have changed the ZopeTemplateFile
implementation to work with unicode as internal representation. I think it
would make sense for FSPageTemplate instance to use unicode as well -
especially when ZPTs and FSPageTemplate
The CMF developer community is hereby announcing the release of CMF
version 2.1.0-alpha.
What is the CMF?
The Zope Content Management Framework provides a set of services and
content objects useful for building highly dynamic, content-oriented
portal sites. The CMF provides the foundation
Previously Jens Vagelpohl wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> If anyone has any objections to cutting CMF 2.1 alpha this weekend
> please speak up. Silence is consent. Wichert would like one to
> coincide with Plone 3.0 alpha, also due in the next few days (I think).
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If anyone has any objections to cutting CMF 2.1 alpha this weekend
please speak up. Silence is consent. Wichert would like one to
coincide with Plone 3.0 alpha, also due in the next few days (I think).
jens
-BEGIN PGP SIGNATURE-
Version
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9 Sep 2006, at 15:57, Wichert Akkerman wrote:
Plone 3.0 is slowly making progress and I would like to make a first
alpha release in 3-4 weeks. That release will be quite rough, but will
showcase the new technology. A big part of that will hopeful
Hi guys,
Plone 3.0 is slowly making progress and I would like to make a first
alpha release in 3-4 weeks. That release will be quite rough, but will
showcase the new technology. A big part of that will hopefully be the
CMF 2.1 support that Hanno has been working on. That means that it would
be ver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I just looked over the CMF roadmap document since we're supposed to
have a 2.1 beta in a matter of weeks and now I'm wondering if this is
possible/desirable right now:
http://www.zope.org/Products/CMF/docs/roadmap
First of all, some of
42 matches
Mail list logo
