Mailing List Archive: Zope: CMF

[dev] tools as utilities

Index | Next | Previous | View Threaded

y.2011 at wcm-solutions

Sep 12, 2011, 2:52 AM

Post #1 of 24 (1099 views)
Permalink

[dev] tools as utilities

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.REQUEST and the plan was
to replace these methods by view code. But that never happened. So these
tools and all tools depending on these tools are still not converted.

I propose to use 'five.globalrequest' instead of self.REQUEST inside
tools. AFAICS that allows to convert *all* tools into utilities.

What do you think?

Cheers,

Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

jens at dataflake

Sep 12, 2011, 3:00 AM

Post #2 of 24 (1057 views)
Permalink

Re: [dev] tools as utilities [In reply to]

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.REQUEST and the plan was
> to replace these methods by view code. But that never happened. So these
> tools and all tools depending on these tools are still not converted.
>
> I propose to use 'five.globalrequest' instead of self.REQUEST inside
> tools. AFAICS that allows to convert *all* tools into utilities.

Hi Yuppie,

Why would you want to add a dependency for 3 lines of code? All that package does is register a 1 line event handler. I'd rather do that in the CMF itself.

IMHO the "cleaner" way would be to make sure the request object is explicitly passed into any code that needs it.

jens

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

y.2011 at wcm-solutions

Sep 12, 2011, 3:32 AM

Post #3 of 24 (1061 views)
Permalink

Re: [dev] tools as utilities [In reply to]

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 does is register a 1 line event handler. I'd rather do that in the CMF itself.

Because it provides an API that is also used and maintained by other
people. Plone 4.1 depends on it.

> IMHO the "cleaner" way would be to make sure the request object is explicitly passed into any code that needs it.

Sure. But that requires either API changes in the tools or new view
code. The last 4 years nobody did work on this because it is much more
work than 'just' converting tools to utilities.

Cheers,

Yuppie
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

hanno at hannosch

Sep 12, 2011, 5:44 AM

Post #4 of 24 (1055 views)
Permalink

Re: [dev] tools as utilities [In reply to]

On Mon, Sep 12, 2011 at 12:32 PM, yuppie <y.2011 [at] wcm-solutions> 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 dependency for 3 lines of code? All that package does is register a 1 line event handler. I'd rather do that in the CMF itself.
>
> Because it provides an API that is also used and maintained by other
> people. Plone 4.1 depends on it.

I think we should just merge five.globalrequest into Zope2 itself.
zope.globalrequest can stay on its own. This would be for Zope 4, in
Zope 2.13 you would use the extra five.globalrequest package to enable
this.

>> IMHO the "cleaner" way would be to make sure the request object is explicitly passed into any code that needs it.
>
> Sure. But that requires either API changes in the tools or new view
> code. The last 4 years nobody did work on this because it is much more
> work than 'just' converting tools to utilities.

Yep. I think changing the actual API's of all of these tools for the
sake of better separation of concerns is not worth it anymore. We
won't turn them into nice and pretty API's anyways as there's too few
people working on this. So using the globalrequest "trick" sounds like
the best approach to me.

Hanno
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

y.2012 at wcm-solutions

Sep 5, 2012, 4:26 AM

Post #5 of 24 (689 views)
Permalink

Re: [dev] tools as utilities [In reply to]

Hi Laurence!

Laurence Rowe wrote:
> On 5 September 2012 11:48, yuppie <y.2012-E2EsyBC0hj3+aS/vkh9bjw [at] public> 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.
>>>>>
>>>>> These should be identified and replaced by
>>>>> getUtility(IURLTool).getPortalObject() or other suitable code.
>>>>
>>>> Maybe we could add a convenience API for that?
>>>
>>>
>>> getToolByName can be used instead as it does the lookups.
>>
>>
>> getToolByName is no option because it is part of the machinery that should
>> become obsolete.
>>
>> getUtility(IURLTool).getPortalObject() might be overkill because it adds the
>> request to the context. All the code that needs the request should be fixed
>> already. Using queryUtility(ISiteRoot) should be sufficient.
>>
>> But AFAICS the only way to find all the places where this needs to be fixed
>> is to set up a site with tools that are not stored in the site root.
>
> How about introducing a new getPortal() function? It could simply use
> getSite() then walk back down the acquisition chain until finding an
> object that directlyProvides ISiteRoot. In Plone KSS can introduce
> another 'component site' between its view and the portal itself.

Not sure why the discussion takes this direction. My point was that
several CMF tools/utilities might not work correctly if the site root is
not their parent. The difficult part is not to look up the site root.
The difficult part is to figure out where a lookup is required.

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 advantage compared to using getUtility(ISiteRoot)?

Cheers,

Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

l at lrowe

Sep 5, 2012, 5:03 AM

Post #6 of 24 (690 views)
Permalink

Re: [dev] tools as utilities [In reply to]

On 5 September 2012 13:26, yuppie <y.2012 [at] wcm-solutions> wrote:
> Hi Laurence!
>
>
> Laurence Rowe wrote:
>
>> On 5 September 2012 11:48, yuppie
>> <y.2012-E2EsyBC0hj3+aS/vkh9bjw [at] public> 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.
>>>>>>
>>>>>> These should be identified and replaced by
>>>>>> getUtility(IURLTool).getPortalObject() or other suitable code.
>>>>>
>>>>>
>>>>> Maybe we could add a convenience API for that?
>>>>
>>>>
>>>>
>>>> getToolByName can be used instead as it does the lookups.
>>>
>>>
>>>
>>> getToolByName is no option because it is part of the machinery that
>>> should
>>> become obsolete.
>>>
>>> getUtility(IURLTool).getPortalObject() might be overkill because it adds
>>> the
>>> request to the context. All the code that needs the request should be
>>> fixed
>>> already. Using queryUtility(ISiteRoot) should be sufficient.
>>>
>>> But AFAICS the only way to find all the places where this needs to be
>>> fixed
>>> is to set up a site with tools that are not stored in the site root.
>>
>>
>> How about introducing a new getPortal() function? It could simply use
>> getSite() then walk back down the acquisition chain until finding an
>> object that directlyProvides ISiteRoot. In Plone KSS can introduce
>> another 'component site' between its view and the portal itself.
>
>
> Not sure why the discussion takes this direction. My point was that several
> CMF tools/utilities might not work correctly if the site root is not their
> parent. The difficult part is not to look up the site root. The difficult
> part is to figure out where a lookup is required.
>
> 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
> advantage compared to using getUtility(ISiteRoot)?

While it's an accidental side effect, it is something we could make use of.

Once I merge my parent pointers branch into Zope 4 (hopefully soon),
RequestContainer wrapping is completely removed and all objects with
__parent__ pointers to the Application root will always have their
correct context (and be able to acquire the REQUEST.) This will allow
getUtility(ISiteRoot) to function correctly, along with any other
tools/utilities that have their __parent__ pointer set. The branch
lives on a temporary repository at
https://github.com/zopefoundation/Zope/tree/elro-parent-pointers, I
expect some problems with CMF trunk following the removal of
RequestContainer, but I hope to address these once I get it merged.
I'll try and post a proper writeup of its state and how to make it run
in the next few days.

Laurence
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

y.2012 at wcm-solutions

Sep 5, 2012, 6:36 AM

Post #7 of 24 (689 views)
Permalink

Re: [dev] tools as utilities [In reply to]

Hi!

Laurence Rowe wrote:
> On 5 September 2012 13:26, yuppie <y.2012-E2EsyBC0hj3+aS/vkh9bjw [at] public> 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
>> advantage compared to using getUtility(ISiteRoot)?
>
> While it's an accidental side effect, it is something we could make use of.
>
> Once I merge my parent pointers branch into Zope 4 (hopefully soon),
> RequestContainer wrapping is completely removed and all objects with
> __parent__ pointers to the Application root will always have their
> correct context (and be able to acquire the REQUEST.) This will allow
> getUtility(ISiteRoot) to function correctly, along with any other
> tools/utilities that have their __parent__ pointer set. The branch
> lives on a temporary repository at
> https://github.com/zopefoundation/Zope/tree/elro-parent-pointers, I
> expect some problems with CMF trunk following the removal of
> RequestContainer, but I hope to address these once I get it merged.
> I'll try and post a proper writeup of its state and how to make it run
> in the next few days.

Great! Making the REQUEST attribute of the app object a shortcut for
using globalrequest looks like a good BBB solution. But

- this is still a Zope 2 (Zope 4) specific feature. I hope you don't
plan to recommend using it in new code. A PendingDeprecationWarning
might be useful to figure out which code is using that legacy feature.

- that doesn't explain why you propose using getSite() instead of
getUtility(ISiteRoot).

- CMF 2.3 targets Zope 2.13 as primary platform. So we can't rely on
Zope 4 features.

Cheers,

Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

charlie.clark at clark-consulting

Sep 5, 2012, 6:39 AM

Post #8 of 24 (689 views)
Permalink

Re: [dev] tools as utilities [In reply to]

Am 05.09.2012, 15:36 Uhr, schrieb yuppie <y.2012 [at] wcm-solutions>:

> - 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
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

charlie.clark at clark-consulting

Sep 5, 2012, 6:42 AM

Post #9 of 24 (689 views)
Permalink

Re: [dev] tools as utilities [In reply to]

Am 05.09.2012, 15:05 Uhr, schrieb Lennart Regebro <regebro [at] gmail>:

> 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 per non-container object basis
okay but not beyond that.

Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

l at lrowe

Sep 5, 2012, 6:55 AM

Post #10 of 24 (689 views)
Permalink

Re: [dev] tools as utilities [In reply to]

On 5 September 2012 15:36, yuppie <y.2012 [at] wcm-solutions> wrote:
> Hi!
>
>
> Laurence Rowe wrote:
>
>> On 5 September 2012 13:26, yuppie
>> <y.2012-E2EsyBC0hj3+aS/vkh9bjw [at] public> 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
>>> advantage compared to using getUtility(ISiteRoot)?
>>
>>
>> While it's an accidental side effect, it is something we could make use
>> of.
>>
>> Once I merge my parent pointers branch into Zope 4 (hopefully soon),
>> RequestContainer wrapping is completely removed and all objects with
>> __parent__ pointers to the Application root will always have their
>> correct context (and be able to acquire the REQUEST.) This will allow
>> getUtility(ISiteRoot) to function correctly, along with any other
>> tools/utilities that have their __parent__ pointer set. The branch
>> lives on a temporary repository at
>> https://github.com/zopefoundation/Zope/tree/elro-parent-pointers, I
>> expect some problems with CMF trunk following the removal of
>> RequestContainer, but I hope to address these once I get it merged.
>> I'll try and post a proper writeup of its state and how to make it run
>> in the next few days.
>
>
> Great! Making the REQUEST attribute of the app object a shortcut for using
> globalrequest looks like a good BBB solution. But
>
> - this is still a Zope 2 (Zope 4) specific feature. I hope you don't plan to
> recommend using it in new code. A PendingDeprecationWarning might be useful
> to figure out which code is using that legacy feature.
>
> - that doesn't explain why you propose using getSite() instead of
> getUtility(ISiteRoot).
>
> - CMF 2.3 targets Zope 2.13 as primary platform. So we can't rely on Zope 4
> features.

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 the component site set as a thread local during traversal.
Assuming that has an acquisition context including the portal then we
have the portal object with its correct acquisition context so can
call portal.absolute_url().

Another alternative would be to set the portal directly as a thread
local during the traversal (just as setSite() is called) and clear it
at the end of the request.

Laurence
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

regebro at gmail

Sep 5, 2012, 7:00 AM

Post #11 of 24 (689 views)
Permalink

Re: [dev] tools as utilities [In reply to]

On Wed, Sep 5, 2012 at 3:42 PM, Charlie Clark
<charlie.clark [at] clark-consulting> 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 do
that, but we were just messing with you so now you are fucked".
Well, I don't think we should say that.

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.

//Lennart
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

charlie.clark at clark-consulting

Sep 5, 2012, 7:10 AM

Post #12 of 24 (689 views)
Permalink

Re: [dev] tools as utilities [In reply to]

Am 05.09.2012, 16:00 Uhr, schrieb Lennart Regebro <regebro [at] gmail>:

> 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 of context.

> Well, I don't think we should say that.

I won't be telling Plone users anything. And anyone with an existing Plone
2.5 or earlier site has a more problems than CMF 2.3 compatibility, which
the last I heard was not intended anyway. I've recently struggled with a
Plone 3 to Plone 4 migration and would not wish the same on anyone else.

There are lots of good reasons for having only one website per Data.fs /
Zope instance.

> 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.

The CMF (has to) treats its users as adults. While Yuppie has described
that he uses that setup he also pointed out the possible pitfalls of doing
so. Given the recent discussion I do think it would be a good idea to make
this policy with a note that other setups may work but will not be
supported.

Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

y.2012 at wcm-solutions

Sep 5, 2012, 7:26 AM

Post #13 of 24 (689 views)
Permalink

Re: [dev] tools as utilities [In reply to]

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 the component site set as a thread local during traversal.
> Assuming that has an acquisition context including the portal then we
> have the portal object with its correct acquisition context so can
> call portal.absolute_url().
>
> Another alternative would be to set the portal directly as a thread
> local during the traversal (just as setSite() is called) and clear it
> at the end of the request.

Now I see your point. But

- getUtility(IURLTool).getPortalObject() also returns the portal with a
complete acquisition chain.

- if tools are looked up as utilities, they don't have the request in
their acquisition chain. That might cause trouble if Plone switches to
CMF 2.3, but in CMF itself all code that tries to get the request by
acquisition from a tool was fixed. That also means that tools depending
on the portal as parent *don't* depend on a portal with request in the
acquisition chain. So if this has to be fixed inside the tools,
getUtility(ISiteRoot) is sufficient.

Cheers,

Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

l at lrowe

Sep 5, 2012, 7:54 AM

Post #14 of 24 (689 views)
Permalink

Re: [dev] tools as utilities [In reply to]

On 5 September 2012 16:26, yuppie <y.2012 [at] wcm-solutions> 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(portal), which is unlikely to be useful. getSite() instead
>> returns the component site set as a thread local during traversal.
>> Assuming that has an acquisition context including the portal then we
>> have the portal object with its correct acquisition context so can
>> call portal.absolute_url().
>>
>> Another alternative would be to set the portal directly as a thread
>> local during the traversal (just as setSite() is called) and clear it
>> at the end of the request.
>
>
> Now I see your point. But
>
> - getUtility(IURLTool).getPortalObject() also returns the portal with a
> complete acquisition chain.
>
> - if tools are looked up as utilities, they don't have the request in their
> acquisition chain. That might cause trouble if Plone switches to CMF 2.3,
> but in CMF itself all code that tries to get the request by acquisition from
> a tool was fixed. That also means that tools depending on the portal as
> parent *don't* depend on a portal with request in the acquisition chain. So
> if this has to be fixed inside the tools, getUtility(ISiteRoot) is
> sufficient.

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().getPhysicalPath() will be ['portal']
getUtility(IURLTool).getRelativeContentPath(content) will be ['porta',
'content'] instead of ['content']

You'd need to stop having any portals contained in folders, something
that's fine for new sites but will prevent upgrades.

Laurence
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

tseaver at palladion

Sep 5, 2012, 8:01 AM

Post #15 of 24 (689 views)
Permalink

Re: [dev] tools as utilities [In reply to]

-----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
> <charlie.clark [at] clark-consulting>
> 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
> do that, but we were just messing with you so now you are fucked".
> Well, I don't think we should say that.
>
> 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 to migrate such
sites (that is what GS is for, after all).

Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver [at] palladion
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBHaT8ACgkQ+gerLs4ltQ6uDQCgnfmSR1kkumUJTPUnlbBtN+YE
2+oAoJpHjoK/S7aVk9xVeLDr9NVMESkL
=AXwq
-----END PGP SIGNATURE-----

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

y.2012 at wcm-solutions

Sep 5, 2012, 8:15 AM

Post #16 of 24 (689 views)
Permalink

Re: [dev] tools as utilities [In reply to]

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().getPhysicalPath() will be ['portal']
> getUtility(IURLTool).getRelativeContentPath(content) will be ['porta',
> 'content'] instead of ['content']
>
> You'd need to stop having any portals contained in folders, something
> that's fine for new sites but will prevent upgrades.

Not sure who is missing something and what. Just a wild guess:

Are you aware of the fact that five.localsitemanager just removes the
RequestContainer, not the complete acquisition chain?

And that CMF 2.3 adds a RequestContainer in getPortalObject()?

Cheers, Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

l at lrowe

Sep 5, 2012, 10:21 AM

Post #17 of 24 (689 views)
Permalink

Re: [dev] tools as utilities [In reply to]

On 5 September 2012 17:15, yuppie <y.2012 [at] wcm-solutions> 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 /folder/portal/content
>> getUtility(IURLTool).getPortalObject().getPhysicalPath() will be
>> ['portal']
>> getUtility(IURLTool).getRelativeContentPath(content) will be ['porta',
>> 'content'] instead of ['content']
>>
>> You'd need to stop having any portals contained in folders, something
>> that's fine for new sites but will prevent upgrades.
>
>
> Not sure who is missing something and what. Just a wild guess:
>
> Are you aware of the fact that five.localsitemanager just removes the
> RequestContainer, not the complete acquisition chain?
>
> And that CMF 2.3 adds a RequestContainer in getPortalObject()?

Ok, I wasn't aware that five.localsitemanager restored a partial aq
chain. The RequestContainer is removed to avoid caching old requests
as part of the aq_chain of utilities.

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.

Laurence
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

l at lrowe

Sep 5, 2012, 11:36 AM

Post #18 of 24 (689 views)
Permalink

Re: [dev] tools as utilities [In reply to]

On 5 September 2012 19:21, Laurence Rowe <l [at] lrowe> wrote:
> On 5 September 2012 17:15, yuppie <y.2012 [at] wcm-solutions> 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 /folder/portal/content
>>> getUtility(IURLTool).getPortalObject().getPhysicalPath() will be
>>> ['portal']
>>> getUtility(IURLTool).getRelativeContentPath(content) will be ['porta',
>>> 'content'] instead of ['content']
>>>
>>> You'd need to stop having any portals contained in folders, something
>>> that's fine for new sites but will prevent upgrades.
>>
>>
>> Not sure who is missing something and what. Just a wild guess:
>>
>> Are you aware of the fact that five.localsitemanager just removes the
>> RequestContainer, not the complete acquisition chain?
>>
>> And that CMF 2.3 adds a RequestContainer in getPortalObject()?
>
> Ok, I wasn't aware that five.localsitemanager restored a partial aq
> chain. The RequestContainer is removed to avoid caching old requests
> as part of the aq_chain of utilities.
>
> 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 gave this a go in
http://zope3.pov.lt/trac/changeset/127722/five.localsitemanager/branches/global-request-container

It seems to work fine with the CMF trunk tests even when I remove all
RequestContainer wrapping from both CMFCore and CMFDefault (the
CMFDefault tests then fail with five.localsitemanage trunk.)

http://zope3.pov.lt/trac/changeset/127724/Products.CMFCore/branches/global-request-container
http://zope3.pov.lt/trac/changeset/127726/Products.CMFDefault/branches/global-request-container

Laurence
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

regebro at gmail

Sep 5, 2012, 10:37 PM

Post #19 of 24 (670 views)
Permalink

Re: [dev] tools as utilities [In reply to]

On Wed, Sep 5, 2012 at 5:01 PM, Tres Seaver <tseaver [at] palladion> 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 to migrate such
> sites (that is what GS is for, after all).

I'm confused now. GenericSetup has never been able to reliably export
the content of a Plone site, to my knowledge.
I'm sure we could make that happen, of course, but is that really less
work than having zexp work? :-)

//Lennart
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

tseaver at palladion

Sep 5, 2012, 10:59 PM

Post #20 of 24 (670 views)
Permalink

Re: [dev] tools as utilities [In reply to]

-----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
> <tseaver [at] palladion> 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 to migrate
>> such sites (that is what GS is for, after all).
>
> I'm confused now. GenericSetup has never been able to reliably export
> the content of a Plone site, to my knowledge. I'm sure we could make
> that happen, of course, but is that really less work than

I have no idea what you man. GS has been the *only* means I have used
for migrating CMF / Plone based sites for going on years now: I haven't
used a .zexp export to do so in more than a decade (since well before GS
was even released).

(I am talking about sites with literally millions of content objects, BTW).

Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver [at] palladion
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBIO74ACgkQ+gerLs4ltQ4PoQCffkrkUVwWyyGlqXJznQRJH4QW
h9gAn26PAPViJC/C5O5/ksfDtGE0Q2tk
=fuB+
-----END PGP SIGNATURE-----

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

regebro at gmail

Sep 5, 2012, 11:09 PM

Post #21 of 24 (670 views)
Permalink

Re: [dev] tools as utilities [In reply to]

On Thu, Sep 6, 2012 at 7:59 AM, Tres Seaver <tseaver [at] palladion> 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
>> <tseaver [at] palladion> 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 to migrate
>>> such sites (that is what GS is for, after all).
>>
>> I'm confused now. GenericSetup has never been able to reliably export
>> the content of a Plone site, to my knowledge. I'm sure we could make
>> that happen, of course, but is that really less work than
>
> I have no idea what you man. GS has been the *only* means I have used
> for migrating CMF / Plone based sites for going on years now: I haven't
> used a .zexp export to do so in more than a decade (since well before GS
> was even released).
>
> (I am talking about sites with literally millions of content objects, BTW).

Impressive, I usually have gotten errors during the export, because it
tries to export content objects when I don't want to, I just want to
back up the configuration.
Of course, there is the problem that some configuration uses content
objects, so if you try to export just configuration and not content
you have problems anyway, but I don't know what we can do about
that...

(I have to say though that I think the claim that this is what GS is
for probably is news to many. It was always pushed as a way to do
*setup* not exporting content. Ah well).

//Lennart
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

y.2012 at wcm-solutions

Sep 5, 2012, 11:14 PM

Post #22 of 24 (670 views)
Permalink

Re: [dev] tools as utilities [In reply to]

Hi Laurence!

Laurence Rowe wrote:
> On 5 September 2012 19:21, Laurence Rowe <l [at] lrowe> 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 gave this a go in
> http://zope3.pov.lt/trac/changeset/127722/five.localsitemanager/branches/global-request-container
>
> It seems to work fine with the CMF trunk tests even when I remove all
> RequestContainer wrapping from both CMFCore and CMFDefault (the
> CMFDefault tests then fail with five.localsitemanage trunk.)
>
> http://zope3.pov.lt/trac/changeset/127724/Products.CMFCore/branches/global-request-container
> http://zope3.pov.lt/trac/changeset/127726/Products.CMFDefault/branches/global-request-container

Nice!

Unfortunately there's a trade-off:

Modernizing the RequestContainer concept makes it possible to move
forward in some areas without breaking existing code. That's a good thing.

But on the other hand it makes it easy to write bad code. New code
should not rely on this. People should write views if their code depends
on the request, not utilities.

I think this discussion is closely related to your plans for Zope 4: If
Zope 4 will (re-)enable the get-request-by-acquisition pattern
everywhere, it doesn't make much sense to be more restrictive in CMF 2.3
on Zope 2.13.

Please consider providing tools for people who want to write clean code.
Documentation, warnings, maybe even a switch for disabling the legacy
behavior.

Cheers,

Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

patrick.gerken at computer

Sep 6, 2012, 2:56 AM

Post #23 of 24 (672 views)
Permalink

Re: [dev] tools as utilities [In reply to]

On Thu, Sep 6, 2012 at 7:59 AM, Tres Seaver <tseaver [at] palladion> 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
>> <tseaver [at] palladion> 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 to migrate
>>> such sites (that is what GS is for, after all).
>>
>> I'm confused now. GenericSetup has never been able to reliably export
>> the content of a Plone site, to my knowledge. I'm sure we could make
>> that happen, of course, but is that really less work than
>
> I have no idea what you man. GS has been the *only* means I have used
> for migrating CMF / Plone based sites for going on years now: I haven't
> used a .zexp export to do so in more than a decade (since well before GS
> was even released).

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?
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

charlie.clark at clark-consulting

Sep 6, 2012, 3:07 AM

Post #24 of 24 (670 views)
Permalink

Re: [dev] tools as utilities [In reply to]

Am 06.09.2012, 11:56 Uhr, schrieb Patrick Gerken
<patrick.gerken [at] computer>:

> 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 objects from one Zope system to another? I guess you can as long
as you provide the right upgrade steps for your content types, ie. you
write the missing management stuff, as transmogrify seems to do.

Tres, please correct me if I'm wrong on that.

In terms of CMF I think we could add something that would allow content
objects to be ex- and importable. Though like Patrick I'm not too sure how
this would handle adapted content.

Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] zope
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads