[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 hannosch - [GS] Error when choosing initial_configuration , [Accepted] http://www.zope.org/Collectors/CMF/473 tseaver - CMF needs View-based TypeInformation, [Accepted] http://www.zope.org/Collectors/CMF/437 yuppie - purge_old in runAllImportSteps not working, [Accepted] http://www.zope.org/Collectors/CMF/455 Pending / Deferred Issues - workflow notify success should be after reindex, [Deferred] http://www.zope.org/Collectors/CMF/389 - Can't add (plone) portal with plone 3.0b3 - AttributeError in DCWorkflow._executeTransition, [Pending] http://www.zope.org/Collectors/CMF/484 Pending / Deferred Features - CMFTopic Does Not Cache, [Deferred] http://www.zope.org/Collectors/CMF/295 ___ 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] ICS support for CMF Calendar
Hi Charlie, * the vCal format isn't really suitable for a PageTemplate although it is possible. Are there any other options? You might try Chris Withers' Twiddler: http://www.simplistix.co.uk/software/python/twiddler Might be a piledriver for your nail though! Cheers, Dan -- Dan Fairs [EMAIL PROTECTED] ___ 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] ICS support for CMF Calendar
Am 22.06.2007 um 10:34 schrieb Dan Fairs: You might try Chris Withers' Twiddler: http://www.simplistix.co.uk/software/python/twiddler Might be a piledriver for your nail though! Hi Dan, I don't want to introduce a dependency on twiddler or genshi into CMFCalendar and it's not necessary for this as the template requires little or no logic: formatting or string.Template are more than adequate but I would like to have the template outside of the calling script. You can in fact use ZPT quite well for non *ML if you use the pseudo-tags tal:content tal:content=options/start_date / is only a little bit more verbose than %(start_date)s or $start_date but it would be nice to have a handler for string.Template templates. Is it possible to work with .txt? ie. template = context.event_ics_template() template = template % options # or template.substitute(options) The bigger problem seems that there is no easy way to get the timezone needed to get appointments to work properly. vCal requires timezone id's like Europe/Amsterdam. Looks like the only thing is to coerce the time to what the server thinks is UTC and hope the client will do the conversion. 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: Minor problem with local_pt and non-ascii portal properties
Charlie Clark wrote: it is not possible to do anything with a local_pt in the ZMI if any of the Portal properties are non-ascii. I have a site called Düsseldorf with a local_pt containing some customisations for the homepage. With CMF 2.0 and Zope 2.9 this is not a problem but CMF 2.1 and Zope 2.10 will cause an error presumably due to the switch to Zope 3 PageTemplates. The tracaback is below. The first question is: am I doing something wrong using local_pt like this? If not the second question is: what's the best way around this? Please try to use a script and Products.CMFDefault.utils.decode. In CMF 2.1 *all* strings passed to a template have to be unicode. Maybe 'portal_title' defined in getMainGlobals works for you, at least it shows how to use 'decode'. HTH, Yuppie ___ 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: New factory stuff
Hi Charlie! Charlie Clark wrote: One thing I haven't quite sussed: my products are still registered using ContentType.addContentType function but I notice that the CMF Default types make use of zope.component.factory and seem to register factories somewhere, ie. cmf.document I haven't been able to recreate this behaviour myself despite invoking a factory. Did you register your factory as utility? Did you make sure 'product' is empty in your type info? Do I need to create my own namespace to register content types or can I insert them in the cmf one? The only reason a namespace is used is to make sure identifiers are unique. If you use your own namespace, you don't have to care about utility names used by other products. HTH, Yuppie ___ 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: New factory stuff
Am 22.06.2007 um 12:04 schrieb yuppie: Did you register your factory as utility? Did you make sure 'product' is empty in your type info? I did register it as a utility but product wasn't empty! Seems to be working now Does this mean that product initialisation in __init__.py can be reduced to simple imports? ie. import Employee with no more calls to utils.ToolInit and utils.ContentInit? Do I need to create my own namespace to register content types or can I insert them in the cmf one? The only reason a namespace is used is to make sure identifiers are unique. If you use your own namespace, you don't have to care about utility names used by other products. That does indeed make sense. Thank you very much! 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] Re: Minor problem with local_pt and non-ascii portal properties
Am 22.06.2007 um 12:13 schrieb yuppie: Please try to use a script and Products.CMFDefault.utils.decode. In CMF 2.1 *all* strings passed to a template have to be unicode. Maybe 'portal_title' defined in getMainGlobals works for you, at least it shows how to use 'decode'. Displaying the local_pt works fine. I just can't edit it without changing the portal_title first which is strange because I can't understand why the portal_title is called in the ZMI when the manage_workspace is called. I thought the whole idea of local_pt was to be able to write template snippets that don't fit an existing template but this becomes impossible if you can't edit them. 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] CMF Tests: 11 OK
Summary of messages to the cmf-tests list. Period Thu Jun 21 12:00:00 2007 UTC to Fri Jun 22 12:00:00 2007 UTC. There were 11 messages: 11 from CMF Unit Tests. Tests passed OK --- Subject: OK : CMF-1.5 Zope-2.7 Python-2.3.6 : Linux From: CMF Unit Tests Date: Thu Jun 21 21:32:52 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005390.html Subject: OK : CMF-1.5 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Thu Jun 21 21:34:22 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005391.html Subject: OK : CMF-1.5 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Thu Jun 21 21:35:55 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005392.html Subject: OK : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Thu Jun 21 21:37:26 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005393.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Thu Jun 21 21:38:57 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005394.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Thu Jun 21 21:40:27 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005395.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Thu Jun 21 21:41:58 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005396.html Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Thu Jun 21 21:43:29 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005397.html Subject: OK : CMF-2.1 Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Thu Jun 21 21:45:01 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005398.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Thu Jun 21 21:46:32 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005399.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Thu Jun 21 21:48:04 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-June/005400.html ___ 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: New factory stuff
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charlie Clark wrote: Am 22.06.2007 um 12:04 schrieb yuppie: Did you register your factory as utility? Did you make sure 'product' is empty in your type info? I did register it as a utility but product wasn't empty! Seems to be working now Does this mean that product initialisation in __init__.py can be reduced to simple imports? ie. import Employee with no more calls to utils.ToolInit and utils.ContentInit? Adding directives which *allow* moving all registration steps from Python code to ZCML was an explicit goal; I *think* we accomplished it, but may have overlooked something. Note that I would not favor doing imports at module scope in __init__.py; that just muddies the waters about how you expect the import to work. I would make an exception for a package which was *designed* to be a facade on which others could depend (like the 'zapi' module). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGe9yv+gerLs4ltQ4RAo4JAKCJDUB++GJL7tB/rHEgrI2fvUZxkQCglV1k gBDWf3B1YiJRFoDuxrc= =Xid2 -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] Re: state of GenericSetup trunk and branches
yuppie wrote: Hi Rob! Rob Miller wrote: yuppie wrote: - Why is it necessary to use version numbers from VERSION.txt? AFAICS it does not make much sense to keep profile version numbers in sync with product version numbers. New profiles should have an explicit version in metadata.xml, old profiles can use '0' as version number. No? i could go either way. i thought that some folks, with products that had fast release cycle, might choose to use the product version as the profile version, so the product version is used as a failover if a profile version isn't present. i don't feel strongly, though, and would be fine to remove this if others disagree. Well. I'd prefer to have *one* obvious and explicit solution. The failover adds extra code that needs to be maintained and makes it less obvious where the version number comes from. i agree. i was thinking since my last reply that, since the code is already in there, we could support a special value in the metadata.xml file that explicitly tells GS to use the product version for the profile version, rather than having that be the default behaviour. - Why uses ProfileMetadata the old ImportConfiguratorBase? ImportConfiguratorBase is just not deprecated because GenericSetup still uses it in some places. But the goal was to get rid of it, not to add new files that depend on it. since it wasn't deprecated, or even commented, i didn't know the goal was to get rid of it. sorry. I am sorry. Looks like you spent a lot of time on figuring out how it works and writing documentation :( yup. ah well. I wrote that code long ago, replacing the old pattern still used in DCWorkflow's WorkflowDefinitionConfigurator. Later I figured out that this extra framework is less flexible and not much easier to use than the generic DOM API. All new code is DOM based and a big part of the old code is converted. If you agree that this code can be removed in the long run, we should figure out how to document this decision. i'm fine to remove it. it was a bit of a PITA. putting a comment in the code or the docstring would have been enough to alert me to not use it, until such time as we can convert the remaining uses and officially deprecate it. - Why is exporting metadata.xml not supported? because metadata.xml is not actually site configuration. it's metadata on the profile itself. there's not any way, nor should there be, IMO, that the information provided in the metadata file can be changed on a live site in such a way that it would be exported. perhaps it would be better to change the metadata to an .ini file, or some other config syntax, to distinguish it more clearly from the rest of the profile. If it is pure registration information, why don't we extend the ZCML directive? But AFAICS data like the version number belongs to the profile itself and it might be useful to add timestamp based version numbers to exported profiles. - How are profile dependencies specified, where are they used? dependencies are specified in metadata.xml; syntax can be found in test_profile_metadata.py. unfortunately, they're not used yet... this was a goal that we didn't actually get to. :-(. 'DEPENDENCY 1' and 'DEPENDENCY 2' don't really explain how to specify dependencies: Would we use identifiers like 'Products.CMFCalendar:default'? Is it possible to use version numbers? true enough. i was thinking it would simply be the profile identifier, e.g. 'Products.CMFCalendar:default'. i'm not planning on developing a really rich dependency management infrastructure, just a way to have one profile trigger the importation of another. As long as these questions are not resolved I would disable the support for dependencies completely. it IS disabled completely. but i'm fine w/ removing the 'dependency' pieces from the metadata.xml parsing, until such time as it can actually be implemented. -r ___ 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: state of GenericSetup trunk and branches
Rob Miller, on 2007-06-21: Wichert Akkerman wrote: The new GS looks very nice, but from the ZMI UI I can no longer see how I can import only selected steps of an extension profile. I hope that is still possible; it can be extremely useful. It looks like the import and export tab only act on the base profiels now. hmm... i think that the aggregate of all of the steps from the various profiles that have ever been imported should show up on the import screen, so it should be possible to select ones that were added by a specific extension profile. but this doesn't help, of course, when you only want to re-import the portal types step from an extension profile. Indeed: currently you will just import the portal types as defined by the base profile. so you're right, the UI is missing a piece. two pieces, actually. on the 'profiles' tab, there should be another button, load import steps, which will register the steps w/o actually running them. (importing a profile does this for you.) then the import and export tabs can have a dropdown that lets you choose from any profiles that have had the steps loaded. i won't be able to get to that until next week, unfortunately. anyone else? I have some code that I think does the first part: adding a button on the Profiles tab and adding some code to support it: http://paste.plone.org/15348 During testing I noticed that my knowledge of GenericSetup might be flawed though, as I discovered some things that were new to me, so I have some questions that crept up. 1. In GenericSetup 1.2, if you select an extension profile on the Properties tab (now called Profiles), and then go to the Import tab and import all steps, is that extension profile then basically treated as a BASE profile? 2. What needs to happen on the import tab now on trunk? We want a drop down that lists all extension profiles. When I select one of those extension profiles, should I get a list of only those steps for which this profile has an xml file? Or should I just get a list of all steps available (several dozen on Plone 3) and have the extension profile as context when I click the correct button? 3. When I install Plone 3.0 with the new GenericSetup trunk, and go to the Import tab, there are about 37 steps listed. That is a lot. Especially there are a few importVarious steps of different products, at least when you add some third party products in the Products dir. I do not know how widespread and generally accepted those importVarious steps are for third party products. I do notice that in the current situation in Plone 3 when you go to that import tab and click Import All Steps, all registered steps are tried, including all third party importVarious steps. As a test I added my own eXtremeManagement product in the Products dir, which also has a GS extension profile with an importVarious step. I registered this profile with the patch I linked to above. Then I tried to import all steps. This meant that the eXtremeManagement importVarious step was run, which gave problems as it assumed some portal types to be available, which were not there. I now fixed that by checking what the context is: def importVarious(context): if 'Products/eXtremeManagement/profiles/default' \ not in context._profile_path: return ... In fact, when running all import steps, the profile path of the context is that of CMFPlone: u'/home/maurits/instances/xm30/Products/CMFPlone/profiles/default' Anyway, for extension profiles we want to give the users a means on that import tab to get the context right. I guess my question is: A. Is my change to eXtremeManagement in the importVarious function above logical? I committed it already, so it had better be. :) B. These importVarious steps that eXtremeManagement and other products define, and that cannot be mapped to other handlers, are they good practice? Or are they an abomination, bound to lead to problems? Thanks for your time, -- Maurits van Rees | http://maurits.vanrees.org/ [NL] Work | http://zestsoftware.nl/ Do not worry about your difficulties in computers, I can assure you mine are still greater. ___ 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
