[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 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 Pending / Deferred Features - CMFTopic Does Not Cache, [Deferred] http://www.zope.org/Collectors/CMF/295 - iCal support for CMFCalendar, [Pending] http://www.zope.org/Collectors/CMF/487 ___ 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 Tue Jul 17 12:00:00 2007 UTC to Wed Jul 18 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: Tue Jul 17 21:31:30 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005668.html Subject: OK : CMF-1.5 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Tue Jul 17 21:33:00 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005669.html Subject: OK : CMF-1.5 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Jul 17 21:34:34 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005670.html Subject: OK : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Tue Jul 17 21:36:06 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005671.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Jul 17 21:37:38 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005672.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Jul 17 21:39:12 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005673.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Jul 17 21:40:42 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005674.html Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Jul 17 21:42:16 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005675.html Subject: OK : CMF-2.1 Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Jul 17 21:43:46 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005676.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Jul 17 21:45:19 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005677.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Jul 17 21:46:50 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-July/005678.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] [GenericSetup] One profile for different GS versions
Hi, I have an extension profile that works with Plone 3.0 (basically modifying portal_skins and portal_actions). For Plone 2.5 compatibility my actions.xml and skins.xml need to be different because the XML structure is different between. What is the best approach for maintaining XML files for both Plone 2.5 and Plone 3.0 in one profile (at least within the same source tree)? Andreas -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK E-Publishing, Python, Zope Plone development, Consulting pgpRbIATxL1Vc.pgp Description: 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: [GenericSetup] One profile for different GS versions
Andreas Jung, on 2007-07-18: I have an extension profile that works with Plone 3.0 (basically modifying = portal_skins and portal_actions). For Plone 2.5 compatibility my=20 actions.xml and skins.xml need to be different because the XML structure is = different between. What is the best approach for maintaining XML files for=20 both Plone 2.5 and Plone 3.0 in one profile (at least within the same source tree)? There might be some support for conditions in some of the xml files, but I am not aware of any. Other than that, I would say you need more than one profile. profiles/25 and profiles/30 could be copies of each other, except for the minor differences. Any changes to one profile would have to be kept in synch with the other profile, which is not terribly nice, but can be done. Or profiles/default could have all the configuration that is valid for both Plones and the 25 and 30 profiles could have only actions.xml and skins.xml or maybe only the relevant parts of those files. It would then be up to the user to pick the right profile in portal_setup. Or you could manage it for them in an install.py. I need something like that for the eXtremeManagement product too I think. I have a few settings in the various types definitions that lead to multiple sharing tabs and a superfluous metadata tab on Plone 3.0. No big deals, but not very nice either. I thought about making a subversion branch once Plone 3 is out, but two profiles might do the trick too. Thanks for the tip. Other ideas anyone? -- 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
Re: [Zope-CMF] Re: [GenericSetup] One profile for different GS versions
--On 18. Juli 2007 19:08:00 + Maurits van Rees [EMAIL PROTECTED] wrote: Andreas Jung, on 2007-07-18: I have an extension profile that works with Plone 3.0 (basically modifying = portal_skins and portal_actions). For Plone 2.5 compatibility my=20 actions.xml and skins.xml need to be different because the XML structure is = different between. What is the best approach for maintaining XML files for=20 both Plone 2.5 and Plone 3.0 in one profile (at least within the same source tree)? There might be some support for conditions in some of the xml files, but I am not aware of any. For portal_skins you can keep skins.xml (for Plone 3.0) and skins_2.5.xml (for Plone 2.5) within the default profile. Since the meta_type for portal_skins differs between Plone 2.5 and Plone 3.0 GS seems to pick up the right one in both cases. Unfortunatly this is not the case for portal_actions where the meta_type is identical in both Plone versions and at least the actions.xml (Plone 3.0) shadows actions_2.5.xml. -aj pgp1BLd19FRD5.pgp Description: 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] Moving to browser views
Hi,
I making my first stab at browser views for my iCal support having
finally come up with some templates that seem to produce files that
work with most calendar programs.
I have a couple of questions:
1) should I implement them as BrowserViews calling templates or
should I use an adapter? The templates are TAL and the only
difference to an HTML page is the different response header.
2) how do I pass in values derived specifically for these views? ie.
going from
options = {}
options['name'] = charlie
...
return context.mytemplate(**options)
to the appropriate call inside a browser view. I haven't been able to
work this out based on the examples or the Zope 3 book.
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] Moving to browser views
Am 18.07.2007 um 21:51 schrieb Charlie Clark:
2) how do I pass in values derived specifically for these views?
ie. going from
options = {}
options['name'] = charlie
...
return context.mytemplate(**options)
Looks like I've solved that:
return ViewPageTemplateFile('templates/test.pt')(self, **options)
However, seeing as all the examples such as document.py and event.py
are different this probably isn't the correct way to proceed...
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: Moving to browser views
Charlie Clark wrote:
Hi,
I making my first stab at browser views for my iCal support having
finally come up with some templates that seem to produce files that work
with most calendar programs.
I have a couple of questions:
1) should I implement them as BrowserViews calling templates or should I
use an adapter? The templates are TAL and the only difference to an HTML
page is the different response header.
i think the most common idiom is to use browser:page directives, pointing at
a BrowserView subclass, using either template or attribute within the
directive to specify the action to take.
2) how do I pass in values derived specifically for these views? ie.
going from
options = {}
options['name'] = charlie
...
return context.mytemplate(**options)
while it may be appropriate in some cases to pass values directly into the
template like this, usually the template pulls the values from the view class.
you can make name an attribute (or a property) of the view class, and then
use the view/name TALES expression within the template.
-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
Re: [Zope-CMF] Re: Moving to browser views
Am 18.07.2007 um 22:07 schrieb Rob Miller: while it may be appropriate in some cases to pass values directly into the template like this, usually the template pulls the values from the view class. you can make name an attribute (or a property) of the view class, and then use the view/name TALES expression within the template. Okay, thanks! I'm nearly there. I think. %-? ;-) Because I'm only creating essentially a slightly different view of an event I've taken the ZCML for the standard view as a lead: browser:page for=Products.CMFCalendar.interfaces.IEvent layer=Products.CMFDefault.interfaces.ICMFDefaultSkin name=event_iCal_view class=.event.EventiCalView permission=zope2.View / is event_iCal_view my view class? So, let's say I need to turn my creation date into 20030127T09Z I can call this in my view class via self.startdate = self.context.CreationDate() and call this in my template via view/startdate? 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: Moving to browser views
Charlie Clark wrote:
I making my first stab at browser views for my iCal support having
finally come up with some templates that seem to produce files that work
with most calendar programs.
I have a couple of questions:
1) should I implement them as BrowserViews calling templates or should I
use an adapter? The templates are TAL and the only difference to an HTML
page is the different response header.
2) how do I pass in values derived specifically for these views? ie.
going from
options = {}
options['name'] = charlie
...
return context.mytemplate(**options)
to the appropriate call inside a browser view. I haven't been able to
work this out based on the examples or the Zope 3 book.
shameless-plug
You know, I wrote a whole book for learning how to use this Zope 3
stuffm (and that includes explanations of how to use it in Zope 2 via Five).
/shameless-plug
--
http://worldcookery.com -- Professional Zope documentation and training
___
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: Moving to browser views
Charlie Clark, on 2007-07-18: Okay, thanks! I'm nearly there. I think. %-? ;-) Because I'm only creating essentially a slightly different view of an event I've taken the ZCML for the standard view as a lead: browser:page for=Products.CMFCalendar.interfaces.IEvent layer=Products.CMFDefault.interfaces.ICMFDefaultSkin name=event_iCal_view class=.event.EventiCalView permission=zope2.View / is event_iCal_view my view class? No, that is the name. That means you can do tal:define=view context/@@event_iCal_view in a template that has an IEvent provider as context. The class is the EventiCalView class in event.py. So, let's say I need to turn my creation date into 20030127T09Z I can call this in my view class via self.startdate = self.context.CreationDate() and call this in my template via view/startdate? Yes. You need to do the tal:define above first though, unless there is some other magic (well, code) that hooks up this view to that specific template. I think that is done when you specify template=mytemplate in the zcml snippet. -- 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
Re: [Zope-CMF] Re: Moving to browser views
Am 18.07.2007 um 23:03 schrieb Philipp von Weitershausen: shameless-plug You know, I wrote a whole book for learning how to use this Zope 3 stuffm (and that includes explanations of how to use it in Zope 2 via Five). /shameless-plug No need to be shameless, Mr. Gallagher! I've got the book and am working my way through it. It's very good but it didn't cover this in quite the detail I need. 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: Moving to browser views
Am 18.07.2007 um 23:10 schrieb Maurits van Rees: No, that is the name. That means you can do tal:define=view context/@@event_iCal_view in a template that has an IEvent provider as context. The class is the EventiCalView class in event.py. Yes, thanks. So, let's say I need to turn my creation date into 20030127T09Z I can call this in my view class via self.startdate = self.context.CreationDate() and call this in my template via view/startdate? Yes. You need to do the tal:define above first though, unless there is some other magic (well, code) that hooks up this view to that specific template. Actually I don't define the view explicitly in the template as my class calls it directly. I think that is done when you specify template=mytemplate in the zcml snippet. Well, I've now got two classes (EventvCalView has to set different headers so I can't see an easy way round this in ZCML) and two different templates. Everything is working fine apart from the content-type is remaining steadfastly text/html! Content-Disposition is being set correctly. How do I fix this? ;-) Tomorrow I'll try and write the tests for this so that I can submit the patch. And I'll also have something to talk about at the Rheinland ZUG meeting on Friday! ;-) 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: Moving to browser views
Am 18.07.2007 um 23:32 schrieb Charlie Clark: Well, I've now got two classes (EventvCalView has to set different headers so I can't see an easy way round this in ZCML) and two different templates. Everything is working fine apart from the content-type is remaining steadfastly text/html! Content- Disposition is being set correctly. How do I fix this? ;-) mm, calling the template gets the response header reset... 1) call the template 2) set the headers 3) write the response 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
