[Zope-CMF] cmf-tests - OK: 8
This is the summary for test reports received on the cmf-tests list between 2012-09-06 00:00:00 UTC and 2012-09-07 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received CMF-2.2 Zope-2.12 Python-2.6.8 : Linux CMF-2.2 Zope-2.13 Python-2.6.8 : Linux CMF-2.3 Zope-2.13 Python-2.6.8 : Linux CMF-2.3 Zope-trunk Python-2.6.8 : Linux CMF-trunk Zope-2.13 Python-2.6.8 : Linux CMF-trunk Zope-2.13 Python-2.7.3 : Linux CMF-trunk Zope-trunk Python-2.6.8 : Linux CMF-trunk Zope-trunk Python-2.7.3 : Linux Non-OK results -- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Security declarations on adapters
Hi Charlie! Charlie Clark wrote: Am 07.09.2012, 09:01 Uhr, schrieb yuppie : And I have a quick and dirty view implementation for local role/sharing. Reimplementing it based on formlib would be a lot of work, so maybe I should just check in my code. As I'm not even sure what it does I'd definitely suggest you check it in. Ok. I'd also be very interested in your "skinless" workaround. As luck would have it I was discussing CMF with someone and I think we should have it in the docs somewhere. Well. Basically it works out of the box. If you have a complete ZTK skin, you can delete the skins tool. The sites I converted just use the features that already have browser views in CMFDefault or customized browser views in my own code, so missing views like those for discussion were no problem. The biggest issue I had to fight with is the fact that zope.browserresource (or the Zope 2 specific version in Five) is much harder to use than static resources in a CMF DirectoryView. Some packages exist that try to provide better resources support, but I'm not aware of any package that resolves my issues. I really don't want to register each icon separately in zcml, but I want to be able to override single icons. And I want to have some control over the urls of the resources. I want files like 'robots.txt' and 'favicon.ico' in the root, other resources in subdirectories like 'images' or 'resources'. Currently I use browser:resourceDirectory to register one resources directory per layer, and a special view that walks through directlyProvidedBy(request).__iro__ to find the first layer that contains the requested resource. This is an expensive hack, but does what I need. I'm still fighting with HEAD and PROPFIND requests for resources. So far I wasn't able to figure out how ZTK handles these. The errors returned by Zope 2 are not useful. Some clients retry those requests several times because they interpret the errors as temporary. I would also like to add a quick install guide for anyone wanting to use CMFDefault as a springboard. Not sure what exactly you mean by springboard in this context. I didn't propose to pack all this in CMF 2.3. My list also contains the next steps after the release. Where is the list? I didn't mean a big list. Just the few steps I mentioned in the previous mail. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Security declarations on adapters
Hi Charlie! Charlie Clark wrote: Am 07.09.2012, 09:01 Uhr, schrieb yuppie : [-] means that we don't want/need to convert this [?] means that we still have to decide if and how this should be converted [/] means unfinished Regarding RSS: you've written [/] ISyndicatable @@rss.xml (not hooked up): - [x] RSS.py -> rss.View - [x] RSS_template.pt -> rss.pt - [?] rssDisabled.pt What do you mean by not hooked up? There's not an appropriate action but the template is configured. As syndicatability is determined by a marker interface I don't think we need to have a disabled view for it. Maybe there are better words for this. It's not really relevant at the moment. I have plans to use the same todos for the related changes in profiles or code that links to the views. It just means that no Action or code in CMFDefault links to the RSS feed, so there is nothing that needs to be updated. I'm fine with not providing a disabled view. BTW: If scripts or templates like TitleOrId.py show up in different contexts, that doesn't have to be a mistake. I did this if I expect they'll become part of different views instead of sharing one implementation. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Security declarations on adapters
Hi Yuppie, Am 07.09.2012, 09:01 Uhr, schrieb yuppie : [-] means that we don't want/need to convert this [?] means that we still have to decide if and how this should be converted [/] means unfinished Regarding RSS: you've written [/] ISyndicatable @@rss.xml (not hooked up): - [x] RSS.py -> rss.View - [x] RSS_template.pt -> rss.pt - [?] rssDisabled.pt What do you mean by not hooked up? There's not an appropriate action but the template is configured. As syndicatability is determined by a marker interface I don't think we need to have a disabled view for it. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Security declarations on adapters
Am 07.09.2012, 09:01 Uhr, schrieb yuppie : I have additional data, but still have to verify it and merge it into the CMF trunk todos. Just updated the todo for 'content' and added one for 'skins'. [-] means that we don't want/need to convert this [?] means that we still have to decide if and how this should be converted [/] means unfinished Thanks for the clarification. Some of the issues mentioned in 'content' might now belong into 'discussion'. Please update the todos according to your changes. Will do. And I have a quick and dirty view implementation for local role/sharing. Reimplementing it based on formlib would be a lot of work, so maybe I should just check in my code. As I'm not even sure what it does I'd definitely suggest you check it in. I'd also be very interested in your "skinless" workaround. As luck would have it I was discussing CMF with someone and I think we should have it in the docs somewhere. I would also like to add a quick install guide for anyone wanting to use CMFDefault as a springboard. I thought we'd agreed not to make them the default for this release but remove the "experimental" label from the profile. Personally, I would like to see them as the default, not least because they nearly all have coverage. But, we shouldn't be packing too much into a single release. Maybe because you work with trunk you notice less? I didn't propose to pack all this in CMF 2.3. My list also contains the next steps after the release. Where is the list? Off the top of my head: correcting the docs. There are also duplicate DCWorkflow docs. Someone has to figure out if the old .stx docs are redundant and obsolete. There are equivalents for all .stx as .rst. I thought I had moved the files over but apparently not. I don't know what to do about the examples. But the .stx files can go. You moved the docs to the new place, so why didn't/don't you remove the obsolete files yourself? It was sort of rhetorical. I thought I'd done svn move, to preserve the history. But considering the refactoring I guess I didn't. I'll pull the .stx Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Security declarations on adapters
Hi Charlie! Charlie Clark wrote: Am 06.09.2012, 16:24 Uhr, schrieb yuppie : There are the (incomplete) todo lists for browser views. I'd also like to revisit the names we did choose for the views and make them the default target of Actions. hm, I drew up the lists from the existing Scripts/Templates and thought it was complete. I've just checked again and can only find the following as not done: - [?] viewThreadsAtBottom.pt (structure) - [?] talkback_tree.pt (macros) - [?] setup_talkback_tree.py - [?] discitem_delete.py I have additional data, but still have to verify it and merge it into the CMF trunk todos. Just updated the todo for 'content' and added one for 'skins'. [-] means that we don't want/need to convert this [?] means that we still have to decide if and how this should be converted [/] means unfinished Some of the issues mentioned in 'content' might now belong into 'discussion'. Please update the todos according to your changes. And I have a quick and dirty view implementation for local role/sharing. Reimplementing it based on formlib would be a lot of work, so maybe I should just check in my code. I thought we'd agreed not to make them the default for this release but remove the "experimental" label from the profile. Personally, I would like to see them as the default, not least because they nearly all have coverage. But, we shouldn't be packing too much into a single release. Maybe because you work with trunk you notice less? I didn't propose to pack all this in CMF 2.3. My list also contains the next steps after the release. Off the top of my head: correcting the docs. There are also duplicate DCWorkflow docs. Someone has to figure out if the old .stx docs are redundant and obsolete. There are equivalents for all .stx as .rst. I thought I had moved the files over but apparently not. I don't know what to do about the examples. But the .stx files can go. You moved the docs to the new place, so why didn't/don't you remove the obsolete files yourself? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
