Re: [Zope-CMF] [dev] CMF 2.2 plans?
Hi! Martin Aspeli wrote: Jens Vagelpohl wrote: I'll look at CMFCore and CMFDefault over the next few days (I'm traveling). Are there any code changes that you still need or is the current trunk state ready to be released from your point of view? I haven't looked into it in great detail, but from what I can tell, these things are al stable. Yuppie would know best, though. There are 2 issues I'd like to see resolved before a beta is released: 1.) look up add view actions in a different way --- The current implementation is not flexible enough. There is no way to sort or group these actions. This is on my todo list, but I still have to write a proposal. 2.) get rid of redundant type info properties - See http://mail.zope.org/pipermail/zope-cmf/2009-January/028059.html Unfortunately nobody seems to feel responsible for this. We also should decide when to switch from zope.formlib to z3c.form. I have no ambitions to maintain zope.formlib based code for a long time. If we make Zope 2.12 the required platform for CMF 2.2 we can easily add z3c.form to the dependencies and refactor existing forms. Or we could move the forms and other views to a separate package. That way CMFDefault would not depend on zope.formlib nor on z3c.form. 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] [dev] CMF 2.2 plans?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 2, 2009, at 11:30 , Hanno Schlichting wrote: yuppie wrote: 2.) get rid of redundant type info properties - See http://mail.zope.org/pipermail/zope-cmf/2009-January/028059.html Unfortunately nobody seems to feel responsible for this. My mail had: I have one small todo item on my list regarding the changes to content type icons. I'm referring to the same thing here. Without any release date planned whatsoever, it wasn't high on my list so far ;) Apparently having CMF betas is high on your list, so this todo should be one step higher, obviously :-P jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmrtecACgkQRAx5nvEhZLIwagCfQzSum38mhGRzZ3s4i/ezWYx1 U+sAoKi8ck73HR1XhgUawXwBVheLEFf1 =YocE -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
[Zope-CMF] CMF Tests: 6 OK
Summary of messages to the cmf-tests list. Period Sun Mar 1 12:00:00 2009 UTC to Mon Mar 2 12:00:00 2009 UTC. There were 6 messages: 6 from CMF Tests. Tests passed OK --- Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.6 : Linux From: CMF Tests Date: Sun Mar 1 20:48:22 EST 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-March/010993.html Subject: OK : CMF-2.1 Zope-2.11 Python-2.4.6 : Linux From: CMF Tests Date: Sun Mar 1 20:50:25 EST 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-March/010994.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.6 : Linux From: CMF Tests Date: Sun Mar 1 20:52:27 EST 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-March/010995.html Subject: OK : CMF-trunk Zope-2.11 Python-2.4.6 : Linux From: CMF Tests Date: Sun Mar 1 20:54:27 EST 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-March/010996.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.6 : Linux From: CMF Tests Date: Sun Mar 1 20:56:28 EST 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-March/010997.html Subject: OK : CMF-trunk Zope-trunk Python-2.5.4 : Linux From: CMF Tests Date: Sun Mar 1 20:58:28 EST 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-March/010998.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
Re: [Zope-CMF] [dev] CMF 2.2 plans?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: Hi! Martin Aspeli wrote: Jens Vagelpohl wrote: I'll look at CMFCore and CMFDefault over the next few days (I'm traveling). Are there any code changes that you still need or is the current trunk state ready to be released from your point of view? I haven't looked into it in great detail, but from what I can tell, these things are al stable. Yuppie would know best, though. There are 2 issues I'd like to see resolved before a beta is released: 1.) look up add view actions in a different way --- The current implementation is not flexible enough. There is no way to sort or group these actions. This is on my todo list, but I still have to write a proposal. Hmm, I don't recall the issue here. 2.) get rid of redundant type info properties - See http://mail.zope.org/pipermail/zope-cmf/2009-January/028059.html Unfortunately nobody seems to feel responsible for this. We also should decide when to switch from zope.formlib to z3c.form. I have no ambitions to maintain zope.formlib based code for a long time. If we make Zope 2.12 the required platform for CMF 2.2 we can easily add z3c.form to the dependencies and refactor existing forms. I'm actually uncomfortable with either dependency. Or we could move the forms and other views to a separate package. That way CMFDefault would not depend on zope.formlib nor on z3c.form. I would favor the latter. cmf.forms, maybe? 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 iD8DBQFJrBEE+gerLs4ltQ4RApJJAJ9o8uut5gbE3UtHQWfD7yOQYEVikQCeMcVG HQhtPZ8IdGGAfpoOP8Ywmjs= =ShhR -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] [dev] CMF 2.2 plans?
Hi! Tres Seaver wrote: yuppie wrote: 1.) look up add view actions in a different way --- The current implementation is not flexible enough. There is no way to sort or group these actions. This is on my todo list, but I still have to write a proposal. Hmm, I don't recall the issue here. There wasn't much discussion about this. Some time ago Dieter asked for grouping support: http://mail.zope.org/pipermail/zope-cmf/2008-September/027776.html And I am missing a way to control the order of the add actions. The latter could be resolved by making the types tool an ordered container. But I tend to use special IActionCategory objects in the actions tool instead. They would look up the add actions in the types tool and provide features like filtering and sorting. The current mechanism was never released, so I'd rather change that now than after a release. We also should decide when to switch from zope.formlib to z3c.form. I have no ambitions to maintain zope.formlib based code for a long time. If we make Zope 2.12 the required platform for CMF 2.2 we can easily add z3c.form to the dependencies and refactor existing forms. I'm actually uncomfortable with either dependency. Or we could move the forms and other views to a separate package. That way CMFDefault would not depend on zope.formlib nor on z3c.form. I would favor the latter. cmf.forms, maybe? Don't know. I don't think we have the resources to maintain several kinds of full skins for CMFDefault. The browser views should *replace* the old skins and z3c.form is quite useful for writing all the necessary forms. That would mean that CMFDefault-the-example-application will depend on z3c.form. If we are going to split off the forms we need to split off all browser views and the profiles that use these views. Something like 'cmf.app' that includes all the CMFDefault stuff Plone doesn't depend on. 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] [dev] CMF 2.2 plans?
yuppie wrote: That would mean that CMFDefault-the-example-application will depend on z3c.form. If we are going to split off the forms we need to split off all browser views and the profiles that use these views. Something like 'cmf.app' that includes all the CMFDefault stuff Plone doesn't depend on. I'd be generally in favor of making the distinction between the CMFDefault-example-application and the reusable parts as used by for example Plone clearer. This can happen in two ways, though. Either move the example-application bits into a different package or move the reusable bits into one. If you are really interested in doing this work, I'd be happy to figure out what parts of CMFDefault Plone is actually using. Hanno ___ 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] [dev] CMF 2.2 plans?
Am 02.03.2009 um 19:27 schrieb yuppie: This is on my todo list, but I still have to write a proposal. Hmm, I don't recall the issue here. There wasn't much discussion about this. Some time ago Dieter asked for grouping support: http://mail.zope.org/pipermail/zope-cmf/2008-September/027776.html I'm still struggling with the abolition of TypeInfo actions so I'd appreciate more discussion or simply explanation of this. Or we could move the forms and other views to a separate package. That way CMFDefault would not depend on zope.formlib nor on z3c.form. I would favor the latter. cmf.forms, maybe? Don't know. I don't think we have the resources to maintain several kinds of full skins for CMFDefault. The browser views should *replace* the old skins and z3c.form is quite useful for writing all the necessary forms. I agree on both those points. In fact I'd rather reorder CMFDefault to use packages for each content type with their own dedicated browser folder and views and the same for the tools. For me the only thing is whether CMFDefault/formlib is in the right place. Tres, is this what you're referring to with by cmf.form(lib)? This itself will depend on whichever library we're using - which I think will be z3c.forms post CMF 2.2 That would mean that CMFDefault-the-example-application will depend on z3c.form. If we are going to split off the forms we need to split off all browser views and the profiles that use these views. Something like 'cmf.app' that includes all the CMFDefault stuff Plone doesn't depend on. I'm not sure if that is a win. Moving to views should, at some point, allow us to deprecate non-view object rendering. But maybe that is a separate point? 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 https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CMF 2.2 plans?
Am 02.03.2009 um 19:46 schrieb Hanno Schlichting: This can happen in two ways, though. Either move the example- application bits into a different package or move the reusable bits into one. If you are really interested in doing this work, I'd be happy to figure out what parts of CMFDefault Plone is actually using. I think this is essential. While I maintain the CMFDefault is an excellent start for many websites, Plone should not be *directly* dependent upon it - there are just too many conceptional differences and by now also too many stylistic ones as well. 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 https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CMF 2.2 plans?
Previously Charlie Clark wrote: Am 02.03.2009 um 19:46 schrieb Hanno Schlichting: This can happen in two ways, though. Either move the example- application bits into a different package or move the reusable bits into one. If you are really interested in doing this work, I'd be happy to figure out what parts of CMFDefault Plone is actually using. I think this is essential. While I maintain the CMFDefault is an excellent start for many websites, Plone should not be *directly* dependent upon it - there are just too many conceptional differences and by now also too many stylistic ones as well. +1 This goes in two ways: some bits of CMFCore should probably be in CMFDefault as well. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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
