[Zope-CMF] CMF Tests: 6 OK
Summary of messages to the cmf-tests list. Period Wed Dec 10 12:00:00 2008 UTC to Thu Dec 11 12:00:00 2008 UTC. There were 6 messages: 6 from CMF Tests. Tests passed OK --- Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.5 : Linux From: CMF Tests Date: Wed Dec 10 20:51:39 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-December/010525.html Subject: OK : CMF-2.1 Zope-2.11 Python-2.4.5 : Linux From: CMF Tests Date: Wed Dec 10 20:53:09 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-December/010526.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.5 : Linux From: CMF Tests Date: Wed Dec 10 20:54:39 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-December/010527.html Subject: OK : CMF-trunk Zope-2.11 Python-2.4.5 : Linux From: CMF Tests Date: Wed Dec 10 20:56:09 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-December/010528.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.5 : Linux From: CMF Tests Date: Wed Dec 10 20:57:39 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-December/010529.html Subject: OK : CMF-trunk Zope-trunk Python-2.5.2 : Linux From: CMF Tests Date: Wed Dec 10 20:59:09 EST 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-December/010530.html ___ 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] GenericSetup 1.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I would like to get a 1.5 release of GenericSetup out over the holidays. Here is what I have on the roadmap: - Clean up the sphinx docs for the package, incorporating / updating Rob Miller's excellent tutorial on GS (Rob has already blessed the notion). - Make *much* clearer the idea that content export / import should not be treated as part of any normal profile, including adding some extra support for doing that task at the application level. - Tidy up any deprecations when running under Python 2.5 (and maybe even 2.6). Anyone have other stuff they would like to see in the mix (and can help land)? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com 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 iD8DBQFJQUtL+gerLs4ltQ4RAoDIAJ9HV0NtsTLj/HHxJRcmjeaRPuCI7ACfTQCF 9AF0Pk2jMOdmMTpvgb2ejME= =u2g+ -END PGP SIGNATURE- ___ 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 add views and browser:page /
Hi! Martin Aspeli wrote: Martin Aspeli wrote: Mmmm... I'm not sure most people would find it natural to think about the add form as an adapter like this. Well. I find it natural to think about browser pages as a special kind of adapters. Having explained this to a lot of different people with different levels of experience, I think natural is too strong a word for most people. The fact that browser views are adapters is an implementation detail that often give people an aha! type reaction when they really understand it. However, a lot of people will use browser views for a long time without really understanding adapters (if they ever do or care). Well. I guess it depends on your perspective. For Plone users adapters might be implementation details, for others they are important tools for solving many different problems. I can't see a fundamental problem in using the generic adapter directive for registering browser pages. I just see limited support for the adapter directive in Zope 2. As long as these issues are not resolved, I can live with Zope 2 security declarations in add views. FWIW, I think this'll work: adapter for=Products.CMFCore.interfaces.IFolderish zope.publisher.interfaces.browser.IBrowserRequest ..interfaces.IDexterityFTI provides=zope.publisher.interfaces.browser.IBrowserView factory=.add.DefaultAddView / class class=.add.DefaultAddView require permission=cmf.AddPortalContent interface=zope.publisher.interfaces.browser.IBrowserView AFAICS this should be IBrowserPage or IPageForm, not IBrowserView. / /class I don't much like it, though. :-/ I like it ;) This is not perfect. But better than using oldstyle Zope 2 security declarations. I'll change my checkins. Meh - of course, I meant: cmf:addview name=my.type for=Products.CMFCore.interfaces.IFolderish fti=..interfaces.IDexterityFTI class=.add.DefaultAddView permission=cmf.AddPortalContent / Providing customized solutions for specific use cases makes it easier to solve these use cases, but it also makes the framework more complex and less framework-ish. I can't see a need for the directive you propose. But if you also volunteer to maintain the additional code in the long run, I can live with it. Cheers, Yuppie ___ 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] GenericSetup 1.5
Hi! Tres Seaver wrote: I would like to get a 1.5 release of GenericSetup out over the holidays. Here is what I have on the roadmap: - Clean up the sphinx docs for the package, incorporating / updating Rob Miller's excellent tutorial on GS (Rob has already blessed the notion). Great! But why didn't you remove handlers.txt and profiles.txt in GenericSetup/doc? AFAICS they are now redundant and outdated. - Make *much* clearer the idea that content export / import should not be treated as part of any normal profile, including adding some extra support for doing that task at the application level. - Tidy up any deprecations when running under Python 2.5 (and maybe even 2.6). +1 Anyone have other stuff they would like to see in the mix (and can help land)? I recently started using UpgradeSteps and would like to improve the Upgrades tab. Especially I'd like to implement useful behavior for steps that have source/destination versions *and* a checker specified. Right now the versions are mostly ignored if a checker exist. I'd like to evaluate the versions first and use the checker as an additional restriction. Also, running a step with checker should not update the current version of the profile. These changes would allow to split upgrades between versions into several task centric steps. That gives users more control over the upgrade process, doing upgrades step by step or skipping specific steps. If people agree that this doesn't require a proposal and discussion first, I could try to implement this in time for your release. Cheers, Yuppie ___ 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] GenericSetup 1.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: Hi! Tres Seaver wrote: I would like to get a 1.5 release of GenericSetup out over the holidays. Here is what I have on the roadmap: - Clean up the sphinx docs for the package, incorporating / updating Rob Miller's excellent tutorial on GS (Rob has already blessed the notion). Great! But why didn't you remove handlers.txt and profiles.txt in GenericSetup/doc? AFAICS they are now redundant and outdated. I certainly plan to review all the docs: ideally, we would have a combination of explanatory, tutorial, and reference docs. - Make *much* clearer the idea that content export / import should not be treated as part of any normal profile, including adding some extra support for doing that task at the application level. - Tidy up any deprecations when running under Python 2.5 (and maybe even 2.6). +1 Anyone have other stuff they would like to see in the mix (and can help land)? I recently started using UpgradeSteps and would like to improve the Upgrades tab. Especially I'd like to implement useful behavior for steps that have source/destination versions *and* a checker specified. Right now the versions are mostly ignored if a checker exist. I'd like to evaluate the versions first and use the checker as an additional restriction. Also, running a step with checker should not update the current version of the profile. These changes would allow to split upgrades between versions into several task centric steps. That gives users more control over the upgrade process, doing upgrades step by step or skipping specific steps. If people agree that this doesn't require a proposal and discussion first, I could try to implement this in time for your release. Sounds OK to me: note that I have never yet used UpgradeSteps myself. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com 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 iD8DBQFJQYyw+gerLs4ltQ4RAmdMAKCHDz3T9GEgmvH50D35ngzXuU5EngCfdjlO F3weQ5zXtbOnJ8GLjRtCUn4= =xUzm -END PGP SIGNATURE- ___ 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 add views and browser:page /
Hi Yuppie, Mmmm... I'm not sure most people would find it natural to think about the add form as an adapter like this. Well. I find it natural to think about browser pages as a special kind of adapters. Having explained this to a lot of different people with different levels of experience, I think natural is too strong a word for most people. The fact that browser views are adapters is an implementation detail that often give people an aha! type reaction when they really understand it. However, a lot of people will use browser views for a long time without really understanding adapters (if they ever do or care). Well. I guess it depends on your perspective. For Plone users adapters might be implementation details, for others they are important tools for solving many different problems. Adapters are of course important tools. However, the fact that browser pages are named multi-adapters that provide Interface and adapt the context object and the request, normally via a marker interface called a layer that's applied to the request during traversal, is an implementation detail, and one that requires quite a lot of explanation and even then doesn't make a whole lot of sense unless you are quite familiar with Zope 3's brand of the adapter pattern. It took me 32 words to state that as completely and concisely as I could, without even explaining any of the concepts. The concept of a named multi-adapter is an order of magnitude more advanced than, say, page templates skin layers or the concept of having a class/template that's registered in an XML file. People who are not steeped in software design patterns can learn the latter quite quickly. They struggle with the former, Plone user or not. Providing customized solutions for specific use cases makes it easier to solve these use cases, but it also makes the framework more complex and less framework-ish. Then why do we have browser:page /? You could of course do: adapter for=.interfaces.IMyType Products.CMFDefault.interfaces.ICMFDefaultLayer provides=zope.interface.Interface name=myview factory=.myview.MyView / class class=.myview.MyView require permission=zope2.View allowed_interface=zope.publisher.interfaces.browser.IBrowserPage / /class I can't see a need for the directive you propose. But if you also volunteer to maintain the additional code in the long run, I can live with it. I can probably do that, but I'd like to know if others agree. I actually don't have an immediate need for it myself, since I've implemented the same thing for my specific use case using a martian grokker, but I suspect people would prefer an analogue to browser:page / rather than having to register their add views manually. If we want people to use add forms (in Plone we certainly do - premature object creation sucks), then we need to make it easy to do so. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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
