Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed
On Mon, Aug 17, 2009 at 5:48 PM, Alec Mitchell wrote: > It may make the > most sense to remove the Quoted Printable config from MailHost and > just punt this decision to some future release. Currently your changes only apply to Zope trunk aka 2.13 which is in early development. The change looks perfectly fine to me for that release. If you get the permission to backport these changes to 2.12 (or be bold enough to just do it, since they seem to make sense) you could back out this one change, so the 2.12 would keep the slightly more backwards compatible notion. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
On Sat, Aug 8, 2009 at 12:14 AM, Charlie Clark wrote: > Is the patch for Plone or CMF? It's for Plone, I guess. The "problem is solved" in Plone 4.0 itself (via monkey-patching CMF). > If it's for CMF then you should consider simply submitting a patch or > opening a branch. But before you write any package I would like to know a > little more about what exactly you want to do. The problem is the entire concept of opaque items. The only places I know they are still in use is the "talkback" objects as used by the discussion machinery in CMF. CMFUid also claims to implement the concept, but doesn't actually need any of the functionality, since it has its own event subscribers to deal with things. So the problem starts in CMFCore.CMFCatalogAware.dispatchToOpaqueItems, with the nice line: for opaque in ob.opaqueValues(): which in turn calls later on the opaqueItems method which contains this beauty: self_base = aq_base(self) for name in self_base.__dict__.keys() obj = getattr(self, name) if ICallableOpaqueItem.providedBy(obj): items.append((obj.getId(), obj)) The whole method redispatches any IObjectEvent fired on an IOpaqueItemManager to any opaque item in it. In doing so, it needs to load every single entry in the objects __dict__ to see if it is an ICallableOpaqueItem. It happens that the CMFCatalogAware base class is such an IOpaqueItemManager, so any essentially any content object gets this treatment. Now imagine you edit the title of a folderish type containing 1000+ items. Thanks to the above you will also load all items it contains from the database. Any add/delete/edit operation on a large folderish type suddenly becomes increasingly slow. On the Plone level we decided to no longer support the opaque items concept except for the talkback item. That simplifies the whole overhead into a simple attribute lookup for that one item and avoids the overhead of checking every contained item. I don't know how such a feature removal or deprecation would be handled on the CMF level. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
On Fri, Aug 7, 2009 at 9:17 PM, toutpt wrote: > experimental.opaquespeedup is good but not enough for me. The load tests > results are not enough, I want to be more 'aggressive' and > experimental. For me this package is backward compatible and do a > catalog query instead of parsing all attributes. I want to do nothing > except support 'talkback'. I want also to release this package on pypi, > and I want your opionons: > > * makina.opaquespeedup (makina is where I m working) > * experimental.aggressiveopaquespeedup > * any other idea ? > > My vote goes to experimental.aggressiveopaquespeedup Either way is fine, just pick the one you like :) Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
On Mon, Aug 3, 2009 at 11:09 PM, toutpt wrote: > I don't really understand why all these improvements are not merged > inside plone3.X and CMF and are marked up as 'experimental'. The opaque items issue at hand is not a simple and clear "bug fix". On the Plone level we have decided to no longer support this particular feature of CMF as it causes too much of a performance bottleneck for us. This is removing a feature which might be used by custom code or add-ons, even though there are no known add-ons, which actually depend on this feature. In a major release like the new Plone 4, we can make such a more radical change and remove a feature, but this has been too invasive to put into a Plone 3.x release. The improvements form the contentcreation package are similar and can potentially cause problems for code that relies on specific semantics during content creation in the portal_factory tool. The changes have been merged into the Plone 4 code as well now, but have been found to be too risky for Plone 3.x. The catalogqueryplan work is of a different kind and really requires a complete re-factoring of the catalog system as used in Plone to be done properly. Right now it is a set of monkey-patches for various internals of the catalog and the BTree classes. The work is also still ongoing to make the code more general. Since the catalog is one of the spots that thanks to its widespread use in Plone is also customized extensively, changes to it are particular risky to do. There is a whole number of other changes and techniques that are known to speed up Plone. One of the major problems is that these are often very easy to do given a particular single site, which can assume a lot of constraints about the way it is used. But the complexity of different usage patterns and the endless flexibility of configuration options make it very hard to improve performance in a general way. A typical issue of this kind is the question if a particular feature needs to be configurable per database configuration or just based on file system settings. In the latter case there can often be a number of things that can be cached at startup time avoiding the additional database lookups per view call. This is something Plone cannot do in general, but can bring substantial improvements for particular sites. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
On Mon, Aug 3, 2009 at 10:46 PM, toutpt wrote: > I m currently profiling the code of Plone to find performance issue and > fix them (i m sure there are a lot). Did you try to install all the experimental.* (opaquespeedup, contentcreation, catalogqueryplan) packages that have been done over the last year? They help to address some of the known performance problems. For the particular issue at hand you can either use the opaquespeedup package which has a more conservative approach to fixing this issue or backport the approach taken in Plone 4 as per https://svn.plone.org/svn/plone/Plone/branches/4.0/Products/CMFPlone/patches/speed.py Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Zope dependency
Jens Vagelpohl wrote: > On May 26, 2009, at 10:21 , Wichert Akkerman wrote: >> Previously Jens Vagelpohl wrote: >>> The CMF eggs, even on trunk, still advertise compatibility with Zope >>> 2.10. I believe we had agreed to target Zope 2.12 with trunk - please >>> correct me if that's wrong. If we do want Zope 2.12 I would like to >>> go >>> through before the first CMF 2.2 beta and do the following: >>> >>> - adjust all setup.py files to show the Zope2 egg as dependency, >>> which will imply the "Zope2 >= 2.12dev" dependency >>> >>> - go through and delete all BBB code for Zope versions earlier than >>> 2.12 >>> >>> If anyone thinks that's a bad idea please speak up. >> I think we are targetting Plone 4 at CMF 2.2 and Zope 2.11 at the >> moment, so that would be bad for us. Yep, the new Plone 4.0 (to be released sometime this year) is planned to be a new more stable stepping stone to the Plone trunk work that is going on for a while. We have been talking about using Zope 2.11 for that release so far, since Zope 2.12 is quite invasive. But I think that's a decision that is still to be made and we can go with 2.12 for the new Plone 4. If there are good reasons for the CMF developers to switch to an exclusive Zope 2.12 platform, Plone can deal with that. If there's no real reason except "it's newer" and the cost of being compatible with both 2.11 and 2.12 isn't too high, targeting both Zope versions might be nicer. > I'm guessing you are not aware that there already is a hard dependency > in CMFDefault. In essence, I would not be setting a new policy, I > would document the current situation. Why doesn't that generate test failures? We are running nightly tests testing CMF trunk with Zope 2.10, 2.11 and 2.12. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] five.localsitemanager: 1.0 branch dependencies
yuppie wrote: > I doubt you can satisfy the requirements for five.localsitemanager 2.0 > in a Zope version older than 2.12. That's why Zope2 >= 2.12.dev is > specified as dependency. I thought you were fine with that. > > five.localsitemanager 1.x doesn't depend on eggified Zope versions, so > we need different ways to make recommendations. > > That said, I don't care much about the solution for older packages. > Removing just the version number doesn't seem to make sense because no > other unrestricted dependencies are specified. But I'm not familiar with > the consequences for fake-egg based installations. So feel free to make > any changes you like. Right, sorry. Just ignore me, bad day syndrome ;) Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] five.localsitemanager: 1.0 branch dependencies
Wichert Akkerman wrote: > Previously yuppie wrote: >> I'd like to change install_requires to 'zope.component < 3.6dev' and >> make tests work with zope.component 3.5.1 and older versions. >> >> Any objections? I'd just remove the version number altogether. If this version works with a yet unreleased version or not is speculation. The recommendation for using the 2.0 version with Zope 2.12 is a KGS information and not a requirement in my view. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IndexableObjectWrapper
Martin Aspeli wrote: > Jens Vagelpohl wrote: >> Is there any kind of low-traffic announcement list for things like >> PLIPs? I'm not subscribed to any Plone list because of (for me at >> least) signal to noise ratio fears. > > There's plone-announce, but I don't think this was announced there. plone-announce is targeted at consumers of Plone, so has information like "New Symposium coming up", "Plone 3.2 released". > I actually think the Plone release manager should cross-post a few > important announcements to this list, though. We could probably do that. There is a lot of information which isn't relevant at all to the CMF level nor the Zope level in the same ways. > The actual feature discussion happens on the medium-traffic > framework-team list, which you can join. In fact, it'd be great if you > did, as we'd appreciate your input, but I realise it may not be > something you want to spend a lot of time on. One way to get quite a filtered list is to look at the PLIP's themselves from time to time. For Plone 3.3 this is: http://plone.org/products/plone/releases/3.3 We can make sure to post the important dates for our release process to this list and provide at least this kind of URL. For Plone 4.0 we haven't probably started the process yet (my fault) but have some things available in the listing at: http://dev.plone.org/plone/milestone/4.0 The items on the 4.0 list here are basically all of my personal pet peeves and there's a lot of more things we are going to do, like completely revamp the admin UI and probably use Dexterity for the default types, while retaining backwards compatible support with Archetypes. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CMF 2.2 plans?
yuppie wrote: > That would mean that CMFDefault-the-example-application will depend on > z3c.form. If we are going to split off the forms we need to split off > all browser views and the profiles that use these views. Something like > 'cmf.app' that includes all the CMFDefault stuff Plone doesn't depend on. I'd be generally in favor of making the distinction between the CMFDefault-example-application and the reusable parts as used by for example Plone clearer. This can happen in two ways, though. Either move the example-application bits into a different package or move the reusable bits into one. If you are really interested in doing this work, I'd be happy to figure out what parts of CMFDefault Plone is actually using. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CMF 2.2 plans?
yuppie wrote: > 2.) get rid of redundant type info properties > - > > See http://mail.zope.org/pipermail/zope-cmf/2009-January/028059.html > > Unfortunately nobody seems to feel responsible for this. My mail had: "I have one small todo item on my list regarding the changes to content type icons." I'm referring to the same thing here. Without any release date planned whatsoever, it wasn't high on my list so far ;) Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] [dev] CMF 2.2 plans?
Hi. Quoting a mail from Jens from September last year: "Is there anything to hold back a CMF 2.2.0 beta at this point?" I have one small todo item on my list regarding the changes to content type icons. Things I remember people working on: - Formlib based views - Add-views http://www.zope.org/Products/CMF/docs/roadmap/view has a couple of items, I'm not sure about. Is there anything missing, people would like to have in a new version? It should be no surprise, that I'd like to have official support for Zope 2.12 for CMF 2.2 as well ;) Nightly tests are running fine for all I can see. As Zope 2.12 is not likely to be released before Summer, would that be a reasonable timeframe to aim for a CMF 2.2 final release as well? Hanno P.S. I would appreciate some kind of first alpha or beta release soonish, so we can start releasing Plone 4 preview releases based on this... ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] five.localsitemanager: dependencies
Hanno Schlichting wrote: > If a package only depends on Acquisition, DateTime and zope.* packages > it does no longer depend on "Zope2". I'd like to encourage people to > look at their real dependency and be honest about those. Especially > looking at things from the perspective of: "why does my package have a > Zope2 dependency" instead of "I use this inside Zope2, so let's specify > Zope2". The later information is where a classifier of > "Framework::Zope2" is appropriate, the former is not. Damn, too late. I meant: Only add a install_requires=['Zope2'] if you really have a dependency on the Zope2 package. Never ever make the mistake of doing the lazy thing and mistaking it for a "I work with Zope2". The expression of "working with" or "intended for" is what the classifiers are for. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] five.localsitemanager: dependencies
yuppie wrote: > Hanno Schlichting wrote: >> In a package based world, if you specify a dependency on a package, you >> can in my opinion only rely on the package contents itself to be there. >> You cannot rely on its dependencies to stay around. > > I agree with you in general, but Zope2 is a special package because it > represents the Zope 2 platform and ships with a KGS. I'm fine with giving the Zope2 package this special meaning of representing "the framework". As long as people don't mistake this as a general rule to say: Oh, I just use this with Zope2, so lets specify it as a dependency and don't think about it. If a package only depends on Acquisition, DateTime and zope.* packages it does no longer depend on "Zope2". I'd like to encourage people to look at their real dependency and be honest about those. Especially looking at things from the perspective of: "why does my package have a Zope2 dependency" instead of "I use this inside Zope2, so let's specify Zope2". The later information is where a classifier of "Framework::Zope2" is appropriate, the former is not. > Keeping all specified dependencies of all packages always up to date is > a big maintenance burden. Or do you have a tool that syncs the specified > dependencies with the code base automatically? I don't have a tool to do this. Personally I think specifying dependencies is the same as keeping a changelog updated or being strict about version numbers - it's the extra administrative burden you get, for making things into a package and offering it for reuse. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 4 OK, 1 Failed, 1 Unknown
Charlie Clark wrote:
> Am 03.02.2009 um 13:45 schrieb Hanno Schlichting:
>> ZopeXMLConfigurationError: File
>> "/home/stefan/autotest/temp/python24-zope212-cmf22/Products/
>> CMFDefault/skin/configure.zcml",
>> line 12.2
>>ConfigurationError: ('Unknown directive',
>> u'http://namespaces.zope.org/browser', u'defaultSkin')
>>
>> defaultSkin has been deprecated in 2006 and now finally removed. I
>> don't quite know what this actually does and if this is in actual
>> use by CMF.
I re-read the code again and actually made a mistake. The deprecation
warnings did not include defaultSkin and so I put it back.
Sorry for the noise,
Hanno
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 4 OK, 1 Failed, 1 Unknown
CMF Tests Summarizer wrote:
> Summary of messages to the cmf-tests list.
> Period Mon Feb 2 12:00:00 2009 UTC to Tue Feb 3 12:00:00 2009 UTC.
> There were 6 messages: 6 from CMF Tests.
>
> Test failures
> -
>
> Subject: FAILED (failures=2, errors=3) : CMF-trunk Zope-trunk Python-2.5.4 :
> Linux
> From: CMF Tests
> Date: Mon Feb 2 21:10:01 EST 2009
> URL: http://mail.zope.org/pipermail/cmf-tests/2009-February/010854.html
>
> Unknown
> ---
>
> Subject: UNKNOWN : CMF-trunk Zope-trunk Python-2.4.5 : Linux
> From: CMF Tests
> Date: Mon Feb 2 21:08:28 EST 2009
> URL: http://mail.zope.org/pipermail/cmf-tests/2009-February/010853.html
Those are partly my fault. I updated the Zope trunk tree to the latest
zope.* versions which remove some deprecated stuff (this is Zope 2.12
including what will become Zope 3.5).
ZopeXMLConfigurationError: File
"/home/stefan/autotest/temp/python24-zope212-cmf22/Products/CMFDefault/skin/configure.zcml",
line 12.2
ConfigurationError: ('Unknown directive',
u'http://namespaces.zope.org/browser', u'defaultSkin')
defaultSkin has been deprecated in 2006 and now finally removed. I don't
quite know what this actually does and if this is in actual use by CMF.
five.localsitemanager needs to be adopted to the new zope.site package
from what I can see. I'll try to do that this evening.
Hanno
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] type info: content_icon vs. icon_expr property
Hi. yuppie wrote: > I just noticed this checkin: http://svn.zope.org/?rev=94014&view=rev > > And I'm a bit confused. What's the plan? Maintaining redundant > information? Using a different icon for the add action? Deprecating > content_icon and migrating everything to icon_expr? I would be fine with deprecating content_icon and switching to icon_expr instead of maintaining both. The only place I know where this would be a bit difficult is in Products.CMFCore.TypesTool.TypeInformation.getIcon which returns the icon name and not the complete URL. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] Should portal_setup be registered as utility?
yuppie wrote: > CMFDefault registers portal_setup as utility. Some code in CMF depends > on that. > > Plone doesn't doesn't register portal_setup as utility: > http://dev.plone.org/plone/changeset/18763 > > That causes some trouble in Plone: > http://dev.plone.org/plone/ticket/7714 > > The same issue was reported as CMF bug: > https://bugs.launchpad.net/zope-cmf/+bug/263525 > > Due to a misunderstanding the CMF bug was marked as 'Won't Fix'. > > Questions: Is there a good reason why Plone doesn't register > portal_setup as utility? Does the same reason apply to CMFDefault? Do we > have to support registered and not registered portal_setup tools? The reason why we don't register the setup tool as an utility anymore, is that too many import/export steps in-the-wild required the REQUEST to be available. In general we removed the tool as utility registrations for all tools where a request was still required. We'd like to put those back only after the request is really not used anymore i.e. after the code has been adjusted - not force any code to be changed due to the utility registration. I'd prefer the portal_setup tool utility registration to be removed again. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] portal_fiveactions
Jens Vagelpohl wrote: > > On Oct 4, 2008, at 17:28 , Hanno Schlichting wrote: > >> Jens Vagelpohl wrote: >>> Is anyone actually using the portal_fiveactions tool and the supposed >>> bridging between Z3 menus and CMF actions it is promising? I'm >>> wondering if it's dead wood we're carrying around since it really has >>> not been touched much after the initial import: >> I think nobody is using it. > >> I doubt it works with "new-style" CMF actions anyways. > > Just for clarification: The "Five Actions Tool" does not replace the > normal actions tool, it's a separate tool that acts as an action > provider providing only those "bridged" menu actions. So it's > legitimate if it doesn't care about old- or new-style actions. I thought the actions it emits trough the action providers API are old-style ones and it doesn't register itself in portal_actions as an action provider... But no matter what the code does, nobody is using it. I think it's an artifact from the early "Zope 3 everywhere"-days. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] portal_fiveactions
Jens Vagelpohl wrote: > Is anyone actually using the portal_fiveactions tool and the supposed > bridging between Z3 menus and CMF actions it is promising? I'm > wondering if it's dead wood we're carrying around since it really has > not been touched much after the initial import: I think nobody is using it. I doubt it works with "new-style" CMF actions anyways. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] Re: Problem with Registering Local Utilities on reinstall of product
Hi. There's two issues here. One is with quick installer and one is with GenericSetup. This mailing list is not the right place to discuss issues with the first, please do that on the Plone developers mailing list. Nathan Van Gheem wrote: Martin Aspeli pointed out, I think the problem is in Products.GenericSetup.components - in _initUtilities it does elif factory is not None: self.context.registerUtility(factory(), provided, name) without first checking of a utility with this name for this interface already exists. The code here does seem indeed to be wrong. There's two modes for GS import handlers, one being with purge and one without. The code in question does not support that correctly. It does work in some cases, as the underlying registerUtility function first checks if the component was already registered. It does so effectively by checking the newly registered object and the one that is already registered for equality. This check obviously fails in case of creating a new utility via a factory. There is a bug report for this already at: https://bugs.launchpad.net/bugs/240170 I don't know how to go about fixing this problem since the infrastructure is not set up to handle this. Realistically, if there is an uninstall of a component needed, I would think it could be handled in the Products.GenericSetup.components class. GenericSetup doesn't have any uninstall support, so this is not the right place to handle this. Your main issue here is with quick installer. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMFCore badly registered on PyPI
Hi.
Dieter Maurer wrote:
I tried to easy_install CMFCore from PyPI -- this failed.
Not supported yet :)
Apparently, "CMFCore" is only registered on "PyPI", not uploaded (this
is okay).
I registered all the package names a while back, but forgot to remove
the 2.2.dev releases again. This is done now, so that there's no even
partial releases on PyPi anymore.
Moreover, the url registered as home page
("http://www.zope.org/Products/CMFCore";) apparently does not exist.
I do not think that this is a good sign...
The setup.py files of all the individual packages need some love. I'm
currently quite pressed for time, so I haven't had a chance to do that yet.
Hanno
P.S. Currently Tres and Jens have PyPi access besides me. Yvo do you
have a PyPi account as well, so I can give you access?
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Multiple GS profiles per product
Hi. Maurits van Rees wrote: This is on Plone 3.0 with CMFQuickInstaller 2.0.4. I think you are on the wrong list here. QuickInstaller is a part of Plone and not CMF and should be discussed on plone-dev. I'll give some responses anyways ;) Question 1: can I influence which profile is picked here? Should we add some code to the QuickInstaller.getInstallProfile(s) methods to for instance prefer a profile with a name like "productname:default"? Picking the first profile from the arbitrarily sorted list of profiles is obviously a shortcoming of QI. The main problem here is that QI uses the product name as a primary key for all its operations and thus can only really handle one installation record for one product. The whole use of extension profiles as installation procedures is a bit of a hack. What should really happen and which I'll do for Plone 4.0 is to remove the support for Extensions/Install.py and give up the one-to-one relationship between products and installation records. What happens in the end is that you apply configurations to a site - that can be as many as you want with extension profiles. I just don't see a way on how to move forward with this without a clear cut. Now, I tested with eXtremeManagement 1.5.2, the latest stable release, in case anyone wants to try it out (remember to add a Poi 1.1 bundle too). That release also has Extensions/(App)Install.py files. I moved those out of the way and restarted. Why did you remove Extensions/Install.py? This one is supposed to take precedence over extensions profiles. In your case having one, which installs the GS profile you want internally should work just fine. Question 2: I am used to having a profiles directory in a product and a subdirectory inside it named 'default'. eXtremeManagement is the only product I know that has a second profile next to it. Are others using more than one profile? Well, CMFPlone does a few things here. Multiple profiles are common. I think I made the profiles/default thingy the default value, when you don't provide one in ZCML, but that's all the magic there is and should be. Question 3: Should we encourage programmers to only use one profile, presumably simply in a directory named 'profile' by default? No. :) In the case of eXtremeManagement, the day is saved because it still has an Extensions/Install.py. That is the installer that is actually executed and it has some code to run the correct profile, including a dependency. The only hickup so far is that with the newer QI the name of the other profile is listed instead of the default profile. That is a bug. I think someone added this code of taking the title from the profile, shortly before the final and I missed to review it properly. We should just revert those changes. If you have an Extensions/Install.py nothing should be read from the profile database. Can you add a ticket for this last issue? Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF Tests: 8 OK, 1 Unknown
Hi. CMF Tests Summarizer wrote: Unknown --- Subject: UNKNOWN : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Tests Date: Sat Apr 26 21:58:24 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-April/008623.html I fixed the test failure, which was introduced by me removing deprecated code from Zope trunk. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] GenericSetup and CMF dependencies
yuppie wrote: Wichert Akkerman wrote: Previously yuppie wrote: Until recently, the Products themselves didn't use setuptools. Revision 85287 (http://svn.zope.org/?rev=85287&view=rev) changed that. It is no longer possible to run CMF without setuptools installed. For those of you who didn't read the changeset, I used the version number parsing code from setuptools in order to sort the versions inside the upgrade machinery. I didn't want to duplicate the code to parse all those cryptic version numbers like '3.1-rc1-dev-r42' and sort them correctly. My reasoning for reusing the setuptools functions was, that we seem to use them for package versions as well since some time and they seem to be a reasonable standard. Considering that entire python community appears to be moving to egg, Zope2 is going to be distributed in egg form (at least there is a strong move in that direction) I think a dependency on setuptools is not problematic. I guess CMF 2.2 will be released before Zope2 or Python requires setuptools, so at least for now it is a GenericSetup/CMF dependency. http://svn.zope.org/CMF/trunk/ still exists and needs to be maintained (or deleted). Who ever added the setuptools dependency should update INSTALL.txt and friends (if we agree to keep CMF trunk and the dependency). I don't have a strong opinion on CMF/trunk. I don't use it, so I don't have a particular interest in keeping it around. For me the dependencies noted in setup.py are the canonical place and I would delete the DEPENDENCIES.txt files from all packages on trunk and instead make sure the ones in setup.py are current. If we can agree on that, I can do the work and make sure INSTALL.txt is current as well. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: GenericSetup 1.4 release
Jens Vagelpohl wrote: There's an egg with version 0.3 on the cheeseshop, is that an acceptable version? I simply linked in what I had here from the current CMFCore trunk, but that external is against the five.localsitemanager trunk and the package itself contains no version information whatsoever (documentation foul!). The CMF 2.1 branch uses the five.lsm 0.3 tag, which is identical to the trunk, except that trunk states it is going to be version 0.4. On PyPi there are both an egg as well as a source distribution for the 0.3 release. The CMF trunk currently points to the five.lsm trunk, which doesn't have a version information inside it, as it only uses a part of the actual package. The version information is in the root setup.py, whereas CMF only pulls in the src/five/localsitemanager part of it. Why did we do the above at all? Because we didn't want to require anyone to install a package for the CMF 2.1 line on top of extracting the tarball into the Products folder. For CMF trunk I personally think it is OK, to state a proper dependency in setup.py for both CMF and GenericSetup now and remove the five.lsm inclusion hack from CMFCore. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] launchpad bug tracker - full details in bug reports
For those of you not reading the launchpad-users mailing list, there has been an update which introduces a new option: * You now have the option of receiving the full original bug report in all bug notification emails. Visit https://launchpad.net/name>/+edit then check the "Include bug descriptions when sending me bug notifications" box. (Bug 158668) This has been on the wishlist of some people IIRC. In my case the option was found under 'https://launchpad.net/~schlichting/+edit' or behind 'Change details' after clicking on my user name in the top right corner. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Decode for Record objects
Charlie Clark wrote: If I have non-ASCII data in an RDBMS that I wish to use in a CMF site or even straight ZPT's you get a UnicodeError when accessing the non-ASCII Values which you get around using the decode utility. ZPT uses Unicode internally in Zope 2.10 and newer, so you need to decode your non-unicode values before passing them into a Page Template. Plone hacks the TAL engine in horrible ways so you can still use utf-8 encoded strings as well, but I wouldn't recommend this approach for a small application. However, I think the error is raised because utils.decode simply returns any values untouched it doesn't know what to do with which is why I think it might be worth extending. OTOH it might something that is better fixed in the Shared.RDBMS.Results module The database connection layer is the I/O boundary in this case and the decoding to Unicode should happen here. Pretty much all code in Zope2's SQL or database layers doesn't do this and I haven't seen much interest from anyone to fix this. I'd highly recommend using one of the approaches based on sqlalchemy, as otherwise you'll probably end up fixing a number of bugs and adding missing features to the various products responsible for Zope2's current DB interconnection features. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Eggified CMF - was Re: CMF 2.1.1 release
Tres Seaver wrote:
> Jens Vagelpohl wrote:
>> On Dec 29, 2007, at 18:28 , Hanno Schlichting wrote:
>>> For the small number of CMF parts I'm +1 for individual eggs.
I understood both comments as positive votes and have done the dirty
work of moving CMF trunk into separate parts now. I haven't moved the
2.1 branches yet as it was done for CMFCore.
>> I like your argument where we could use this as an opportunity to move
>> packages like CMFUid out of the bundle/egg/tarball/whatever that
>> people get when they get the CMF. I wouldn't mind having a division
>> where you have...
>
>> - CMFCore (the foundation which may be used by itself to develop
>> other kinds of portal software)
>
>> - CMFDefault + DCWorkflow + (maybe) CMFTopic (a "finished" sample
>> for a CMFCore-based portal software bundle)
>
>> - CMFUid (optional add-on)
>
>> - CMFCalendar (optional add-on)
>
>> - CMFActionIcons (optional add-on)
I haven't updated the install_requires of the individual eggs yet. But
if you for example "easy_install CMFCalendar" you should get a working
system including its depdendencies which probably includes the rest of
CMF as well. The same goes for the other options, so installing
CMFDefault will pull in DCWorkflow and CMFTopic will probably include
both CMFDefault and DCWorkflow. Careful dependency analysis is needed
here, though.
> If we go ahead and break each product out into its own egg, we can
> create one or more "meta eggs" which stitch them back together. E.g.,
> the meta egg could have:
>
> install_requires=['Products.GenericSetup',
> 'Products.CMFCore'
> 'Products.CMFDefault',
> 'Products.CMFTopic',
> 'Products.DWorkflow',
>],
> extras_require={'uid': ['Products.CMFUid'],
> 'calendar': ['Products.CMFCalendar'],
> 'actionicons': ['Products.CMFActionIcons'],
> 'kitchensink': ['Products.CMFUid',
> 'Products.CMFCalendar',
> 'Products.CMFActionIcons',
> ],
> }
Sounds good - except for the kitchensink name ;)
Hanno
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 2.1.1 release
Jens Vagelpohl wrote: > By the way, since Products.CMFCore already appears ready to be published > as an egg, is there anything missing before putting it into the index? Not that I know of. What's the status of moving all the other parts into separate projects / folders? FWIW there hasn't been a final vote on the one-meta-egg vs. individual eggs question. For the small number of CMF parts I'm +1 for individual eggs. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 2.1.1 release
Tres Seaver wrote: > I've now added Jens as 'Owner' on GS, PAS, and PR. I added Jens and Tres as Owners to five.lsm as well. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 2.1.1 release
Jens Vagelpohl wrote: > On Dec 29, 2007, at 14:05 , Hanno Schlichting wrote: >> The maintainer role can only manage releases and files, while the Owner >> can add new users or delete the whole package from the cheese shop. >> >> For GenericSetup Tres should probably add at least you as a second >> Owner. He needs your Cheese Shop login name for that. Permission >> handling is done through the web interface only. > > Interesting, I'll talk to Tres then. The few bits of documentation that > I saw linked from the cheese shop did not mention this at all. Is there > better documentation out there? If you find any, please let me know ;) The roles are explained directly in the admin interface, the rest is 'lessons-learned' by using the Cheese Shop for a rather long time now. I would suggest to define a list of people to add as owners for both GenericSetup and yet-to-be-added Products.CMF* probably consisting of Jens, Tres and Yvo? If I can get the login names of those, I'll add them to five.localsitemanager as well. This is mostly just for emergency handling and making sure we don't depend on a single person should the need for an urgent release arise. Hanno P.S. The full test of the role administration page is: Role maintenance Use this form to add or remove a user's Role for a Package. The available Roles are defined as: Owner Owns a package name, may assign Maintainer Role for that name. The first user to register information about a package is deemed Owner of the package name. The Admin user may change this if necessary. May submit updates for the package name. Maintainer Can submit and update info for a particular package name. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 2.1.1 release
Jens Vagelpohl wrote: > By the way, I have attempted to upload the new GS 1.3.3 to the cheese > shop, but even though I have a login it told me I am not allowed to do > so. This is the first time I am uploading anything, and looking through > the scant documentation linked from the scheese shop pages I couldn't > find any help. > > Who knows why I am getting a 403 error message and how can I get around > it? I tried to execute the following in the toplevel > Products.GenericSetup folder, where the setup.py file is: > > /path/to/python setup.py register You get that because you are not authorized ;) Looking at the page it says: Package Index Owner: tseaver So right now only Tres is allowed to upload or change that package. The Cheese Shop has a simple permission model with an Owner and Maintainer role and only knows about people and not groups. The maintainer role can only manage releases and files, while the Owner can add new users or delete the whole package from the cheese shop. For GenericSetup Tres should probably add at least you as a second Owner. He needs your Cheese Shop login name for that. Permission handling is done through the web interface only. For most packages I uploaded to the cheese shop I have given a couple of people usually directly an Owner role. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 2.1.1 release
Jens Vagelpohl wrote: > The CMF 2.1 branch has seen enough fixes since CMF 2.1.0 to make a > meaningful bugfix release. If there are no objections I would cut CMF > 2.1.1-beta tomorrow (Friday 12/28) and a final a week later. I'm out of > town from tomorrow night until 1/1, that's why I would have to do the > beta either tomorrow or after 1/1. > > The CMF-2.1-branch is currently using the GS 1.3.2 tag, I propose to > move that up to the tip of the GS 1.3 branch today, and then tagging GS > 1.3.3 alongside CMF 2.1.1 final and pinning them together that way. +1 Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] GenericSetup: using global steps
yuppie wrote: > GenericSetup trunk has global step registries. I propose to use the new > ZCML directive for registering all GenericSetup and CMF import and > export steps globally. And to remove the import_steps.xml and > export_steps.xml files from the profiles shipped with CMF. > > This also requires to add a flag file for the 'various' step. > > I already started implementing this. If there are no objections, I'll > soon check in my changes. +1 Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Buildout recipe for CMF?
Andreas Jung wrote:
> is there a buildout recipe that can unpack the CMF source archive properly?
> The problem is basically that the top-level folder contains the products
> as subdirectories. So the product dirs must be moved or linked.
Sidnei already mentioned my recipe, but as I never found the time to
document it, a simple example on how to use it might help. There is also
another option called 'version-suffix-packages' used in the same way as
'nested-packages' which takes a whitespace separated list of names as
well. This one is able to handle a PAS release tarball.
Hanno
Sample buildout.cfg:
[buildout]
parts =
zope2
cmf
instance
[zope2]
recipe = plone.recipe.zope2install
url = http://www.zope.org/Products/Zope/2.10.5/Zope-2.10.5-final.tgz
[cmf]
recipe = plone.recipe.distros
urls = http://www.zope.org/Products/CMF/CMF-2.1.0/CMF-2.1.0.tar.gz
nested-packages = CMF-2.1.0.tar.gz
[instance]
recipe = plone.recipe.zope2instance
zope2-location = ${zope2:location}
user = admin:admin
products =
${cmf:location}
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: eggification status?
Philipp von Weitershausen wrote: > yuppie wrote: >> Wichert Akkerman wrote: >>> A related question is: how do we want to eggify CMF? It seems to make >>> sense to create one egg for the whole of CMF and a second egg for >>> GenericSetup. >> >> Why not one egg for each CMF product? Can you please elaborate? > > *Why* one egg for each product? We'll just end up with the same egg > madness that we have with Zope 3 (e.g. zope.app could've just as well > stayed one big egg, IMO). It's not like the different parts of the CMF > need to move at separate speeds... The different parts don't need to move at different speed, but I would see separate eggs as an option to drop some parts out of the bundle again, which don't see any development at all. For example CMFUid has never quite been expected as a first class citizen of CMF, so having a separate egg for it, would allow us to not use or develop it anymore, when there's really no one interested in it. After all we are only talking about 8 eggs here and not a gazillion of them like Zope 3 has. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Move CMF collector to Launchpad (redux)
Jens Vagelpohl wrote: > Now that the Zope and Zope3 collectors have been migrated successfully > onto Launchpad, and there seems to be a good routine in place to > preserve history and ensure automatic redirects, I wanted to bring up > the question again. Should we move the CMF collector to Launchpad? > > I personally had one remaining issue, namely the fact that my main > browser (OmniWeb) could not display Launchpad at all due to a CSS bug in > OW itself. All that has been fixed, and the Launchpad team has been very > cooperative and responsive. So my own vote at this point is +1: > > Can we have a show of hands, so to speak? +1 Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Eggification redux
Tres Seaver wrote:
> SVN Reorganiztion
> -
>
> I just worked a bit today on spliting CMF 2.1.0 (GenericSetup 1.3.2) out
> into separately releasable egg-based distributions. For the initial
> pass, see:
>
> svn://svn.zope.org/repos/main/Products.GenericSetup/tags/1.3.2
>
> Note that the SVN URL above is not the same as the one we've been using
> (svn://svn.zope.org/repos/main/GenericSetup) and that it adds the
> additional "namespace" package ('Products') to the checkout.I plan
> to fix up the externals currenly pointing into '/GenericSetup' in the
> CMF trunk and 2.1 branch, and then make '/GenericSetup' empty, with a
> pointer to the new location.
>
> Egg Releases
>
>
> I uploaded the Products.GenericSetup 1.3.2 egg to the Cheeseshop:
>
> http://pypi.python.org/pypi/Products.GenericSetup
>
> The egg should be 'easy_installable' in any environment with setuptools
> installed; if that environment has a properly-namespaced 'Products'
> package (Zope2 trunk, or with the backport I'm proposing for Zope issue
> #2359), it should Just Work.
>
> Further Work
>
>
> I'd like to break the remaining CMF packages out (moving from '/CMF' to
> 'Products.CMFCore', 'Products.CMFDefault', etc.) and push the 2.1.0 eggs
> out, as well as equivalent changes for PluggableAuthService and
> PluginRegistry.
>
> Any objections, or other thoughts?
Big +1 :)
Hanno
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF collector on Launchpad?
Jens Vagelpohl wrote: > Andreas Jung is in the process of getting the regular Zope 2 issue > collector moved onto Launchpad. He said the Launchpad guys could move > other collectors like the CMF collector at the same time. The question > is, do we want this? > > My vote is "-0.5", mostly because I never used Launchpad. One drawback > that was mentioned is the fact that bugtracker emails do not contain the > full bug history. From other bugtracker experience I know that's very > annoying. > > Andreas mentioned some arguments for the move, like having the same user > base on all those collectors, the ability to move bugs between them, and > a much better user interface than the sometimes odd collector UI. > > What's the consensus? I'm +0.5 on moving away from anything on zope.org. I find the collector UI and speed suboptimal to work with. Launchpad provides a reasonable good bug tracker from my experience (I mostly reported bugs against the launchpad translation system itself in the past ;)). Personally I find trac a lot more efficient to work with, though. But it's UI is definitely geared towards developers (which is in the end the prime target group for CMF). I'll dare to speak out the unthinkable and as an alternative option suggest to move the CMF bug tracker to a trac instance hosted on plone.org. A common user database between the Plone and CMF bug trackers is a bigger benefit than the common user base between CMF and Zope I think. But maybe our two communities still don't overlap enough for that idea to work out ;) Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: GenericSetup extension profile import step mis-feature
Tres Seaver wrote: > Martin Aspeli wrote: > >> Tres Seaver wrote: >>> 'importVarious' is a brutal hack: better to focus efforts on making it >>> disappear. The entire point of the tool is to externalize configuration >>> as declarative data in the profile; accomodating imperative >>> configuration is not something I care to support. >> I think that's a bit puritanical. Sometimes it's just not possible to have >> declarative configuration for anything, either for time or complexity >> reasons. There will be setup tasks that can only feasibly be achieved in an >> imperative way, and need to run during the installation of a product. > > My point is that imperative configuration creates a logically-insoluble > rats-nest: Goedel's Law comes into play, because imperative stuff > induces ordering dependencies, which are irrelevant for purely > declarative stuff. > > Plone's 'importVarious' was supposed to be a "temporary" hack when Rob > added it almost two years ago; it should *still* die. In the meantime, > it is the responsibility of the perpetrator to obey the Hippocratic > maxim, "first do no harm." Just as a side note, Plone itself (not counting the ones from its dependencies) currently has five different interdependent import various handlers. One is enabling the portal as a Zope3 site, two are quickinstalling products based on extension profiles (which are again dependent on each other), one is doing some configuration that really should be in xml files and one is installing content. The content creation as well as some site settings are dependent on the current browser language. All this works reasonable well right now and while I don't like all of it, I think realistically we need to have some sensible support for imperative import handlers for some time in the future. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Plone needs a release this week
yuppie wrote: > Jens Vagelpohl wrote: >> On 20 Jul 2007, at 11:00, Wichert Akkerman wrote: >>> Previously Jens Vagelpohl wrote: Next step: What needs fixing for the final? >>> >>> There has been a surprising lack of response to this question. Since I >>> need a CMF 2.1-final for Plone in a few weeks that could be very >>> positive news for me but I have a suspicion that some of you have some >>> outstanding issues. Or is there really nothing that needs to be done >>> before going final? >> >> If no one objects I will cut a CMF 2.1.0-final the weekend of August 5. > > I finally found some time to have a closer look at the latest code. > > AFAICS the premature GenericSetup 1.3 release has the biggest issues: > > - The exports created by the new components handler are still flawed, > ISiteRoot and placeless components are not exported correctly. > > - There are also some usability issues (strange ordering; strange > interface names including '_tools' and '_content'; no support for > sub-sites; more attributes than necessary are required; no support for > removing items), but they might not be release blockers. > > I sent hannosch more detailed information, but if he can't work on these > issues this week, someone else has to resolve them. I'm on a sprint in France this week, which I need to concentrate on (because it hopefully produces some results for my Google Summer of Code project), so I won't have time to work on these issues in this week and I doubt to have much time next week as well. Sorry, Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: GenericSetup extension profile import step mis-feature
Martin Aspeli wrote: > Hi guys, > > After a lot of "is-this-a-bug" type discussions with Rob and Wichert, > I've come to feel pretty strongly about the following: > > When you load an extension profile for the first time in GS, it looks to > see if it has any import steps (in import_steps.xml) that are not > already "known". If so, it adds them to the import step registry and > then runs all steps in the registry. > > Any time a profile (the same, or another one) is run subsequently, that > import step will be run too. In Rob's words, the import steps and the > profile that they came from (import_steps.xml-wise) get decoupled. > > We normally don't mind too much, because steps are run in the context of > a particular profile, and if that context has no matching XML file, > nothing is loaded. At least so we assume - there's of course nothing to > stop the setuphandler from having side effects even if the XML file is > not found. We *do* see a problem with importVarious-type hacks, though. > Here, people resort to checking for a "flag" (normally an empty text > file) to determine if the setuphandler should be run. > > I believe this is fundamentally Bad(tm) for three reasons: > > - People don't expect it to work that way. > - Authors of setuphandlers have to be a lot more careful about having > side effects on entirely alien packages. > - It's impossible to predict which steps actually get run for an > extension profile. > > Say, for example, that I wrote extension profile Y and I wanted to use > an import handler used in extension profile X. If X had been run (or in > fact, looked at under the Import tab, the registry filling happens as > soon as you look at a profile there, even without running it) at least > once, then it would get attempted for Y as well. If the appropriate XML > or flag file was found it'd be run. > > But there is no way for Y to know that X was run (or looked at). In > fact, it may be that users of Y do not want X to be loaded at all. > > The only predictable way for Y's author to run said import step is to > explicitly list a setuphandler from X's package in Y's own > import_steps.xml. > > I cannot see a good use case for the current behaviour, and it causes a > lot of confusion (either "why was this step run again?" or "why wasn't > this step run?"). Having to have flag files for pure-python > setuphandlers is also pretty hacky (even if such handlers themselves are > a bit hacky, but sometimes unavoidable). One example where the current behavior makes sense is when you write an add-on product which wants to install itself into a standard Plone site and change the settings of the Archetypes tool. The import handler for the Archetypes tool is only specified in the extension profile for Archetypes and not in the Plone base profile. It is however always installed into a Plone site via an import various step. I think this kind of decoupling the different profiles into the packages they came from is a sensible idea. In order for that to work reliable we need to have some profile dependency support, though. When we would have that I would extend your idea in the following way: > The only sane behaviour, IMHO, is this: > > - When importing a base profile, only steps from the base profile are run. > > - When importing an extension profile, only steps from the *current* > base profile and any additional steps explicitly defined in the > *selected* extension profile (via an import_steps.xml file) are run. In both cases all the steps from any (recursively) defined dependencies are run as well. So the Plone Base profile would depend on the Archetypes extension profile (as well as the other half a dozen we install manually right now) and you could always assume the Archetypes tool import step to be present. For an add-on X it can decide to depend on Y and thus re-use all of their import steps as well, without having to specify the handler itself. > No steps are ever implicitly pulled in from other extension profiles, > and switching base profiles resets the base set of steps that are run > for any extension profile. > > Another solution (better than the current behaviour, less good imho than > the solution above) would be to load all steps from all profiles at Zope > startup, when the profile registry is populated, so that all steps are > always run if a package registering a new step is installed. This still > means having lots of flag/file-checking and could be quite inefficient. This is really bad. That way if there is some experimental profile registered somewhere it would get loaded automatically. So as soon as I have one broken import step somewhere I would have no chance to exclude it. The registration of an import step should still be an explicit task. > What do you think? Is there a sane use case for the current behaviour? Apart from the decoupled but guaranteed-to-be-there extension profiles I cannot think of any. Hanno _
[Zope-CMF] Re: Plone needs a release this week
Wichert Akkerman wrote: > Previously Jens Vagelpohl wrote: >> Next step: What needs fixing for the final? > > There has been a surprising lack of response to this question. Since I > need a CMF 2.1-final for Plone in a few weeks that could be very > positive news for me but I have a suspicion that some of you have some > outstanding issues. Or is there really nothing that needs to be done > before going final? I just fixed the last long-standing issues with the componentregistry handler, which has been the last item on my list. So we are good to go from my side :) Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: fixed issues
Wichert Akkerman wrote: > Can someone close issues 489 and 473? Both of them are fixed now, but I > don't have permission to mark them as closed. Done :) ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Possible beta/rc ?
Jens Vagelpohl wrote: > > On 3 Jul 2007, at 10:10, Wichert Akkerman wrote: > >> Now that the utility vs tool work seems to be settling down and we are >> running Plone without any monkeypatches I want to get Plone 3.0-rc1 >> out the door start of next week. For that to happen I am going to need >> a new CMF release as well. Are there any showstoppers to prevent that >> from happening? If not, Jens, are you able to cut a release this weekend? > > I'll be very happy to do it, I was just waiting for one last thing: Rob > Miller merged the BBQ sprint work into the GenericSetup trunk, but then > there was a discussion that petered ot. This is where it started: > > http://mail.zope.org/pipermail/zope-cmf/2007-June/026123.html > > The conclusion I saw was that a few things should be changed from the > current state and it wasn't clear to me whether I can go ahead and cut a > GS 1.5 release and create a GS 1.5 branch at this point. > > So my question to the parties involved: Can we go ahead and cut a GS 1.5 > release with the current GS trunk? As long as you don't call it a final release but only a rc1 or beta, it's fine with me. I need to fix some things in the components handler before we can call it a final, but should be able to fix those in the next two weeks. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] five.localsitemanager: proposal
Hi. I meanwhile managed to fix the issue that prevented all tests from running and now the Plone 3.0 bundles use the head revision of the CMF 2.1 branch and five.lsm trunk again. I have started to fix all the problems that have shown up now. We have some custom tools for which I needed to remove the utility registrations as those depended on self.REQUEST. yuppie wrote: > Wichert Akkerman wrote: >> Previously yuppie wrote: >>> >>> MembershipTool depends on acl_users >>> >>> MemberDataTool, RegistrationTool, DiscussionTool and >>> CachingPolicyManager depend on MembershipTool >From what I can see in the Plone tests it won't be possible in any sane way to let the user related tools to be utilities. At least for CMF 2.1 I think an approach trying to distinguish between safe and unsafe methods is too risky and we should move those back to pure tools. > So far I tried to decide which tool depends on self.REQUEST and which > not. Maybe we need a more fine grained approach: > > MembershipTool doesn't depend on all methods of acl_users, not all user > folder methods depend on self.REQUEST. IStandardUserFolder has not all > the methods, but an interface that adds _doAddUser(), getUserById() > and userFolderDelUsers() should be sufficient. Maybe that set of methods > specified by a user folder utility interface doesn't depend on > self.REQUEST. > > If that doesn't work, we can try the same with the MembershipTool: If > not all methods of IMembershipTool work without self.REQUEST, we still > can use a subset IMembershipUtility. I would suggest we try this approach on the CMF trunk but revert to tools-only for those tools for CMF 2.1. > I'm optimistic these issues can be resolved one way or the other. But I > don't want to spend more time on this before five.localsitemanager is > better tested. I hope the current state of the CMF 2.1 branch is > sufficient for testing five.localsitemanager with Plone and KSS. Real world testing showed dozens of test failures and an almost unusable live instance. I have meanwhile managed to fix quite a bunch of issues so we you can at least create and view a Plone instance again, but the number of failures showing up on the console due to missing REQUEST variables in various tools prevents us from doing anything useful. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] five.localsitemanager: proposal
yuppie wrote: > Hi Hanno! > > Hanno Schlichting wrote: >> Starting any Plone tests will give an AttributeError on self.adapters in >> the subscribers method of zope.component.registry. >> >> The registry is actually the one from five.lsm and is found via the >> zope.app.component.hooks.SiteInfo container. In there it is available as >> the sm property, but it indeed at that point lacks the adapters >> attribute. It looks like _init_registries is never called. But when I >> overwrite the set method on SiteInfo every time a new sm is set, it has >> the right adapters. > > Strange. five.lsm is just messing around with 'utilities', not with > 'adapters'. 'adapters' should work exactly the same way as in a pure z3 > site manager. > > Can't see how the latest five.lsm changes could cause that problem. Me neither :( But as said the sitemanager I get back, though it is the one from five.lsm, has neither an adapters nor utilities or name set. >> I didn't have time to test this properly but maybe this gives somebody >> else an idea who wants to look at it... > > What's your testing environment? > > https://svn.plone.org/svn/plone/bundles/3.0/EXTERNALS.txt > uses r76995 of CMF and > https://svn.plone.org/svn/plone/bundles/3.0-lib/five/EXTERNALS.txt > uses five.localsitemanager/trunk I use https://svn.plone.org/svn/plone/ploneout/trunk and updated CMF to the HEAD revision. Which is pretty much identical to the above bundles. > I expect you can get Plone running with CMF 2.1 branch HEAD and the old > five.lsm, but not with the five.lsm trunk and r76995 of CMF. Haven't actually tried that. Good point. > Are you using a KSS version without monkey patch? I tried with both with and without the KSS monkey but it doesn't seem to have any effect. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] five.localsitemanager: proposal
Hanno Schlichting wrote: >>> ToDo: >>> - >>> >>> - real world testing > > My testing of Plone 3.0 after the merge so far results in all > integration tests failing with that stupid error inside the component > registry when it throws an AttributeError on 'adapters'. The error > happened a few times already, but I'm too tired to figure out right now > why it is failing this time. I looked a bit deeper into this and still cannot figure out what exactly is going wrong. Starting any Plone tests will give an AttributeError on self.adapters in the subscribers method of zope.component.registry. The registry is actually the one from five.lsm and is found via the zope.app.component.hooks.SiteInfo container. In there it is available as the sm property, but it indeed at that point lacks the adapters attribute. It looks like _init_registries is never called. But when I overwrite the set method on SiteInfo every time a new sm is set, it has the right adapters. Now the event that is fired is the EndRequestEvent during the late steps of PloneTestCase's SiteSetup. What I suspect is that the five.lsm is already partially removed at the point the event is fired and thus does not have an adapters argument anymore. But my knowledge of the actual inner workings of the ZODB transaction machinery is very limited. The code in PloneTestCase.setup.SiteSetup looks like this: def run(self): self.app = self._app() try: [... does the setup ...] finally: self._abort() self._close() self._logout() self._placefulTearDown() The event is fired during self._close() and self._abort essentially does transaction.abort(). I didn't have time to test this properly but maybe this gives somebody else an idea who wants to look at it... Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] five.localsitemanager: proposal
Godefroid Chapelle wrote: > yuppie wrote: > > > >> AFAICS, KSS will no longer need the monkey patch if it sets the >> LookupClass to FiveVerifyingAdapterLookup. >> > I tried to test your code this evening... > > This implied starting to fix Archetypes and Plone to work with all the > changes made in CFMCore.interfaces I backported all the changes and adjusted it accordingly, so you can test the code against Plone without adjusting Plone to CMF trunk. Beware that there still seem to be some general issues. As noted on the other mail, all integration tests currently fail :( But help in fixing those is most welcome ;) Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] five.localsitemanager: proposal
Hi. Martin Aspeli wrote: > Hi Yuppie, > >> This proposal is now implemented on CMF and five.localsitemanager >> trunk. Everything *seems* to work, but maybe I'm missing something. >> This might be a good time to review and test the changes - any >> feedback is welcome. > > Well done - great work! :) > >> Done: >> - >> >> There are 10 tools in CMF that are not ready for being used as >> utilities, they have to be used the old way until they are fixed: >> >> content_type_registry >> cookie_authentication >> portal_actions >> portal_calendar >> portal_catalog >> portal_skins >> portal_types >> portal_uidhandler >> portal_url >> portal_workflow > > Are these registered as utilities as all? Or only available using > getToolByName? They are not utilities, so they are not registered as ones. Only available through good old getToolByName :) >> ToDo: >> - >> >> - real world testing My testing of Plone 3.0 after the merge so far results in all integration tests failing with that stupid error inside the component registry when it throws an AttributeError on 'adapters'. The error happened a few times already, but I'm too tired to figure out right now why it is failing this time. >> - backport to the CMF 2.1 branch > > Is this in the pipeline? i.e. will this code land in Plone 3.0? :-) I just did the backport. One test fails in pure CMF 2.1. I was so evil and commented it out. The test is in CMFCore/test/test_SkinsTool and is named test_getCurrentSkinName. I marked it with a XXX comment. Yvo could you look at it, I didn't quite understand all the skins related changes? >> - fix the GenericSetup handler > > How so? There's not only an open bug report in the CMF collector, but I also still have a mail in my inbox with all the changes we agreed on a while back... once the latest changes have proven to be stable, I'll get right to it. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: SVN: CMF/branches/2.1/C - changed the way skins are set up, using __before_publishing_traverse__ instead of __of__
yuppie wrote: > > Hanno Schlichting wrote: >> for some reason this change broken unit tests in all of the Plone >> packages, starting with Archetypes, ATContentTypes up to CMFPlone. It >> cannot find various skin methods and templates anymore. >> >> Do you have some idea what could cause this? I have seen you introduced >> a new __before_publishing_traverse__ method on PortalObject but as the >> PloneSite object is derived from the CMFDefault.CMFSite object and in >> return on PortalObject that method should be present on our site object >> as well. >> >> Any hints in which direction to look here? I have seen you changed the >> setup code in two tests as well, to setup the skin manually, is this >> something that is required now? > > Sorry. I hope this is just a testing issue. Or do you have similar > problems if you start up a Plone site? > > I guess most skin tests need now the manual skin setup. Only tests that > do the publishing traversal and trigger the setup in > __before_publishing_traverse__ don't need it. > > Please let me know if you think this checkin causes too much trouble and > should be reverted. If it is just a testing setup issue we can probably fix that quite easily in the PloneTestCase/CMFTestCase setup which most of our tests use. I'll try to look into this in the next few days unless somebody beats me to it. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] five.localsitemanager: proposal
Hi, yuppie wrote: > Yesterday I tried to do my homework from the CMF-mini-sprint in Potsdam. > I reread the tools-as-utilities discussion and had again a closer look > at the code. In Potsdam we decided to wrap persistent utilities with a > complete acquisition context. But now I think this would be a mistake, > so instead if implementing this I wrote a new proposal. > > A complete acquisition chain usually contains the REQUEST object. This > makes it impossible to cache wrapped utilities across request boundaries > and supports the usage of self.REQUEST - something that should not be > available in utilities. > > I believe using self.REQUEST in tools was never a good idea, tools that > can't be fixed should not be registered as utilities. I guess you are right. Having all tools registered as utilities turned out to be the false approach, but having those tools available as utilities that are really utilities still seems to be a good idea. The Acquisition wrapping makes sure those can actually be used in a Zope2 security context. > five.localsitemanager should remove the REQUEST object from the > acquisition chain before re-wrapping tools. AFAICS this makes the > wrapped tools no longer request specific, making it possible to cache them. [...] > Does that make sense? If there are no objections I'll move on in that > direction. This week I have some time to work on the implementation. +1 from me. As far as I can remember we had most of the code needed for that approach already working, so this should get as a solution in a not too distant future :) Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: SVN: CMF/branches/2.1/C - changed the way skins are set up, using __before_publishing_traverse__ instead of __of__
Hi, for some reason this change broken unit tests in all of the Plone packages, starting with Archetypes, ATContentTypes up to CMFPlone. It cannot find various skin methods and templates anymore. Do you have some idea what could cause this? I have seen you introduced a new __before_publishing_traverse__ method on PortalObject but as the PloneSite object is derived from the CMFDefault.CMFSite object and in return on PortalObject that method should be present on our site object as well. Any hints in which direction to look here? I have seen you changed the setup code in two tests as well, to setup the skin manually, is this something that is required now? Thx, Hanno Yvo Schubbe wrote: > Log message for revision 76729: > - changed the way skins are set up, using __before_publishing_traverse__ > instead of __of__ > > Changed: > U CMF/branches/2.1/CHANGES.txt > U CMF/branches/2.1/CMFCalendar/tests/test_Calendar.py > U CMF/branches/2.1/CMFCore/DynamicType.py > U CMF/branches/2.1/CMFCore/PortalObject.py > U CMF/branches/2.1/CMFCore/Skinnable.py > U CMF/branches/2.1/CMFCore/tests/test_SkinsTool.py > U CMF/branches/2.1/CMFDefault/tests/RegistrationTool.txt > > -=- > Modified: CMF/branches/2.1/CHANGES.txt > === > --- CMF/branches/2.1/CHANGES.txt 2007-06-17 13:35:02 UTC (rev 76728) > +++ CMF/branches/2.1/CHANGES.txt 2007-06-17 14:08:32 UTC (rev 76729) > @@ -11,6 +11,12 @@ > >Bug Fixes > > +- SkinnableObjectManager: Changed the way skins are set up. > + Acquisition wrapping no longer triggers 'setupCurrentSkin'. This is now > + done on publishing traversal after the BeforeTraverseEvent triggers > + 'setSite'. This fix replaces a temporary hack introduced in 2.1.0-beta, > + making sure ISkinsTool is looked up after setting the site. > + ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: getToolByName depreciation, getUtility, and five.lsm
Hi, I'll just offer one alternative solution for disussion, which could avoid reverting all the changes we made. Kapil Thangavelu wrote: > We believe that these recent changes have introduced implicit magic into > a standard Zope3 api to fit Zope2 acquisition. There should be an > explicit separate api if we want acquisition wrapped context-aware > utilities. As an example of a symptom caused by the implicit > implementation, KSS (which was developed as a pure zope 3 component) > breaks when used with Plone, even though it is a perfectly valid z3 > component. Once we return to using getToolByName for tool lookup, the > KSS/Plone3 issue disappears, because the magic wrapping of things stops. > This KSS/Plone3 issue arises because the five.lsm acquisition breaks > down when you add in non five.lsm component registries. If you need > Zope2 acquisition, you should use an accessor api to get things wrapped. I would say that all of Acquisition is dark implicit magic and something I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2 I also expect the need to make the Zope 3 code Acquisition aware. One prime example are browser views, which I need to mix in Acquisition in order for them to work. From my perspective the same could apply to site managers / component registries. As we already need to make a specialized subclass for local site managers to make them work in Zope 2 I think it would be another possibility to enforce the same for non-persistent site managers. This could lead us to a second package five.sitemanager that is aware of the same kind of Acquistion wrapping that five.lsm implies right now. The monkey patches we need right now could go away and KSS could do a conditional import of the site manager from zope.component or five.sitemanager if it is found. > In addition, getToolByName is the most fundamental and widely used api > in all of CMF, and we're going to be issuing hundreds of deprecating > warnings for every single cmf application extant. Yes, and I think in order to move forward and someday be able to remove tools from content space, not to mention not to enforce beginners to learn about yet another CMF-ism named tools, we need to be prepared to make some more intrusive changes sometimes. > As a solution, we propose > > * The five.localsitemanager code should *NOT* be dealing with > acquisition, it should be restricted to setting up a bases chain for > persistent components that does parent lookup. > > * getToolByName deprecation should be reverted. Its internal mechanisms > should be kept the same as in the current CMF 2.1 release, using > getUtility, *AND* it should be the one doing acquisition wrapping. > > So instead of doing implicit magic in the getUtility call stack, let's > be explicit, while still allowing the flexibility that registered > components provide. Which in turn results in an untouched zope3 > getUtility execution path for looking up utilities. > > getToolByName should return acquisition wrapped utilities via name > mapping, and become un-deprecated. Context for wrapping would be the > context passed as an argument to getToolByName, as it always has been. > It would issue deprecation warnings when it has to lookup a tool via > aq_get instead of getUtility. The mechanism for registering tool names > would raise an error when anyone tries to register a component which > does not support Acquisition. > > The getToolByInterfaceName method would no longer be necessary as > getToolByName can be called from restricted code. However if needed it > could remain and use the result of getSite() as the context for wrapping > the tool resulting from the utility lookup. In my alternative we would just need to add a little new package which is mostly a copy/paste job, change KSS to do an conditional import (so it still works in pure Zope 3) and document the change. Looking at Zope 2.11 we will potentially get Acquisition through __parent__ pointers which would allow us to make the implementation of five.sitemanger a lot saner and ultimately allow us to remove it again altogether. > We don't mean to belittle the hard work that anyone has put into this so > far, and we hope this is received in the spirit that it is intended. We > are willing to implement this if we can reach some consensus that this > is the right thing to do. All I'm interested in is a proper solution. Should that imply reverting lots of things I have done it would be unfortunate but obviously the right thing to do :) Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] GenericSetup and five.localsitemanager: managing tool registrations
Hi, yuppie wrote: > The tools-as-utilities changes seem to run fine, but so far there is no > easy way to manage the tool registrations in the local site manager. > > The site manager has no UI for inspecting or manipulating registrations, > so I tried to use GenericSetup: I think this is on the todo-list for five.localsitemanager. Adding support for a ++etc++site view or so, which works similar to the one in Zope3. > While importing settings seems to work without problems, the exports are > broken. Instead of the tool path (object attribute) the handler exports > the tool class (factory attribute). > > Trying to figure out how to fix this, I stumbled over several issues: > > Issue 1: > > Problem: Only setup handlers for Zope core objects should ship with > GenericSetup. The components handler was meant to be a handler for any > IComponentRegistry. But registering tool like objects doesn't really > work with the Zope core site manager. The tests are currently lying > about this. In fact this feature depends on five.localsitemanager. > > Solution: Hope that the dependencies are a temporary problem and Zope > 2.11 will ship with five.localsitemanager. Fix the handler to work with > five.localsitemanager and don't support the object attribute for other > site managers. I like solutions based on hope ;) Limiting support for the object attribute to IObjectManagerSites makes sense to me. > Issue 2: > > Problem: The code that supports the object attribute assumes that the > parent of the setup tool is the local site object linked to the site > manager. This violates the contract of the setup adapter and makes the > handler useless for sub-sites. > > Solution: five.localsitemanager is an ObjectManager, getSiteManager > returns the wrapped site manager. Get the site by acquisition, not from > the setup context. Sounds fine. > Issue 3: > > Problem: The export handler uses registeredUtilities(). Tools looked up > that way are not acquisition wrapped, object paths can't be found. > > Solution: Use getUtility() for each registered utility. The real issue here is that five.localsitemanager does not return wrapped utilities in all cases. This has been become apparent when you have a nested site manager which is not based on five.lsm. You get unwrapped utilities then in all cases. Onces this is fixed in five.lsm the export handler should work. > Issue 4: > > Problem: The re-wrapped tools returned by five.localsitemanager are > always wrapped in the site root. We don't know the actual path of the tool. > > Solution: Support only tools in the root of the local site (or > sub-site), no tools in normal subdirectories. OK, this means adding a bit of documentation and removing the half-baked support for registering tools in subfolders, right? > Issue 5: > > Problem: If modified as proposed, the handler still has problems > exporting the ISiteRoot utility. The exported object path is empty, but > import expects '/'. > > Solution: Support '' as well for import, deprecating '/'. Sounds fine. Should we deprecate the whole '/' in all cases then, as we only support registering objects in the same directory anyways? > I guess that's enough for now. I still have not figured out > http://mail.zope.org/pipermail/zope-cmf/2007-March/025739.html, so I > still might miss something important for resolving these issues. > > Writing this list doesn't mean I volunteer to fix these issues. Maybe > the people who contributed that code can fix it? I cannot promise to look at those things shortly, but should find some time once we have the Plone 3 beta out, which means probably in two weeks or so. Of course any help is most appreciated :) Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: PersistentComponents: wrapped or not?
Hi, yuppie wrote: > Apparently I'm missing something because this doesn't make much sense to > me: > > ComponentRegistryXMLAdapterTests use > z.c.persistentregistry.PersistentComponents. These tests register > wrapped tools, the registry returns them with their original wrapper. > > If I add transaction.commit(), I get a TypeError: "Can't pickle objects > in acquisition wrappers." > > This is what I'd expect. Me too. > But: > > Importing componentregistry.xml in CMF, wrapped tools are registered as > well. No error in that case, but unless re-wrapped by > five.localsitemanager's PersistentComponents, the registry returns > unwrapped tools. > > Any idea what's different in the second case? Why does registerUtility() > work in that case, removing the wrapper without raising an error? Actually I don't know why this works at all and I think it is a bug. We should probably add an aq_base to the registerUtility call in the handler to make sure we are not going to be screwed later on with some obscure bugs. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: tools-as-utilities, merging, releasing, etc
Hi, Jens Vagelpohl wrote: > My checkins today addressed at least the second change set you list by > making the site itself a utility and looking it up that way. The > additional wrapping is gone as well. I tested the branch again against the current Plone trunk and found no branch related problems, except one small glitch in our testing infrastructure which causes three tests to fail (it's missing the setSite() call somewhere). This can be easily fixed by us. I have already updated the current Plone trunk to set up a component registry based on five.localsitemanager and added the migration steps to register all the tools as utilities, as well as addding those to our base profile. So once the branch is merged at least Plone will work straight away. While my vote might not count much, I'd give a +1 to merging the branch and release a beta including it. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Tres Seaver wrote: > Martin Aspeli wrote: >> Jens Vagelpohl wrote: > >>> All those who think this is somehow impure and dirty, keep in mind >>> that this arrangement won't be forever, only for the 2.1 branch. >>> Afterwards there's more time to plan on packaging things differently. >> The only thing that worries me is that if we artificially inject it into >> Products.* and then want to move it, we'll have module aliases to >> contend with. > > Shouldn't need them, unless we are somehow createing persistent objects > from that package / product. I thought all that stuff happened at > runtime, with no persistence? The local registry we are already using is persistent, so will be the new registry, where the main difference is that the new one is smarter about handling nested local registries and Acquisition wrapped utilities. The current code looks something like this: from zope.component.globalregistry import base from zope.component.persistentregistry import PersistentComponents from Products.Five.component import enableSite from Products.Five.component.interfaces import IObjectManagerSite def enableSite(self, portal): enableSite(portal, iface=IObjectManagerSite) components = PersistentComponents() components.__bases__ = (base,) portal.setSiteManager(components) where setSiteManager is part of OFS.ObjectManager and defined as: def setSiteManager(self, components): self._components = components We wouldn't need a GenericSetup exportimport handler for the component registry when the information wouldn't be persistent. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [CMF 2.1] PersistentComponents is not enough
Rocky Burt wrote: > On Mon, 2007-08-01 at 15:40 +0100, Philipp von Weitershausen wrote: >> Since Five is feature-frozen and new stuff should be added in Python >> packages anyway, my suggestion is to put this thing into a >> five.localsitemanager package which would then be used by CMF 2.1, Plone >> 3, etc.. It could possibly be included into the Zope 2.11 release. > > If no one else has started this I'll probably pick up this work sometime > this week with the aim of at least having it included in Plone 3.0 /me cheers rocky!!! As Jens already pointed out having this advanced site manager is what is currently blocking the merge of the tools-as-utilities work. Sadly I have no time to digg into this myself but I hope my pointers in this thread in combination with Philipps comments should make it a both interesting and uncomplicated task ;) Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Martin Aspeli wrote: > Jens Vagelpohl wrote: >> >> Let's talk about something fun instead, like that wrapping issue. I >> personally can't see any problem with Hanno's suggestion for a >> "special" component registry and automatically wrapping those tools >> that are in the little registry. I'm just concerned that this >> registry is being abused a little - it really was only meant for >> getToolByName to construct a more meaningful deprecation message >> where the interface name is displayed, looked up from the tool ID. It >> seems Hanno's suggestion forces it to be kept around even after >> getToolByName has gone away in the distant future. > > Why not do it a more Zope3 ish way: > > class ICMFTool(Interface): >"""Marker for any CMF tool""" > > and then in the subclass of the local component registry: > > local_utility = > if ICMFTool.providedBy(local_utility): > local_utility = local_utility.__of__(context) > > or so. We could mix ICMFTool into the interface hierarchy for CMF's > tools, or declare it explicitly on each interface. We could even be more > specific, and call it IAcquisitionDependentTool and only use it where aq > is truly needed. That's of course a better idea. I would prefer the more general name IAcquisitionDependentUtility, as it might be used by code that's not a tool in the first place. There's nothing tool specific about the interface or its usage. All that the interface should promise is that the object providing it, can be AQ-wrapped. Right now I would let all existing CMF tools implement that interface, so we would be on the safe side. In a later release we can revisit this and see if some tools don't need Acquisition to work properly. If I'm not mistaken this should let us remove all the manual AQ-wrapping again (sorry Jens for the premature patch) and thus impose no extra pain on add-on developers. I'm starting to like this idea ;) Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Dieter Maurer wrote: > Martin Aspeli wrote at 2007-1-6 22:22 +: >> >> - Registering the portal as a utility that can be obtained by >> getUtility(IPortalRoot) is pretty good practice; in my estimation, that >> should solve all the use cases for utilities where acquisition is used >> now and where we're not really after an adapter, view. > > But the returned object is almost worthless, if it is not > acquistion wrapped (otherwise, it is not even able to determine its > 'getPhysicalPath' or 'absolute_url'). > > Thus, the proposal exhibits an essential example that local > utilities should be returned acquisition wrapped (if the have an '__of__' > method). Maybe a compromise would be to only return those utilities back acquisition wrapped that where registered as tools? Jens added a new function to CMFCore.utils called registerToolInterface that registers a tools name and the interface that tool implements in a global registry (a simple module level dict). The primary purpose is to let getToolByName look up known tools by interface instead of using Acquisition. While I'm not too proud of my persistent component registry proposed earlier in this thread it could be extended easily to only return those utilities back AQ-wrapped that are registered in the global tools registry. See my attached aq-components.py file for a sample implementation. Personally I think AQ-wrapping every utility is a bit too much as well. I've written a number of new utilities for Plone 3.0 that while having some persistent configuration don't need any Acquisition context. Magically wrapping those might indeed lead to unexpected behavior. Hanno from zope.component.persistentregistry import PersistentComponents from Acquisition import aq_parent, Explicit from Products.CMFCore.utils import _tool_interface_registry class Zope2PersistentComponents(Explicit, PersistentComponents): def queryUtility(self, provided, name=u'', default=None): utilities = super(Zope2PersistentComponents, self).queryUtility(provided, name=name, default=default) if utilities is not None: # Only wrap those utilities that are also cmf tools if provided in _tool_interface_registry.values() and \ getattr(utilities, '__of__', None) is not None: return utilities.__of__(aq_parent(self)) return utilities def getUtility(self, provided, name=u''): utility = super(Zope2PersistentComponents, self).getUtility(provided, name=name) # Only wrap those utilities that are also cmf tools if provided in _tool_interface_registry.values() and \ getattr(utility, '__of__', None) is not None: return utility.__of__(aq_parent(self)) return utility ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Hi Jens,
Jens Vagelpohl wrote:
> - I'll be happy to mark those places in the code where I had to
> manually wrap after a straight getUtility/queryUtility call so these
> places stand out as a reminder to do something about it.
I haven't marked those places yet, but attached you can find a patch
against the current CMFCore branch, that in combination with the small
change to DCWorkflow/Expressions.py noted earlier is needed to get most
of the tests for Plone running.
I still have one problem in the test case setup for functional tests,
where the portal isn't set as a site and thus the utility lookups don't
work, but as far as I can tell this is only a test case problem.
Hanno
Index: MembershipTool.py
===
--- MembershipTool.py (revision 71776)
+++ MembershipTool.py (working copy)
@@ -503,6 +503,7 @@
# Delete member data in portal_memberdata.
mdtool = queryUtility(IMemberDataTool)
if mdtool is not None:
+mdtool = mdtool.__of__(self)
for member_id in member_ids:
mdtool.deleteMemberData(member_id)
@@ -513,7 +514,7 @@
# Delete members' local roles.
if delete_localroles:
-utool = getUtility(IURLTool)
+utool = getUtility(IURLTool).__of__(self)
self.deleteLocalRoles( utool.getPortalObject(), member_ids,
reindex=1, recursive=1 )
Index: MemberDataTool.py
===
--- MemberDataTool.py (revision 71776)
+++ MemberDataTool.py (working copy)
@@ -184,7 +184,7 @@
def pruneMemberDataContents(self):
""" Delete data contents of all members not listet in acl_users.
"""
-membertool= getUtility(IMembershipTool)
+membertool= getUtility(IMembershipTool).__of__(self)
members = self._members
user_list = membertool.listMemberIds()
Index: RegistrationTool.py
===
--- RegistrationTool.py (revision 71776)
+++ RegistrationTool.py (working copy)
@@ -159,7 +159,7 @@
# Anyone is always allowed to grant the 'Member' role.
_limitGrantedRoles(roles, self, ('Member',))
-membership = getUtility(IMembershipTool)
+membership = getUtility(IMembershipTool).__of__(self)
membership.addMember(id, password, roles, domains, properties)
member = membership.getMemberById(id)
Index: URLTool.py
===
--- URLTool.py (revision 71776)
+++ URLTool.py (working copy)
@@ -24,6 +24,7 @@
from zope.interface import implements
from ActionProviderBase import ActionProviderBase
+from interfaces import ISiteRoot
from interfaces import IURLTool
from interfaces.portal_url import portal_url as z2IURLTool
from permissions import ManagePortal
@@ -74,7 +75,15 @@
def getPortalObject(self):
""" Get the portal object itself.
"""
-return aq_parent( aq_inner(self) )
+portal = aq_inner(self)
+while True:
+portal = getattr(portal, 'aq_parent', None)
+if portal is None:
+break
+if ISiteRoot.providedBy(portal):
+return portal
+# Portal could not be found, log an error or raise one?
+return aq_inner(self)
security.declarePublic('getRelativeContentPath')
def getRelativeContentPath(self, content):
Index: ActionInformation.py
===
--- ActionInformation.py(revision 71776)
+++ ActionInformation.py(working copy)
@@ -504,7 +504,7 @@
def __init__( self, tool, folder, object=None ):
self.portal = portal = aq_parent(aq_inner(tool))
-membership = getUtility(IMembershipTool)
+membership = getUtility(IMembershipTool).__of__(portal)
self.isAnonymous = membership.isAnonymousUser()
self.user_id = membership.getAuthenticatedMember().getId()
self.portal_url = portal.absolute_url()
Index: PortalFolder.py
===
--- PortalFolder.py (revision 71776)
+++ PortalFolder.py (working copy)
@@ -125,7 +125,7 @@
this folder.
"""
result = []
-portal_types = getUtility(ITypesTool)
+portal_types = getUtility(ITypesTool).__of__(self)
myType = portal_types.getTypeInfo(self)
if myType is not None:
Index: CMFCatalogAware.py
===
--- CMFCatalogAware.py (revision 71776)
+++ CMFCatalogAware.py (working copy)
@@ -118,6 +118,7 @@
if catalog is None:
return
path = '/'.join(self.getPhysicalPath())
+catalog = catalog.__of__(self)
# XXX if _getCatalogTool() is overriden w
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Jens Vagelpohl wrote: > > On 7 Jan 2007, at 14:26, Martin Aspeli wrote: > >> I didn't realise we would fully deprecate getToolByName() quite yet, >> though. I must admit I haven't been following your checkins, for lack >> of time (and since you're surely more qualified than me in this work >> in any case). > > The thread I pointed out clearly spells out the deprecation and the > DeprecationWarning. I'm somewhat surprised how DeprecationWarnings are > an issue. Clearly, in the past the Plone developer community hasn't been > too concerned about DeprecationWarning messages. I'm fine with deprecating getToolByName. This will spit out tons of deprecation warnings but those can be fixed (and I know I'm probably going to be the one doing most of that work for Plone core ;)) As a side note, I tried to bring Plone 3.0 into a state where it doesn't spit out deprecation warnings anymore and while I haven't been completely successful it has gotten a lot better than it used to be. >> However, surely, if we agree that it's premature to do so, commenting >> out the line that sends a DeprecationWarning won't be much of a change? > > I don't agree. I vote for keeping it in. There is no other obvious way > to alert developers of this change. Besides, that's _the_ way > deprecations have always been handled. Why should this one be different? This one is no different IMO. > Anyway, I propose the following: > > - the tool work to make them less dependent on acquisition is a good > idea, but it's out of scope for the part I volunteered for. Others are > welcome to step forward. Yep, I feared that ;) > - I'll continue with the work the way I have been doing it so far, > there's just a couple small tools left and invocations in Yvo's browser > view classes. > > - I'll be happy to mark those places in the code where I had to > manually wrap after a straight getUtility/queryUtility call so these > places stand out as a reminder to do something about it. OK, after all I think this approach is not that bad. My current testing of the CMF branches against Plone trunk shows only one major problem and about two minor places where we would need to adjust some code. The major problem is that the skin isn't set properly on the thread right now in the tests, so skin Acquisition magic doesn't work, which results in some hundred test failures for CMFPlone. > - *However*, I won't touch any more code until we have some consensus > here. > > Don't get me wrong, even if we come to a conclusion that spells "throw > away the branch" or "rewrite it all" I don't care, I just want some > final word and no more re-opening of discussions. Anything else is > analysis paralysis and a waste of time. OK, you get my +0.5 on moving forward. In the end this branch will bring us a big step forward towards Zope3 adaptation and all the benefits that result from it. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Philipp von Weitershausen wrote:
> On 6 Jan 2007, at 23:22 , Martin Aspeli wrote:
>
> Actually, why dont you keep a simple mapping between existing names and
> interfaces, e.g.:
>
> name2iface = {'portal_catalog': ICatalog,
> 'portal_skins': ISkinTool,
> ...}
>
> and use that in getToolByName? Then *all* of the existing code base
> continues to work, especially if getToolByName does aq wrapping.
> getToolByName('some.dotted.interface.IName') looks silly.
We already have that. It's called _tool_interface_registry and can be
found in CMFCore/utils.py ;)
This is used in getToolByName first and only if the name is not
registered it falls back to the old Acquisition-based approach.
Hanno
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Jens Vagelpohl wrote: > > Now, the main issue is still there, how to deal with tool wrapping when > calling getUtility/queryUtility in trusted code. Doing it every time > right after the call is stupid. I like Tres' hardline assertion that we > must have it wrapped every time, automatically. This needs to be > implemented somehow, maybe in Five as he suggests. > > How do we proceed? Personally I like Tres idea as well. I had one idea so far that achieves this without monkey-patching the functions in zope.component. The idea is to use a specialized persistent component registry, that does the needed AQ-wrapping. This will however only give us AQ-wrapped local utilities, whereas those registered with the global component registry wouldn't be wrapped. I think this might be an acceptable trade-off. Instead of creating a PersistentComponents registry in setuphandlers.py in CMFDefault (or CMFPlone) we could use the following one: from zope.component.persistentregistry import PersistentComponents from Acquisition import aq_parent, Explicit class Zope2PersistentComponents(Explicit, PersistentComponents): def queryUtility(self, provided, name=u'', default=None): utilities = super(Zope2PersistentComponents, self).queryUtility(provided, name=name, default=default) if utilities is not None: if getattr(utilities, '__of__', None) is not None: return utilities.__of__(aq_parent(self)) return utilities def getUtility(self, provided, name=u''): utility = super(Zope2PersistentComponents, self).getUtility(provided, name=name) if getattr(utility, '__of__', None) is not None: return utility.__of__(aq_parent(self)) return utility I'm not sure about all the implications this has, so treat it with care ;) Also we would probably need to overwrite all the other methods that return utilities like getUtilitiesFor, registeredUtilities, ... and we would need to make a decision about how to handle adapters or subscribers. Thoughts? Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Martin Aspeli wrote: > Hanno Schlichting wrote: > >> PhiliKON some time ago suggested that Five should wrap the utilities >> eventually but nobody followed up on that idea. > > Philipp also has some ideas (not too far off completion, I believe) that > may remove some of the acquisition intermingling. I'm not sure they'd > apply here. Yep, he worked on making the Zope 2 security policy aware of the ILocation interface as an alternative to the Acquisition hierarchy IIRC. This is targeted at Zope 2.11 though and last time I asked he still got segfaults ;) >> Ah yep, you are of course right. My main point was probably that it >> shouldn't rely on the request (unless passed in explicitly as a method >> argument). > > And sometimes we have methods that can legitimately take a 'context' > parameter. Quite often, this is because we were really after a view, > though. For example, most of PloneTool.py is a hodge-podge of random > things that were needed in page templates and Script (Python)'s but that > people wanted in filesystem code. That crap has to be refactored completely. The complete Plone tool has to be ripped apart and turned into nice utilities and views... Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Martin Aspeli wrote: > Hanno Schlichting wrote: > >> Yep, you are wrong ;) > > Fair enough. Out of curiosity, does the object have a __parent__? Nope, not ILocation aware :( > In any case, I think your original suggestion is a good one. Let's take > this opportunity to diagnose the problem and not the symptom: "True" > tools should be singletons and act much like utilities. Stuff like > self.REQUEST is pretty nasty. Maybe some tools will need some internal > cleanup in that respect; my feeling is that in most cases, that cleanup > should be reasonably easy, and where it's not perhaps we wait to put > those methods into the corresponding utility interfaces and think about > using adapters instead. The only question is who does this tool cleanup ;) > As Tres points out, you need aq context for security and in case > something is contained in the tool and needs proper containment > acquisition. portal_factory is such an example. I don't know if > portal_actions would be now as well; portal_types probably too. > > These are not really utilities, though, they are magic singleton > containers for specific things. Whereas a tool that is converted to a > utility may one day be deprecated out of content space, these ones may > not, I don't know. Hhm, ok. So do we expose these tools at utilities now at all? Can we really deprecate getToolByName then? > Also, getToolByName remains and is almost certainly the way forward for > all TTW code still, because it lets us aq wrap, it removes the need to > make all interfaces importable in untrusted code, and it can do any > additional security related things. In filesystem code, though, I think > the security aspect won't matter in most cases. Jens came up with a nice alternative here, which is getToolByInterfaceName. The docstrings reads: """Get a tool by its fully-qualified dotted interface path. This method replaces getToolByName for use in untrusted code. Trusted code should use zope.component.getUtility instead.""" Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Tres Seaver wrote: > Rocky Burt wrote: >> On Sat, 2007-06-01 at 16:32 +0100, Hanno Schlichting wrote: >>> Hhm, I'm not sure what the best way is here. Personally I would like to >>> get rid of as much of Acquisition as possible, but obviously we need to >>> be careful here. >> +10 here > > Fuggeddaboudit -- this is Zope2, and acquisition is still crucial (and > will remain so for the foreseeable future). Tools-qua-utilities *need* > wrapping in order for Zope2's security machinery to operate. If Five's > "local utility" bits don't arrange to wrap their own registered > utilities (not those gotten by "acquiring" from above), then we need to > change them to do so. Five doesn't do anything special for any utilities for Zope 2. It relies completely on the Zope 3 implementation, which of course doesn't know anything about Acquisition. PhiliKON some time ago suggested that Five should wrap the utilities eventually but nobody followed up on that idea. Personally I have no clue how Acquisition and security are intermingled in Zope 2, so cannot suggest any reasonable behavior here. >>> In the end a utility is defined as something that does not need a >>> context to do it's work. > > You are confusing "context" here -- the utility doesn't need to have an > "adapterish" context, but it *does* need to have "containment" context > -- that is why it is "local" in the first place. Ah yep, you are of course right. My main point was probably that it shouldn't rely on the request (unless passed in explicitly as a method argument). Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Martin Aspeli wrote: > Jens Vagelpohl wrote: > > My concern is just that we need a robust solution that doesn't put too > much onus on the end developer. If I have to do this it's pretty > horrendous: > > >>> mtool = getUtility(IMembershipTool) > >>> mtool = mtool.__of__(context) > >>> # now use mtool > > especially since the errors I get will likely be confusing. I have > learned the hard way that having to understand how acquisition interacts > with your code fully can be painful, and that sometimes the Zope2/Zope3 > divide still forces this on developers. In this case, we need to make it > as hard as possible to make mistakes, or the learning curve will just > shoot up again. > > In fact, I'm not quite sure I understand the full extent of the problem > here, which is why I'm not being more pro-active in offering suggestions. > > Now, I assume we still create the tool objects as > portal['portal_membership'] or whatever, i.e. they are still > SimpleItem's or whatever, so they still have acquisition mixed in. > Presumably, they should also have an aq_parent always, no? > > Then, I assume that on portal setup, we do > registerUtility(provides=IMembershipTool, > component=portal.portal_membership) - that is, we are telling the > persistent local utility registry that we are using the same physical > object (in the ZODB), rather than giving it a factory from which to > create its own object. > > This is what leads to believe there ought to be an aq_parent by > containment, but I guess I may be wrong? Yep, you are wrong ;) A sample session from my local zopectl debug: >>> from Products.CMFPlone.interfaces import ITranslationServiceTool >>> from zope.component import getUtility >>> getUtility(ITranslationServiceTool, context=app.test) >>> getUtility(ITranslationServiceTool, context=app.test).aq_parent Traceback (most recent call last): File "", line 1, in ? AttributeError: aq_parent >>> from Products.CMFCore.utils import getToolByName >>> getToolByName(app.test, 'translation_service') >>> getToolByName(app.test, 'translation_service').aq_chain [, , ] You currently don't get any Acquisition context for utilities if you don't wrap them explicitly: >>> getUtility(ITranslationServiceTool, context=app.test).__of__(app.test).aq_chain [, , ] Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Jens Vagelpohl wrote: > > On 6 Jan 2007, at 15:34, Hanno Schlichting wrote: >> I had to change two things in CMF so far though. Here are the patches I >> came up with: > > Thanks Hanno, this is a point I wanted to bring up after getting the > last work done: When using getUtility/queryUtility, I am assuming the > returned utility should always considered to be unwrapped. Because > that's what the unit tests show me. There are several places where CMF > unit tests failed and I ended up manually wrapping the utility where I > retrieved it using __of__, but I'm not sure if I'm expected to do it > that way. It's clear that some tools must be wrapped in order to perform > their function - that's why for example the method I wrote to replace > getToolByName for untrusted code still expects a context to be passed > along and I wrap the utility in it. > > It's just a bit unintuitive that sometimes you must wrap them, sometimes > you don't need to. For a third party coder this could turn into a major > headache and bug bear. Hhm, I'm not sure what the best way is here. Personally I would like to get rid of as much of Acquisition as possible, but obviously we need to be careful here. Thinking about it a bit more, I would say, that if you need to aq_wrap a tool in order for it to function as expected, you shouldn't really register it as a utility in the first place. The forced aq_wrapping is like introducing a new required context argument in a method. You effectively change the methods signature, which shouldn't be done without a deprecation period at least. In the end a utility is defined as something that does not need a context to do it's work. Registering tools as utilities that either need an Acquisition context or even worse the request (think of the evil self.REQUEST you see sometimes) violates that very definition of what utilities are. While I would really love to see getToolByName vanish as fast as possible I'm not sure if we can do this as easily as it first looked. Maybe we could offer those tools as utilities that are real utilities for CMF 2.1 and start rewriting those tools that are really more like adapters as such, removing the tools altogether or splitting them up into utilities and adapter parts. I know this isn't a scenario that would produce major results in the near future considering the number of people that currently contribute to CMF but maybe it's the safer approach. But maybe I'm just in a bit too cautious mood right now ;) Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Jens Vagelpohl wrote:
>
> On 6 Jan 2007, at 12:57, Andreas Jung wrote:
>>> On 5 Jan 2007, at 20:51, Andreas Jung wrote:
I finished my work (including some test).
Any objections merging the changes back to the trunk?
>>>
>>> If the tests pass, no. At least from me ;)
>>>
>
>> I merged the changes... hopefully without side-effects :-)
Well see ;) But Plone shouldn't have too many problems with it, as it
monkey-patches the hell out of the Zope3 tal and pagetemplate packages
anyways, as it produces UnicodeDecodeErrors all over the place otherwise.
> Now is the best time, I'm sure Plone 3 testing will give it the best
> workout it can get. I hope to finish my huge checkin (deprecating
> getToolByName and replacing it with utility calls) this weekend.
Regarding your greatly appreciated utilities work, I have tried it with
the current Plone 3 bundle and found various problems. After fixing
various code snippets, I have it in a state where the tests start at
least and we get about 200 errors for the CMFPlone tests.
I had to change two things in CMF so far though. Here are the patches I
came up with:
In DCWorkflow/Expression.py the workflow is not aq-wrapped anymore, so
you cannot call getPhysicalRoot on it anymore. But luckily we can use
the object instead.
The second one is even more important. The URLTool's getPortalObject
method was pretty dumb so far and returned the aq_parent of the tool. As
the tool can get pretty awkward aq_chains now, as getToolByName wraps
the tool inside the callers context, we need a better approach.
The simplest one I came up with is to do an recursive loop and check if
the parent implements ISiteRoot. This should get you the real portal
object. At least with this patch another 300 unit tests pass in CMFPlone
where about 500 failed before.
Another way would potentially be to register the portal object itself as
a utility, so you could query it directly, but that would be a bit of an
extra work...
I'll try to find out what's causing the other test failures in Plone :)
Hanno
Index: Expression.py
===
--- Expression.py (revision 71731)
+++ Expression.py (working copy)
@@ -122,7 +122,7 @@
'container':container,
'folder': container,
'nothing': None,
-'root': wf.getPhysicalRoot(),
+'root': ob.getPhysicalRoot(),
'request': getattr( ob, 'REQUEST', None ),
'modules': SecureModuleImporter,
'user': getSecurityManager().getUser(),
Index: URLTool.py
===
--- URLTool.py (revision 71731)
+++ URLTool.py (working copy)
@@ -24,6 +24,7 @@
from zope.interface import implements
from ActionProviderBase import ActionProviderBase
+from interfaces import ISiteRoot
from interfaces import IURLTool
from interfaces.portal_url import portal_url as z2IURLTool
from permissions import ManagePortal
@@ -74,7 +75,15 @@
def getPortalObject(self):
""" Get the portal object itself.
"""
-return aq_parent( aq_inner(self) )
+portal = aq_inner(self)
+while True:
+portal = getattr(portal, 'aq_parent', None)
+if portal is None:
+break
+if ISiteRoot.providedBy(portal):
+return portal
+# Portal could not be found, log an error or raise one?
+return aq_inner(self)
security.declarePublic('getRelativeContentPath')
def getRelativeContentPath(self, content):
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Hi Jens, all!
I haven't seen any progress on the tools as local utilities story for
some time now. Is there anything specific I can help with?
Jens Vagelpohl wrote:
> On 22 Nov 2006, at 12:15, Hanno Schlichting wrote:
>> At the time I wrote this it was kind of experimental and I didn't know
>> if I could make it work. So I put it in an add-on with the clear
>> intention to merge it back into GenericSetup once it was reasonably
>> stable and working. Thx for taking over that part :)
>
> Thanks for the code ;)
I have taken another look at the code and fixed some obvious bugs. As I
still have no commit rights for the svn repo (yes, entirely my fault)
could somebody commit the attached patch (against GS trunk) for me?
With this patch applied I think at least the utility handlers are fully
functional. As I haven't written tests for the adapter handlers so far,
I'm not sure for those yet ;)
Thx in advance,
Hanno
Index: tests/test_components.py
===
--- tests/test_components.py(revision 71534)
+++ tests/test_components.py(working copy)
@@ -24,10 +24,14 @@
from Products.Five.component import enableSite
from Products.Five.component.interfaces import IObjectManagerSite
+from Products.GenericSetup.interfaces import IBody
from Products.GenericSetup.testing import BodyAdapterTestCase
from Products.GenericSetup.testing import ExportImportZCMLLayer
+from Products.GenericSetup.tests.common import DummyExportContext
+from Products.GenericSetup.tests.common import DummyImportContext
from zope.app.component.hooks import setSite, clearSite, setHooks
+from zope.component import getMultiAdapter
from zope.component import getSiteManager
from zope.component import queryUtility
from zope.component.globalregistry import base
@@ -50,12 +54,6 @@
def verify():
"""Returns True."""
-class IDummyInterface2(Interface):
-"""A second dummy interface."""
-
-def verify():
-"""Returns True."""
-
class DummyUtility(object):
"""A dummy utility."""
@@ -64,28 +62,31 @@
def verify(self):
return True
-class DummyUtility2(object):
-"""A second dummy utility."""
+class DummyTool(SimpleItem):
+"""A dummy tool."""
+implements(IDummyInterface)
-implements(IDummyInterface2)
+id = 'dummy_tool'
+meta_type = 'dummy tool'
+security = ClassSecurityInfo()
+security.declarePublic('verify')
def verify(self):
return True
-dummy2 = DummyUtility2()
-
-class DummyTool(SimpleItem):
-"""A dummy tool."""
+class DummyTool2(SimpleItem):
+"""A second dummy tool."""
implements(IDummyInterface)
-id = 'dummy_tool'
-meta_type = 'dummy tool'
+id = 'dummy_tool2'
+meta_type = 'dummy tool2'
security = ClassSecurityInfo()
security.declarePublic('verify')
def verify(self):
return True
+
InitializeClass(DummyTool)
_COMPONENTS_BODY = """\
@@ -100,12 +101,10 @@
object="/dummy_tool"/>
+ object="/test_folder_1_/dummy_tool2"/>
-
"""
@@ -115,6 +114,32 @@
layer = ExportImportZCMLLayer
+def test_body_get(self):
+self._populate(self._obj)
+context = DummyExportContext(self.app)
+adapted = getMultiAdapter((self._obj, context), IBody)
+self.assertEqual(adapted.body, self._BODY)
+
+def test_body_set(self):
+context = DummyImportContext(self.app)
+adapted = getMultiAdapter((self._obj, context), IBody)
+adapted.body = self._BODY
+self._verifyImport(self._obj)
+self.assertEqual(adapted.body, self._BODY)
+
+# now in update mode
+context._should_purge = False
+adapted = getMultiAdapter((self._obj, context), IBody)
+adapted.body = self._BODY
+self._verifyImport(self._obj)
+self.assertEqual(adapted.body, self._BODY)
+
+# and again in update mode
+adapted = getMultiAdapter((self._obj, context), IBody)
+adapted.body = self._BODY
+self._verifyImport(self._obj)
+self.assertEqual(adapted.body, self._BODY)
+
def _getTargetClass(self):
from Products.GenericSetup.components import \
ComponentRegistryXMLAdapter
@@ -139,19 +164,15 @@
self.assertEqual(tool.meta_type, 'dummy tool')
self.assertEquals(repr(util), repr(tool))
-util = queryUtility(IDummyInterface2)
-self.failUnless(IDummyInterface2.providedBy(util))
-self.failUnless(util.verify())
-
[Zope-CMF] Re: Tools as local utilities
Hi Jens, all. Why did you pick exactly the two weeks where I'm on vacation without an Internet connection to do this? Anyways by reading through the mailing list it seems you have figured it all out by now ;) Jens Vagelpohl wrote: > > I have to run off right now, but a quick look over GSLocalAddons > suggests it should be part of the main CMF Default GS profile, and doing > it with GenericSetup certainly is the way to go. Why did Hanno not put > it into the CMF base profile right from the start, dangit! At the time I wrote this it was kind of experimental and I didn't know if I could make it work. So I put it in an add-on with the clear intention to merge it back into GenericSetup once it was reasonably stable and working. Thx for taking over that part :) The dumb but simple reason why I didn't start folding this back in myself is that (besides the usual lack of time) I don't have commit rights on svn.zope.org. As I'm quite lazy could anybody point me to the current process of getting those or tell me what I have to do? Thx, Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 2.1 release schedule
Hi. Jens Vagelpohl wrote: > > I was under the impression there were a few "show-stoppers" that needed > CMF 2.1 (and in some cases Five) support that weren't there yet, like > the "customize a skin item". Are there any items you know are missing? > You seem to apply you have everything you need. The current state of the CMF 2.1 support for Plone 3.0 is simply at the it-works level. That is, I made all those changes that where required to get all tests passing again. The major change here was porting all actions related code to the new IAction and IActionCategory code, which was especially painful for our huge amount of migration code. The second major change was porting quite some amount of code for registering new content types to be based on GenericSetup profiles, as I found this to be the only reliable way to register new types. Regarding the skin customizations our current strategy is to write views in pure file-system based code without a way to customize these TTW and have the page templates as usual skin items with customize support. While this isn't ideal we are currently mainly moving code out of tools into views and utilities. Both of these increase the ability to make customizations compared to the former state of having to replace complete tools. > Looking at http://www.zope.org/Products/CMF/docs/roadmap there are quite > a few items we were hoping to get in that aren't finished yet. OK, to be honest: None of the items in the CMF roadmap are crucial to the next Plone release in any way. So for the three remaining items: Eggs As we won't be able to move Plone to be completely egg-based we do not need CMF to be either. But of course we want to make as much of Plone available as an egg as possible in the future, maybe in the next release which is planned for autumn 2007 (Plone 3.0 final is scheduled for late March 2007). Note that this is however not a priority as we depend on quite some external binaries, so we won't be able to do a pure egg-based install anyways. Zope3 views --- Having good Zope3 views in CMF would be nice as it would eventually enable us to re-use some of these again. But honestly right now we do not use any of the content types from CMF anymore apart from being based on the PortalContent base class. We do not use any of the skin layers from CMF and the only skin script we still use is the titleOrId script which is more than trivial. So having views on the CMF level might open up a possibility to re-use some of them again, but whether or not these are present does not have any immediate effect on Plone. Events -- This is the only item that has a direct effect on our code. The extremely ugly way we dealt with the added events and removed manage* methods so far is to copy over the manage* methods to Archetypes instead, as we cannot break all dependent products without concrete deprecation warnings and nobody had the time to add proper events support to Archetypes so far. This resulted in a even more insane cataloging behavior of Archetypes which we circumvented by looking if an object is already in a catalog before indexing it and looking if it is still there before unindexing it. Reindexing objects still takes place quite some times. As the amount of people working on Archetypes right now is fairly limited, I guess we will deal with most other events in the same manner. While this is ugly it was the only way to get Archetypes working with CMF 2.1 so far. So while more events are theoretically nice, we won't take advantage of them right now. Some of the above might only be my personal opinion and I'll let others jump in if they have a different point of view :) Yours, Hanno P.S. We'll hopefully meet in St. Augustin next week ;) ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Hi. Jens Vagelpohl wrote: > > Just out of curiosity, which dependencies does Plone 3.0 have that > require Zope 2.10? Or was it some papal edict to use 2.10? It was more of an edict, to catch up with the latest versions of our underlying frameworks again. The two things we are actually relying on right now is OOTB support for egg-enabled Python packages instead of Zope products (there are some egg-enabled plone.* and plone.app.* packages) and quite some of these packages are using the new local components API. We are also going to use formlib based forms, contentmanagers and viewlets and finally zope.testbrowser based tests but these are available in Zope 2.9 with Five 1.4 as well. Apart from these supporting only Zope 2.10 made it possible to remove quite some BBB code for changed package locations ;) As a final note I might add that we still consider to support Zope 2.11 as well for Plone 3.0 especially if it brings us Blob support on the ZODB level. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 2.1
Hi Jens, all! For the uninitiated I'm the poor guy that signed up to work on getting Plone trunk (aka 3.0) to work with current CMF trunk (aka 2.1) amongst other things ;) According to the roadmap for the next Plone release we currently aim for Plone 3.0-final to be released in January 2007. More important to the CMF roadmap is our planned feature freeze which is currently set around September/October 2006. This is the date where all features to be included in Plone should be ready and merged and thus should be pretty stable. If you are wondering what we do in the upcoming months - well fixing bugs :) So as Plone 2.5 (which should be released any day now) will stay on CMF 1.6 and Plone 3.0 won't be around for some months there is no need for a CMF release from our side right now. Ideal for our roadmap would be a CMF 2.1 release that includes some more work on Zope3 (like object events and views) and would see a final dot-O release somewhere around October this year. If there is a demand for a 2.1 release right now from other consumers or users of the CMF, we would either have to use this release for Plone 3.0 or as we want to try to stay close to the CMF releases would be happy to have another CMF release in lets say December and re-aim for Plone 3.0 to be released in February 2007 instead. On a side note we will require at least Zope 2.10 (or eventually Zope 2.11) for Plone 3.0, so there is no need to support things like Zope 2.8 or even 2.9 in CMF as far as we are concerned anymore. Hope we can get a CMF roadmap together that fits all our needs and individual roadmaps ;) Hanno Jens Vagelpohl wrote: > I just looked over the CMF roadmap document since we're supposed to have > a 2.1 beta in a matter of weeks and now I'm wondering if this is > possible/desirable right now: > > http://www.zope.org/Products/CMF/docs/roadmap > > First of all, some of the work items on the list are half-finished or > still off on some branch. Secondly, when comparing our roadmap to the > Plone roadmap... > > http://plone.org/products/plone/roadmap > > I'm not sure if we need a 2.1 right now. We seem to be producing > one-off release branches that are either not used at all or used > sporadically by specific projects. By the way, Florent, do you guys have > such a roadmap doc that I can look at once in a while? Something that at > least says "version X is planned for Y and will run on CMF version Z". > > Also, one of the highly desirable items on the list, the local skin > customization, has an outside dependency that we need to wait on. > > So, what's the consensus? Do we postpone 2.1 to get more things done? Do > we cut the list of planned features down and create yet another release > branch that might not even be used? I'm hoping this discussion can > foster more active collaboration on roadmaps between the different "CMF > customers". There's no sense following a strict time-based policy that > is currently out of sync with what the "customers" want/need. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] Portal status messages and i18n: a proposal
Lennart Regebro wrote:
> On 2/23/06, yuppie <[EMAIL PROTECTED]> wrote:
>> Currently the portal status message is always translated in the i18n
>> domain of main_template if sent through a redirect. This makes it
>> impossible to use different domains (and mappings or defaults).
>>
>> Add-on products might want to use their own i18n domain. CMFCalendar
>> demonstrates that use case. "Event changed." is currently not translated
>> because of that issue.
>
> Afaik, using MessageIds solves this. If it doens't, that's a bug. :)
Message(ID)s indeed solve this but are complex unicode objects, that are
quite hard to map to a query string safe (per standard pure ascii but
utf-8 might work in recent browser versions) representation.
So how would the query string look like for this portal status message:
title = u'some object name with non-ascii chars in it'
_(u'msgid', default=u'Object ${name} deleted.', mapping={u'name': title})
?portal_status_message=... ?
And how would the page template regenerate a Message(ID) out of it
again, so it is indeed translated?
See my other post for a possible solution ;)
Hanno
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] Portal status messages and i18n: a proposal
Hi yuppie.
As the creator of the mentioned statusmessages product and the current
Plone i18n team lead I'm most interested in a general or at least
extensible solution to this.
The number one reason for the whole approach of the statusmessages
product was, that I wanted to use MessageID's (Messages) to mark all
portal status messages so they get automatically extractable. In Plone
there are dozens of these messages and time has taught us that nobody
updates any pot files just because he adds a missing dot in some message.
The second reason was indeed the same you mentioned: The problem of
third party products which currently have to use the domain of the
main_template. Message(ID)s are always translated in their own domain
thus eliminating this problem too.
Now the third thing the statusmessages product tries to solve is a
usability problem. Consensus in the Plone community has been that adding
portal status messages to the query string is bad as the URL should be
simple and bookmarkable and reloading a page which does not trigger an
action (like object deletion) should also not mention any message for
its success.
I think the third goal is something CMF should not enforce and is a
Plone specific detail, but the two aforementioned goals are general
valid ones.
So what I would like to see for CMF is a in the Zope3-way extensible
solution, meaning a very simple interface that I could adapt or overwrite.
The statusmessages product introduces a global utility to add portal
status messages to, but your implementation sounds a lot more like a
case for an adapter for the REQUEST and RESPONSE.
I had implemented the statusmessages product in this way first but
switched to a utility later as I needed a place to store the messages.
Of course I'm willing to help or relicense / integrate anything from the
statusmessages product in CMF if anyone should want this ;)
This is the interface for IMessage:
class IMessage(Interface):
"""A single status message.
"""
message = Attribute('The text of this message. Usally a Message
object.')
type = Attribute('The type of this message. Used to differentiate
messages by css styles.')
A short snippet of one of my older tests looked like this:
from Products.statusmessages.interfaces import IStatusMessage
from Products.statusmessages.statusmessage import STATUS_KEY
def testAdapter(self):
request = self.app.REQUEST
status = IStatusMessage(request)
# the second parameter is a type argument
status.addStatusMessage('test', 'info')
self.failUnless(request[STATUS_KEY]==status.getStatusMessages())
status.addStatusMessage('test2', 'warn')
# show returns and implictly deletes the messages
messages = status.showStatusMessages()
self.failUnless(len(messages)==2)
self.failUnless(len(status.getStatusMessages())==0)
The whole never really polished code is at:
http://svn.plone.org/svn/collective/statusmessages/branches/initial-implementation-as-adapter/
It enhances the current implementation in two ways: first status
messages have an additional type argument which can be used to
differentiate them by css styles. Typical values are 'info', 'warn' and
'error'. Second: It's possible two add more than one portal status
message at the same time.
Of course the above mentioned code stored the messages directly in the
REQUEST instead of the query string and was only implemented as a
fallback mode where the usual way would have been to use sessions but it
should mainly show the approach using an adapter for the BrowserRequest.
Both additional features don't have to be implemented for CMF but could
be added through the Plone specific add-on module.
Now what's your opinion on encapsulating the translate/charset mangling
in such a way?
Yours,
Hanno
yuppie wrote:
> Hi!
>
> Currently the portal status message is always translated in the i18n
> domain of main_template if sent through a redirect. This makes it
> impossible to use different domains (and mappings or defaults).
>
> Add-on products might want to use their own i18n domain. CMFCalendar
> demonstrates that use case. "Event changed." is currently not translated
> because of that issue.
>
> There are more sophisticated approaches than using the query string for
> status messages. Depending on your needs sessions or the statusmessages
> product (http://dev.plone.org/collective/browser/statusmessages) might
> be more appropriate.
>
> But I'd like to keep the solution used in CMF simple and don't want to
> create any dependencies on third party products. So I propose to resolve
> the issue like this:
>
> 1.) Translate portal status messages and encode them with
> default_charset before they are added to the query string. To make this
> easier I'd like to add a translate function to CMFDefault utils.
>
> 2.) Decode the messages again before they are passed to the
> main_template. No longer use i18n:translate="" in the template.
>
> Comments are welcome! If there are no objec
[Zope-CMF] Re: RFC: first stab at viewification
Hi. These test failures are due to Five 1.1 monkey patching. See http://article.gmane.org/gmane.comp.web.zope.z3base.five/756 or http://article.gmane.org/gmane.comp.web.zope.plone.devel/9501 for some more details. Basically Five monkey patches the GlobalTranslationService adding a wrapped Zope3's TS, which as a service requires some initialization. Hanno Jens Vagelpohl wrote: On 22 Oct 2005, at 00:27, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just checked in a preliminary pass at viewifying the 'full_metadata_form' (now 'metadata.html' as a view): svn+ssh://svn.zope.org/repos/main/CMF/branches/tseaver-viewification I expanded the branch by adding a proposed viewification for the Link content type, based on Tres' example and code he sent to me a few weeks ago. As mentioned in Tres' note, the five:traversable configuration in CMFDefault/configure.zcml is commented out because it breaks other CMF tests and you neeed to uncomment it to see the new stuff. However, I am seeing breakage in the link views tests themselves (traceback below) which I can't quite interpret. This time I doubt it is due to a sandbox with old software, I'm working off today's Zope 2.8 branch, the tseaver-viewification CMF branch and todays Five trunk. Can anyone spot what the problem is? Using the views in the browser does not show any error, it only pops up during testing. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
