Re: [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
-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
[Zope-CMF] cmf-tests - OK: 4
This is the summary for test reports received on the cmf-tests list between 2012-09-04 00:00:00 UTC and 2012-09-05 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received CMF-2.2 Zope-2.12 Python-2.6.8 : Linux CMF-2.2 Zope-2.13 Python-2.6.8 : Linux CMF-trunk Zope-2.13 Python-2.6.8 : Linux CMF-trunk Zope-trunk Python-2.6.8 : Linux Non-OK results -- ___ 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
-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
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 the same as updates. Or what do you have in mind? 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. 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. 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. 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] Security declarations on adapters
Hi Charlie! Charlie Clark wrote: * is there an easy way to write the test for something that requires a tool and some content? The setup of your doctest looks fine, you just have to enable syndication for the folder (app.site) to get the view. * backporting the changes to the PythonScript I hit a roadblock that I can't use security declarations on the adapter. Fortunately, I was able to use the tool as a workaround but, apart from ripping out the PythonScript, I can't think of a better solution. I think CMF 2.3 should ship with a complete oldstyle skin. So it would be nice if you could get this working. But I guess it will be the last release with the oldstyle skin as default. In the long run it will become unmaintained. Any ideas? I'm also struggling with a convenient way of handling the difference in time formatting arising form using native datetime and DateTime with it's convenient rfc822 method Removing DateTime completely has no high priority. If you need it as a formatting tool, just use it. 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
