Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate Unicode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8 Jan 2007, at 01:19, Hanno Schlichting wrote: 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. The manual wrapping can be removed if we do use the special component registry which would do it for us, right. Having it done behind the scenes is obviously much better then trying to figure out if it's needed and then doing it manually. It's also the exact same behavior people got from getToolByName, so it's not really unexpected. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFogZBRAx5nvEhZLIRAnERAJ9k2YBajLS6iXR1oqrwU2otCovtPgCfStLc xn/i6HUcdwEX4TOzAAlhiMQ= =n/bY -END PGP SIGNATURE- ___ 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] CMF Collector: Open Issues
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open mhammond - Windows DevelopmentMode penalty in CMFCore.DirectoryView, [Accepted] http://www.zope.org/Collectors/CMF/366 Pending / Deferred Issues - FSPropertiesObject.py cannot handle multiline input for lines, text attributes, [Deferred] http://www.zope.org/Collectors/CMF/271 - Can't invalidate skin items in a RAMCacheManager, [Pending] http://www.zope.org/Collectors/CMF/343 - workflow notify success should be after reindex, [Deferred] http://www.zope.org/Collectors/CMF/389 - Possible bug when using a BTreeFolder Member folder, [Pending] http://www.zope.org/Collectors/CMF/441 - Proxy Roles not Working/Applied to Worflow Transition Scripts, [Pending] http://www.zope.org/Collectors/CMF/449 - safe_html filters some tags which should probably not be filtered, [Pending] http://www.zope.org/Collectors/CMF/452 - purge_old in runAllImportSteps not working, [Pending] http://www.zope.org/Collectors/CMF/455 - PUT handling for Events is broken, [Pending] http://www.zope.org/Collectors/CMF/458 - Danger from Caching Policy Manager, [Pending] http://www.zope.org/Collectors/CMF/460 Pending / Deferred Features - Favorite.py: queries and anchors in remote_url, [Pending] http://www.zope.org/Collectors/CMF/26 - DefaultDublinCore should have Creator property, [Pending] http://www.zope.org/Collectors/CMF/61 - Document.py: universal newlines, [Pending] http://www.zope.org/Collectors/CMF/174 - portal_type is undefined in initialization code, [Pending] http://www.zope.org/Collectors/CMF/248 - CMFTopic Does Not Cache, [Deferred] http://www.zope.org/Collectors/CMF/295 - Wishlist: a flag that tags the selected action., [Pending] http://www.zope.org/Collectors/CMF/301 - CMFDefault should make use of allowCreate(), [Pending] http://www.zope.org/Collectors/CMF/340 - Nested Skins, [Deferred] http://www.zope.org/Collectors/CMF/377 - CatalogVariableProvider code + tests, [Pending] http://www.zope.org/Collectors/CMF/378 - manage_doCustomize() : minor additions, [Pending] http://www.zope.org/Collectors/CMF/382 - CMF needs View-based TypeInformation, [Pending] http://www.zope.org/Collectors/CMF/437 - Marker attributes should be deprecated, [Pending] http://www.zope.org/Collectors/CMF/440 ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: On 8 Jan 2007, at 01:19, Hanno Schlichting wrote: 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. The manual wrapping can be removed if we do use the special component registry which would do it for us, right. Having it done behind the scenes is obviously much better then trying to figure out if it's needed and then doing it manually. It's also the exact same behavior people got from getToolByName, so it's not really unexpected. Even in Zope3, I think that local utilities may need to be local, meaning that they know the place in which they are registered. In Zope2, we *must* wrap them for the sake of security, if nothing else. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFombj+gerLs4ltQ4RAoQAAJ0TIjargP59yIXdW+59yEedPQwU7gCghQKv 4CichHH+qhX7WGGsdQlwukQ= =5nIX -END PGP SIGNATURE- ___ 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] Installing a CMF Content Type from scratch
Hi, I'm working on a new content type for the CMF. I've got it working as a Zope Product and can add instances of it through the ZMI but I need to register for my CMF site. I've been looking at the way Andy McKay does this in his Plone book but this seems to rely on some Plone magic (an install product function in the Plone control panel) which I don't have. I assume I should be able to do everything I need through the portal_types and add a file system directory view for the skins folder. Is this correct? Is anything else required? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
Re: [Zope-CMF] Internationlisation question
Am 07.12.2006 um 12:54 schrieb Lennart Regebro: span i18n:data python: DateTime() i18n:translate=datefmt i18n:name=date/span With i18n:name I get an error that i18n:name needs to be within a translation unit and without it I get a cannot iterate over a non- sequence. So, what I am getting wrong? This part makes no sense to me: i18n:data python: DateTime() Maybe you meant tal:define=data python: DateTime() ? I don't think so. I've been referring to Andy McKay's book on Plone and he lists i18n:data as an part of the specification but maybe this is specific to Plone? Anyway - what I want to do is have something like 20th January 2007 in some places and 20. Januar 2007 in others on the same site which has no language settings. What is the best way in going about this? Thanks Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
While I don't have time at this very moment to address this in great detail, I will mention a few comments. On Mon, 2007-08-01 at 15:40 +0100, Philipp von Weitershausen wrote: Using PersistentComponents() as the component registry (a.k.a. site manager) for local sites isn't enough. That's because it doesn't understand about containment hierarchies. Imagine this folder hierarchy: /root_site/ + cmf_site/ + somefolder/ + anotherfolder/ + sitefolder/ + + stuff_in_here cmf_site is obviously a site. Let's say root_site and sitefolder are also sites (yes, Zope3-style sites can be nested). That's not to say that sitefolder is another CMF Site, it's just a Zope3-style ISite (regular zope 2 folders can be sites in Zope 2.10). You would expect component lookup at stuff_in_here to * first lookup stuff in sitefolder, * then in cmf_site, * then in root_site, * and finally in the global registry If you use PersistentComponents() this won't automatically happen! This is a major problem. This means that if someone is traversing to sitefolder and some view code calls getUtility(ICatalog) (instead of the deprecated getToolByName(context, 'portal_catalog') then the lookup will fail if sitefolder doesn't provide the utility (and it probably won't provide it). We need a LocalSiteManager implementation for Zope 2 (mostly because of the __bases__ thing, but perhaps also because we then have a designated place for local components instead of the portal root). Indeed. As a bonus, the Zope 2 LocalSiteManager could also mix in ObjectManager. Right, would be nice as well. 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. This would be the best approach (creating five.localsitemanager) in my opinion. But, this means CMF will either require (or distribute) five.localsitemanager. (Plone will have the same issue) I'm not sure where we stand on this. I'd like to avoid making a Five 1.6. +1 Regards, Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ 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: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: On 8 Jan 2007, at 01:19, Hanno Schlichting wrote: 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. The manual wrapping can be removed if we do use the special component registry which would do it for us, right. Having it done behind the scenes is obviously much better then trying to figure out if it's needed and then doing it manually. It's also the exact same behavior people got from getToolByName, so it's not really unexpected. Even in Zope3, I think that local utilities may need to be local, meaning that they know the place in which they are registered. No they don't. There's nothing implied for local utilities, not even persistence. Of course, many local utilities *are* persistent and stored in a folder somewhere, thus have a __parent__ and all that. But that's typically less of interest when *using* the utility. In Zope2, we *must* wrap them for the sake of security, if nothing else. Sadly yes. -- http://worldcookery.com -- Professional Zope documentation and training 2nd edition of Web Component Development with Zope 3 is now shipping! ___ 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
Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate Unicode
Hanno Schlichting wrote at 2007-1-7 23:42 +0100: 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? Why? When an object implements __of__, this indicates that it is willing to play with the ExtensionClass context feature (usually used for acquisition). Why can we not use this indication? -- Dieter ___ 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
Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate Unicode
Martin Aspeli wrote at 2007-1-7 23:40 +: ... 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. No need to invent a new marker interface for this. Objects ready to participate in context wrapping indicate this by the __of__ method... -- Dieter ___ 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
plone's egg story looks non-existent until next release. -w ___ 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
Philipp von Weitershausen wrote: Jens Vagelpohl wrote: CMF won't come eggified for this release, that work has stalled. whit wrote: plone's egg story looks non-existent until next release. Right, I figued as much. Also, it's only for Zope 2.11 that we can actually tackle sensible egg support in the Zope 2 core, so that makes more sense anyway. I see three options: a) somehow bundle CMF 2.1 (and Plone 3) with a package called five.localsitemanager. Given that Plone 3 already has plone.* packages (and I assume they also want five.customerize), this might probably be less of an issue for Plone than for the CMF. b) make Five 1.6 and have that include five.localsitemanager. I would *rather* not like to do that... c) create Products.FiveLocalSiteManager, or perhaps Products.LocalSiteManager. Yet another product *sigh*. OTOH, that might not be such a problem since I envision products to become eggs in Zope 2.11... Of course, whatever we decide to do, the result really should ship with Zope 2.11. It's already sort of a crime that we don't do this in Zope 2.10 yet. Even worse, Five itself is creating sites w/ PersistentComponents :(. -- http://worldcookery.com -- Professional Zope documentation and training 2nd edition of Web Component Development with Zope 3 is now shipping! ___ 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: Philipp von Weitershausen wrote: Actually, I agree with Dieter here. If something has an __of__(), just wrap it. You can't possibly do anything wrong, actually, as it already happens and it provides the best backward compatibility with what we have right now. Is __of__() in an interface somewhere? I would prefer using that (if it's promised by some mixin deep in zope anyway). Not that it greatly matters, if we actually want a policy that wraps every time. If we want wrapping to be controllable and optional, I think we need a marker interface. Fair enough, __of__() is documented by Acquisition.interfaces.IAcquirer which is provided by all objects inheriting from Aquisition.Explicit or .Implicit. That's your marker interface. -- http://worldcookery.com -- Professional Zope documentation and training 2nd edition of Web Component Development with Zope 3 is now shipping! ___ 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
Re: [Zope-CMF] Re: [CMF 2.1] PersistentComponents is not enough
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8 Jan 2007, at 23:54, Martin Aspeli wrote: Philipp von Weitershausen wrote: a) somehow bundle CMF 2.1 (and Plone 3) with a package called five.localsitemanager. Given that Plone 3 already has plone.* packages (and I assume they also want five.customerize), this might probably be less of an issue for Plone than for the CMF. This is not a problem for Plone 3, and I would certainly prefer this option. It's just a deployment/packaging issue for CMF also. You could for example distribute an egg with a script that makes sure it gets installed in the right place ($INSTANCE_HOME/lib/python). - -10 on anything that changes the deployment scenario from the current copy the contents of the tarball into your Products folder. If we really have to I'd rather stitch in a svn external. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFo0qLRAx5nvEhZLIRAnXtAJ49ZBCSCNwv7nTvwPdqv6hgbDJkewCgko76 OXhYr7waD/WGBAzLBySQOAo= =RCFf -END PGP SIGNATURE- ___ 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
