subject:"\[Zope\-CMF\] \[dev\] tools as utilities"

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 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@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Re: [Zope-CMF] [dev] tools as utilities

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 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@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Re: [Zope-CMF] [dev] tools as utilities

2012-09-05 Thread Tres Seaver

-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 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  tsea...@palladion.com
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@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Re: [Zope-CMF] [dev] tools as utilities

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 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@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Re: [Zope-CMF] [dev] tools as utilities

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 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@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Re: [Zope-CMF] [dev] tools as utilities

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 /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@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Re: [Zope-CMF] [dev] tools as utilities


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@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Re: [Zope-CMF] [dev] tools as utilities

2012-09-05 Thread Tres Seaver

-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 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  tsea...@palladion.com
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@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Re: [Zope-CMF] [dev] tools as utilities

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(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@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Re: [Zope-CMF] [dev] tools as utilities


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@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Re: [Zope-CMF] [dev] tools as utilities


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 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@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Re: [Zope-CMF] [dev] tools as utilities

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 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@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Re: [Zope-CMF] [dev] tools as utilities

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
>>> 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@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Re: [Zope-CMF] [dev] tools as utilities


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 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@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Re: [Zope-CMF] [dev] tools as utilities


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

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

Re: [Zope-CMF] [dev] tools as utilities


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
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@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Re: [Zope-CMF] [dev] tools as utilities


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 essential part
of the CMF.


That's why getToolByName isn't marked as deprecated. I guess we will 
support it for a long time. But I wouldn't recommend to use 
getToolByName in new code. If we need getToolByName in CMF (and there 
are still some places where it is used), that's a sign that we haven't 
finished the 'tools as utilities' project.



Cheers,

Yuppie

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Re: [Zope-CMF] [dev] tools as utilities

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.
>
> Even if it works for you I'm not sure that this is a use case we should
> support.

I think it is. We have to have some way to move a Plone site from one
ZODB to another.

//Lennart
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Re: [Zope-CMF] [dev] tools as utilities

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 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@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Re: [Zope-CMF] [dev] tools as utilities


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 case we should  
support.


 The nastiest part of the bootstrapping issue is the fact that without  
the fallbacks currently in place you can't navigate to the Setup Tool of  
a CMF 2.2 instance and run the upgrades. The ZMI folder listing calls  
code that depends on CMF tools.
 But fixing these issues is not on the top of my list. I just mentioned  
them for the sake of completeness.


Which is fine and something we don't do often enough!


 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.


Not sure that is should actually ever become obsolete. Much as I am in  
favour of the interface-based lookup, these tools are an essential part of  
the CMF.


 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.


That's a big ask.

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@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Re: [Zope-CMF] [dev] tools as utilities


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 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@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Re: [Zope-CMF] [dev] tools as utilities

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.

 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.

Laurence
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

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

Re: [Zope-CMF] [dev] tools as utilities