On Tuesday 15 November 2005 10:43 am, Rob Miller wrote:
> Florent Guillaume wrote:
> > Rob Miller wrote:
> >> CatalogMultiplex is a subclass of CMFCatalogAware which overrides the
> >> (un/re)indexObject methods to perform operations in multiple catalogs,
> >> if necessary. your patch changes CMFC
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jens Vagelpohl wrote:
>
> On 15 Nov 2005, at 14:24, yuppie wrote:
>
>> The notes should be logged *and* used for reporting in the ZMI.
>>
>>
>> Implementation:
>>
>> I'm no logging expert, so I might well be missing something. The
>> state of the ar
On 15 Nov 2005, at 14:24, yuppie wrote:
The notes should be logged *and* used for reporting in the ZMI.
Implementation:
I'm no logging expert, so I might well be missing something. The
state of the art seems to be using the Python logging package (PEP
282). Is it possible to use that fram
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> Tres, if you're experiencing the test failures with the Zope 2 trunk but
> not with Zope 2.8 branch, it might be because your stub request is
> lacking the 'default' layer. In Zope 3.1+, layers and skins are
> interf
Hi!
GenericSetup is quite silent. The return values of the setup handlers
and import context notes are ignored. The only feedback is a small
manage_tabs_message.
Goals:
Setup handlers should give detailed feedback. Each note should include a
logging level and a setup handler ID.
The mos
Florent Guillaume wrote:
Rob Miller wrote:
CatalogMultiplex is a subclass of CMFCatalogAware which overrides the
(un/re)indexObject methods to perform operations in multiple catalogs,
if necessary. your patch changes CMFCatalogAware's manage_before* and
manage_after* methods so that it dele
Raphael Ritz wrote:
<--SNIP-->
Now my questions: is the outline given above correct?
At least w.r.t. the big picute?
in a general sense, i think yes.
If so: Having this in place shouldn't this allow for easy
extension to multiple catalogs (like the uid or reference
catalogs from AT) by sim
Jens Vagelpohl wrote:
On 14 Nov 2005, at 22:28, Rob Miller wrote:
okay, i've created a CMF-1.6 branch that has branched everything from
CMF-1.5 with the exception of CMFSetup and GenericSetup, which are
svn:externals from the CMF trunk.
note that i've haven't actually started any backport
Hi Florent!
Thanks for the feedback.
Florent Guillaume wrote:
yuppie wrote:
I can see use cases like that, but I'd prefer a more decentralized
solution. Using the setup tool for tasks like that makes it too
complex and if I want to modify a single tool I don't want to switch
to the setup to
Hi Tres!
Tres Seaver wrote:
The setup handlers for adapter based import / export are just
boilerplate. I'd like to move the complete responsibility for setting up
tools to importToolset / exportToolset.
- -1, if I understand correctly, because it assumes too much. I *want* to
make each tool'
Raphael Ritz wrote:
> I know I'm getting myself in danger now as I know too little
> yet about Zope 3 and I have no practical experience whatsoever
> using the new event system or not even the slightes idea to
> what extend the work for CMF-2.0 already achieved progress here.
>
> So, before I star
Jens Vagelpohl wrote:
On 15 Nov 2005, at 02:56, Rob Miller wrote:
to be fair, AT's (un)indexing code is a mess... i tried to change the
BaseFolderMixin manage_(after|before)* methods so they explicitly
call the PortalFolder implementations and was still ending up w/
subobject orphans left
On 15 Nov 2005, at 05:07, yuppie wrote:
TODO:
- update deprecation warnings on the 1.5 and 1.6 branch, replacing
"will be removed in CMF 1.6" by "will be removed in CMF 2.0"
check
TODO:
- update deprecation warnings on the 1.5 and 1.6 branch, replacing
"will be removed in CMF 1.7" by
On 15 Nov 2005, at 02:56, Rob Miller wrote:
to be fair, AT's (un)indexing code is a mess... i tried to change
the BaseFolderMixin manage_(after|before)* methods so they
explicitly call the PortalFolder implementations and was still
ending up w/ subobject orphans left in the catalog after co
On 14 Nov 2005, at 22:28, Rob Miller wrote:
okay, i've created a CMF-1.6 branch that has branched everything
from CMF-1.5 with the exception of CMFSetup and GenericSetup, which
are svn:externals from the CMF trunk.
note that i've haven't actually started any backporting yet, and as
such t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
yuppie wrote:
> Hi!
>
>
> The setup handlers for adapter based import / export are just
> boilerplate. I'd like to move the complete responsibility for setting up
> tools to importToolset / exportToolset.
- -1, if I understand correctly, because it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
yuppie wrote:
> The new plans for a CMF 1.6 release make it necessary to adjust the
> migration roadmap.
First, we need to ensure that the 1.6 release will actually happen. I
don't plan to spend any cycles on it beyond monitoring list traffic.
> 1.
Rob Miller wrote:
[..]
you're more than welcome to either pitch this to plone-devel or to grab
it by the horns and start working on it yourself. :-).
Hi Rob and all other CMF developers,
I know I'm getting myself in danger now as I know too little
yet about Zope 3 and I have no practical
Paul Winkler wrote:
On Thu, Nov 10, 2005 at 05:52:05PM +0100, Florent Guillaume wrote:
Could folks having old CMF branches clean them up ?
See http://svn.zope.org/CMF/branches/
This seems to concern: ajung, andrew, chrism, chrisw, gregweb,
jshell, mj, regebro, shane, sidnei, slinkp, tseaver,
yuppie wrote:
- import/export of selected tools from a bigger profile: don't think
we really need that
Right now each tool has its own import step and export step. The
'Import'
and 'Export' tab of the setup tool allow to select single steps and run
them independently. If tools become part of
Rob Miller wrote:
Florent Guillaume wrote:
To repost an earlier mail:
The patch I propose to include is:
http://mail.zope.org/pipermail/cmf-checkins/2005-November/007137.html
Could some Plone folks please test that switching to
CMF/branches/efge-1.5-five-compatible instead of CMF/branches/1.
Hi!
The new plans for a CMF 1.6 release make it necessary to adjust the
migration roadmap.
1.) CMF 1.6 will ship with all the CMF BBB code that is in CMF 1.5.
TODO:
- update deprecation warnings on the 1.5 and 1.6 branch, replacing "will
be removed in CMF 1.6" by "will be removed in CMF 2
Raphael Ritz wrote:
Rob Miller wrote:
[..]
to be fair, AT's (un)indexing code is a mess... i tried to change the
BaseFolderMixin manage_(after|before)* methods so they explicitly call
the PortalFolder implementations and was still ending up w/ subobject
orphans left in the catalog after conta
Rob Miller wrote:
[..]
to be fair, AT's (un)indexing code is a mess... i tried to change the
BaseFolderMixin manage_(after|before)* methods so they explicitly call
the PortalFolder implementations and was still ending up w/ subobject
orphans left in the catalog after container deletions. ideal
The following supporters have open issues assigned to them in this collector
(http://www.zope.org/Collectors/CMF).
Assigned and Open
efge
- "CMFSetup: provide non-ascii im- and exports",
[Accepted] http://www.zope.org/Collectors/CMF/292
- "CMFSetup doesn't correctly detect DCWo
25 matches
Mail list logo
