Am 06.09.2012, 11:56 Uhr, schrieb Patrick Gerken
:
Wait, what?
Whenever I look into structure, there is only basic information, not
even the workflow states of the objects get exported.
What am I doing wrong?
I was thinking something similar: can you really use Generic Setup to
migrate obj
On Thu, Sep 6, 2012 at 7:59 AM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 09/06/2012 01:37 AM, Lennart Regebro wrote:
>> On Wed, Sep 5, 2012 at 5:01 PM, Tres Seaver
>> wrote:
And if we don't want to support more than one site the ZODB,
there should be a
Hi Laurence!
Laurence Rowe wrote:
On 5 September 2012 19:21, Laurence Rowe wrote:
Instead of removing the RequestContainer, it could be replaced with a
zope.globalrequest aware RequestContainer. That might be cleaner than
rewrapping in individual utilities, and would work with Zope 2.13.
I
On Thu, Sep 6, 2012 at 7:59 AM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 09/06/2012 01:37 AM, Lennart Regebro wrote:
>> On Wed, Sep 5, 2012 at 5:01 PM, Tres Seaver
>> wrote:
And if we don't want to support more than one site the ZODB,
there should be a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/06/2012 01:37 AM, Lennart Regebro wrote:
> On Wed, Sep 5, 2012 at 5:01 PM, Tres Seaver
> wrote:
>>> And if we don't want to support more than one site the ZODB,
>>> there should be a warning of you try to do it, btw.
>>
>> I've got no problem w
On Wed, Sep 5, 2012 at 5:01 PM, Tres Seaver wrote:
>> And if we don't want to support more than one site the ZODB, there
>> should be a warning of you try to do it, btw.
>
> I've got no problem with more than one CMF site in a single Zope
> instance; I just don't want to promote .zexp as the way
On 5 September 2012 19:21, Laurence Rowe wrote:
> On 5 September 2012 17:15, yuppie wrote:
>> Laurence Rowe wrote:
>>>
>>> Maybe I'm missing something, but the various methods of IURLTool rely
>>> on portal.getPhysicalPath() returning the correct result. Take
>>> getRelativeContentPath for exampl
On 5 September 2012 17:15, yuppie wrote:
> Laurence Rowe wrote:
>>
>> Maybe I'm missing something, but the various methods of IURLTool rely
>> on portal.getPhysicalPath() returning the correct result. Take
>> getRelativeContentPath for example:
>>
>> portal is at /folder/portal
>> content is at /f
Laurence Rowe wrote:
Maybe I'm missing something, but the various methods of IURLTool rely
on portal.getPhysicalPath() returning the correct result. Take
getRelativeContentPath for example:
portal is at /folder/portal
content is at /folder/portal/content
getUtility(IURLTool).getPortalObject().ge
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/05/2012 10:00 AM, Lennart Regebro wrote:
> On Wed, Sep 5, 2012 at 3:42 PM, Charlie Clark
>
> wrote:
>> No, one site per Data.fs is what we should support. This has more or
>> less been the explicit aim of Zope > 2.8
>
> So you want to tell eve
On 5 September 2012 16:26, yuppie wrote:
> Hi!
>
>
>
> Laurence Rowe wrote:
>>
>> Precisely because CMF 2.3 targets Zope 2.13 - persistent local
>> utilities returned by getUtility lack any sort of acquisition context
>> in Zope2, so the result of getUtility(ISiteRoot) will return
>> aq_base(porta
Hi!
Laurence Rowe wrote:
Precisely because CMF 2.3 targets Zope 2.13 - persistent local
utilities returned by getUtility lack any sort of acquisition context
in Zope2, so the result of getUtility(ISiteRoot) will return
aq_base(portal), which is unlikely to be useful. getSite() instead
returns t
Am 05.09.2012, 16:00 Uhr, schrieb Lennart Regebro :
So you want to tell everyone that either has not received that
message, or used Plone since before 2.5, "That yeah, I know you can do
that, but we were just messing with you so now you are fucked".
I think you are taking my words entirely out
On Wed, Sep 5, 2012 at 3:42 PM, Charlie Clark
wrote:
> No, one site per Data.fs is what we should support. This has more or less
> been the explicit aim of Zope > 2.8
So you want to tell everyone that either has not received that
message, or used Plone since before 2.5, "That yeah, I know you can
On 5 September 2012 15:36, yuppie wrote:
> Hi!
>
>
> Laurence Rowe wrote:
>
>> On 5 September 2012 13:26, yuppie
>> wrote:
>>>
>>> I don't think relying on getSite() is a good idea. As you mention it
>>> doesn't
>>> always return the portal object. And the fact it is stored with the
>>> request
>
Am 05.09.2012, 15:05 Uhr, schrieb Lennart Regebro :
I think it is. We have to have some way to move a Plone site from one
ZODB to another.
No, one site per Data.fs is what we should support. This has more or less
been the explicit aim of Zope > 2.8
I find export by zexp generally works on a
Am 05.09.2012, 15:36 Uhr, schrieb yuppie :
- CMF 2.3 targets Zope 2.13 as primary platform. So we can't rely on
Zope 4 features.
Agreed, but we should be looking to getting 2.3 out of the door anyway.
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Kronen
Hi!
Laurence Rowe wrote:
On 5 September 2012 13:26, yuppie
wrote:
I don't think relying on getSite() is a good idea. As you mention it doesn't
always return the portal object. And the fact it is stored with the request
in its context is just an accidental side effect. What would be the
advan
Hi!
Charlie Clark wrote:
Am 05.09.2012, 11:48 Uhr, schrieb yuppie :
getToolByName is no option because it is part of the machinery that
should become obsolete.
Not sure that is should actually ever become obsolete. Much as I am in
favour of the interface-based lookup, these tools are an ess
On Wed, Sep 5, 2012 at 1:40 PM, Charlie Clark
wrote:
> Am 05.09.2012, 11:48 Uhr, schrieb yuppie :
>
>> I use a single Zope instance for several small CMF sites and I use .zexp
>> export and import for moving CMF sites from one Zope instance to an other.
>> Works fine for me. Even with Plone sites.
On 5 September 2012 13:26, yuppie wrote:
> Hi Laurence!
>
>
> Laurence Rowe wrote:
>
>> On 5 September 2012 11:48, yuppie
>> wrote:
>>
>> 2.) Site root lookup: =
>>
>> In several tools we still assume aq_parent(aq_inner(self)) is the
>> portal. Or other cod
Am 05.09.2012, 11:48 Uhr, schrieb yuppie :
I use a single Zope instance for several small CMF sites and I use .zexp
export and import for moving CMF sites from one Zope instance to an
other. Works fine for me. Even with Plone sites.
Even if it works for you I'm not sure that this is a use c
Hi Laurence!
Laurence Rowe wrote:
On 5 September 2012 11:48, yuppie
wrote:
2.) Site root lookup: =
In several tools we still assume aq_parent(aq_inner(self)) is the
portal. Or other code uses the tool as context object, expecting root
and request in its acquisition cha
On 5 September 2012 11:48, yuppie wrote:
2.) Site root lookup: =
In several tools we still assume aq_parent(aq_inner(self)) is the
portal. Or other code uses the tool as context object, expecting root
and request in its acquisition chain.
The
Hi!
Charlie Clark wrote:
Am 04.09.2012, 15:35 Uhr, schrieb Tres Seaver :
I'd rather not add any cruft to support .zexp imports, which have seemed
fundamentally broken to me for a long time.
I'd agree on that. Occasionally, and on a strict, per object basis, they
have their use but not at th
Am 04.09.2012, 15:35 Uhr, schrieb Tres Seaver :
I'd rather not add any cruft to support .zexp imports, which have seemed
fundamentally broken to me for a long time.
I'd agree on that. Occasionally, and on a strict, per object basis, they
have their use but not at the same as updates. Or what
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/04/2012 02:59 AM, yuppie wrote:
> Hi!
>
>
> In CMF 2.3 (beta) all core tools can be looked up using getUtility for
> mandatory tools or queryUtility for optional tools. That's a big step
> forward, but there are still some places where we dep
On Mon, Sep 12, 2011 at 12:32 PM, yuppie wrote:
> Jens Vagelpohl wrote:
>> On Sep 12, 2011, at 11:52 , yuppie wrote:
>>> I propose to use 'five.globalrequest' instead of self.REQUEST inside
>>> tools. AFAICS that allows to convert *all* tools into utilities.
+1
>> Why would you want to add a dep
Hi!
Jens Vagelpohl wrote:
> On Sep 12, 2011, at 11:52 , yuppie wrote:
>> I propose to use 'five.globalrequest' instead of self.REQUEST inside
>> tools. AFAICS that allows to convert *all* tools into utilities.
>
> Why would you want to add a dependency for 3 lines of code? All that package
> doe
On Sep 12, 2011, at 11:52 , yuppie wrote:
> Hi!
>
>
> 5 years ago we started converting CMF tools into local utilities, and we
> are still stuck in the middle of that task.
>
> The problem is that local utilities don't have REQUEST in their
> acquisition chain. A few tool methods use self.RE
30 matches
Mail list logo
