[Zope-CMF] Re: CMF 2.0 Release Status
Hi Martin! Martin Aspeli wrote: I had a browse through the code at http://svn.zope.org/CMF/trunk/CMFCore/interfaces. This work is interesting to me not at least because it will enable us to write against CMF (and hopefully Plone soon) code using Z3 idioms (e.g. accessing things through interfaces, making it possible to use adapters etc.) I think the migration path here has to be to get all the interfaces in place first, and then gradually refactor code to work through these interfaces as necessary. However, I notice that none of the manage_* methods are not there, and that many things have accessors only. I haven't looked at it in the detail, but I'm wondering what the policy is here. For things like setup scripts or control panel views or whatnot, being able to mutate the values in tools (http://svn.zope.org/CMF/trunk/CMFCore/interfaces/_tools.py) and elsewhere (e.g. just setting dumb properties) would seem a necessary of the interface. Am I missing something? Those interfaces are just a first step. The fact they exist doesn't mean that all the z2 mess is cleaned up and all classes have now well defined interfaces. If you look e.g. at the adapters in CMFCore/exportimport you'll see they are cheating a lot. Most of them use methods that are not part of the interface they adapt. Surely that's not optimal. Converting the interfaces to z3 interfaces I did follow this policy: - All properties and methods including their signature have to exist in the class. This has to be verified by verifyClass unit tests. - The descriptions in the interfaces should be in sync with the actual implementation. - Not to add private methods has a higher priority than making the interfaces complete. Adding methods to the interfaces implies a commitment to maintain that API. We lose a lot of flexibility if we just add all existing methods to the interfaces. An incomplete interface is better than no interface. - Everything should go into the right software layer. Interfaces like IPropertyManager or IObjectManager should be maintained in the Zope core. That means there is still a lot of work necessary to find out which methods should become part of the API and which parts of the public API should be deprecated, modified or made private. Not just in the CMF, but also in Zope. Cheers, 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: CMF 2.0 Release Status
Hi, On Wed, 11 Jan 2006 18:42:08 -, Tres Seaver <[EMAIL PROTECTED]> wrote: I'd like to review the current status of a number of the CMF 2.0 roadmap items, and ask for feedback from the community on how they fit into a near-term release of a beta for CMF 2.0. In fact, I would like to release an alpha this weekend, followed by a more-or-less feature complete beta by the end of the month. I have "posted a blog entry,", http://palladion.com/home/tseaver/obzervationz/2006/cmf_2_0_update_20060111 summarizing what I think is the current status of the project. Please comment here on ths list, correcting my mistakes or omissions, as well as responding to the "open questions" section. I had a browse through the code at http://svn.zope.org/CMF/trunk/CMFCore/interfaces. This work is interesting to me not at least because it will enable us to write against CMF (and hopefully Plone soon) code using Z3 idioms (e.g. accessing things through interfaces, making it possible to use adapters etc.) I think the migration path here has to be to get all the interfaces in place first, and then gradually refactor code to work through these interfaces as necessary. However, I notice that none of the manage_* methods are not there, and that many things have accessors only. I haven't looked at it in the detail, but I'm wondering what the policy is here. For things like setup scripts or control panel views or whatnot, being able to mutate the values in tools (http://svn.zope.org/CMF/trunk/CMFCore/interfaces/_tools.py) and elsewhere (e.g. just setting dumb properties) would seem a necessary of the interface. Am I missing something? Martin -- (muted) ___ 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: CMF 2.0 Release Status
On 1/13/06, David Pratt <[EMAIL PROTECTED]> wrote: > Hi Lennart. Isn't CPSSkins GPL? Probably. > I would prefer a generic approach that > compatible with the ZPL. Why? > Would CPSSkins license be changed under this > scenario? I am sure there are others like me that do not develop under > GPL Yeah, I have heard weird rumours to that effect. ;) But you don't need to develop under GPL, CPSSkins is a finished product already, you can just install it. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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: CMF 2.0 Release Status
Lennart Regebro wrote: On 1/12/06, Martin Aspeli <[EMAIL PROTECTED]> wrote: One is CPSSkins, where you in practice has a dedicated WYSIWYG editor for changing the layouts and CSS of a site. It can be argued that CPSSkins is too complex as it is now, and not very user friendly, but it requires zero knowledge of either HTML or TAL. Hi Lennart. Isn't CPSSkins GPL? I would prefer a generic approach that compatible with the ZPL. Would CPSSkins license be changed under this scenario? I am sure there are others like me that do not develop under GPL that are keen to continue Zope2/Zope3 under the ZPL. Many thanks. Regards, David ___ 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: CMF 2.0 Release Status
Hi Tres! Tres Seaver wrote: yuppie wrote: I agree with your concerns. Views and the FiveActionsTool both use Five/Zope3 technology for the price of dropping TTW/GenericSetup support and introducing a second way to do the same things. Hmm, I'm not sure I see how we are trading away GenericSetup support. I was under the FiveActonsTool *supplements* the stock action providers, exposing Zope3 menu items as actions. Yes. But those supplemental Actions are not managed through GenericSetup. It would be easy to ship Five products with a setup profile that sets up the Actions. I'm sure they anyway need somme CMF specific setup. A major advantage of GenericSetup over ZCML is the ability to change the configuration TTW and write it back to the file system. While I didn't vote for including the FiveActionsTool into the CMF core I support the effort to move to views. But we are not there yet and I doubt we'll have view based skins in CMF 2.0 that can fully replace the old CMF skins. I imagine that we may be able to ship a separate "Five-aware" setup profile, and allow folks to use it as an alternative. Likely we can configure the views into place in either case, but have the "stock" profile surface the skin methods / templates rather than views. The TTW features are a strength of the CMF. The fact that Tres and Phillip plan to sprint on local skin customization for CMF 2.1 is good news. As I already said in an other mail I would not enable views by default in CMF 2.0. For now I consider them an experimental feature of the CMF that advanced users can enable if they want. As soon as customization and other issues are resolved views should replace the old skins machinery. In particular, the cost of TTW flexibility is pretty high, both in terms of performance and maintainability. Shipping a version of the CMF which allows folks who *don't* need or want the flexibility to avoid paying those costs will be a win. I guess those folks will enable the views using ZCML. But it sounds like a good idea to provide a setup profile that disables stuff that's not needed in that case. Cheers, 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: CMF 2.0 Release Status
On 1/12/06, Martin Aspeli <[EMAIL PROTECTED]> wrote: > Do I have to make a package, with new content > type and a pile of ZCML just because I want my Description to be at the > bottom rather than the top of my Document view? One zcml statement is not exactly "a pile". :) > That's a fairly drastic > reduction in functionality and friendliness for the average Joe, don't you > think? No, I don't really. Sure, the current way of "press customize and change" is very easy, *if* you understand HTML, and TAL and CMF. But understanding HTML, TAL and CMF is not what I would call being friendly to the average joe. ;) For the type of functionality you are discussing, I think there are two paths you can take that are truly user friendly. One is CPSSkins, where you in practice has a dedicated WYSIWYG editor for changing the layouts and CSS of a site. It can be argued that CPSSkins is too complex as it is now, and not very user friendly, but it requires zero knowledge of either HTML or TAL. The other way is the expert way, where you use HTML editors, or even just text editors to directly edit the template code. If you are capable of doing that, then surely you are capable of typing in overrides.zcml? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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: CMF 2.0 Release Status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: > Martin Aspeli wrote: > >> The only thing that bothers me is the lack of local skin >> customisations. Does that mean that there is *no* way to e.g. overide >> document_view.pt or whatever else? Or just no TTW way? In fact, I'm -1 >> on releasing with either limitation, but I think having no way of >> doing local skin customisations is a major drawback, and would be >> show-stopper as far as I'm concerned. At least in the Plone sphere, >> skin customisations is generally the first thing people do, and one of >> the things that make them like the stack - how easy it is to make >> UI-level changes (which is all a lot of people want to do). Do I have >> to make a package, with new content type and a pile of ZCML just >> because I want my Description to be at the bottom rather than the top >> of my Document view? That's a fairly drastic reduction in >> functionality and friendliness for the average Joe, don't you think? > > > I agree with your concerns. Views and the FiveActionsTool both use > Five/Zope3 technology for the price of dropping TTW/GenericSetup support > and introducing a second way to do the same things. Hmm, I'm not sure I see how we are trading away GenericSetup support. I was under the FiveActonsTool *supplements* the stock action providers, exposing Zope3 menu items as actions. > While I didn't vote for including the FiveActionsTool into the CMF core > I support the effort to move to views. But we are not there yet and I > doubt we'll have view based skins in CMF 2.0 that can fully replace the > old CMF skins. I imagine that we may be able to ship a separate "Five-aware" setup profile, and allow folks to use it as an alternative. Likely we can configure the views into place in either case, but have the "stock" profile surface the skin methods / templates rather than views. > The TTW features are a strength of the CMF. The fact that Tres and > Phillip plan to sprint on local skin customization for CMF 2.1 is good > news. As I already said in an other mail I would not enable views by > default in CMF 2.0. For now I consider them an experimental feature of > the CMF that advanced users can enable if they want. As soon as > customization and other issues are resolved views should replace the old > skins machinery. In particular, the cost of TTW flexibility is pretty high, both in terms of performance and maintainability. Shipping a version of the CMF which allows folks who *don't* need or want the flexibility to avoid paying those costs will be a win. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDx6Bq+gerLs4ltQ4RAvH3AJ4h2grhCO2XnwHI+VxC6P0OdiBHZACgkkGr eMmldLTpMMcFz6FYlRsGx8U= =jlIv -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: CMF 2.0 Release Status
Hi Martin! Martin Aspeli wrote: The only thing that bothers me is the lack of local skin customisations. Does that mean that there is *no* way to e.g. overide document_view.pt or whatever else? Or just no TTW way? In fact, I'm -1 on releasing with either limitation, but I think having no way of doing local skin customisations is a major drawback, and would be show-stopper as far as I'm concerned. At least in the Plone sphere, skin customisations is generally the first thing people do, and one of the things that make them like the stack - how easy it is to make UI-level changes (which is all a lot of people want to do). Do I have to make a package, with new content type and a pile of ZCML just because I want my Description to be at the bottom rather than the top of my Document view? That's a fairly drastic reduction in functionality and friendliness for the average Joe, don't you think? I agree with your concerns. Views and the FiveActionsTool both use Five/Zope3 technology for the price of dropping TTW/GenericSetup support and introducing a second way to do the same things. While I didn't vote for including the FiveActionsTool into the CMF core I support the effort to move to views. But we are not there yet and I doubt we'll have view based skins in CMF 2.0 that can fully replace the old CMF skins. The TTW features are a strength of the CMF. The fact that Tres and Phillip plan to sprint on local skin customization for CMF 2.1 is good news. As I already said in an other mail I would not enable views by default in CMF 2.0. For now I consider them an experimental feature of the CMF that advanced users can enable if they want. As soon as customization and other issues are resolved views should replace the old skins machinery. Cheers, 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: CMF 2.0 Release Status
Martin Aspeli wrote: > ... Does that mean that there is *no* way to e.g. overide > document_view.pt or whatever else? Or just no TTW way? Basically it means no TTW way. You should be able to override view component definitions with overrides.zcml. But regarding the TTW customization, I happen to know some of the brightest Zope minds are brainstorming on these things :) - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ 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: CMF 2.0 Release Status
On 12 Jan 2006, at 22:10, Martin Aspeli wrote: The only thing that bothers me is the lack of local skin customisations. Does that mean that there is *no* way to e.g. overide document_view.pt or whatever else? Or just no TTW way? In fact, I'm -1 on releasing with either limitation, but I think having no way of doing local skin customisations is a major drawback, and would be show-stopper as far as I'm concerned. At least in the Plone sphere, skin customisations is generally the first thing people do, and one of the things that make them like the stack - how easy it is to make UI-level changes (which is all a lot of people want to do). Do I have to make a package, with new content type and a pile of ZCML just because I want my Description to be at the bottom rather than the top of my Document view? That's a fairly drastic reduction in functionality and friendliness for the average Joe, don't you think? The version of Plone that may use a version of CMF 2.x is far far away as far as I can tell. This is not a showstopper for the 2.0 release. jens ___ 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: CMF 2.0 Release Status
On Wed, 11 Jan 2006 18:42:08 -, Tres Seaver <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 First, many thanks to all who have contributed toe the CMF 2.0 effort! I'd like to review the current status of a number of the CMF 2.0 roadmap items, and ask for feedback from the community on how they fit into a near-term release of a beta for CMF 2.0. In fact, I would like to release an alpha this weekend, followed by a more-or-less feature complete beta by the end of the month. I have "posted a blog entry,", http://palladion.com/home/tseaver/obzervationz/2006/cmf_2_0_update_20060111 summarizing what I think is the current status of the project. Please comment here on ths list, correcting my mistakes or omissions, as well as responding to the "open questions" section. What a nice surprise :) I had no idea this was so far along. Great effort! Are the new features documented or demonstrated anywhere in particular? This would make it easier for Plone to know how to take advantage of CMF 2, for instance. The only thing that bothers me is the lack of local skin customisations. Does that mean that there is *no* way to e.g. overide document_view.pt or whatever else? Or just no TTW way? In fact, I'm -1 on releasing with either limitation, but I think having no way of doing local skin customisations is a major drawback, and would be show-stopper as far as I'm concerned. At least in the Plone sphere, skin customisations is generally the first thing people do, and one of the things that make them like the stack - how easy it is to make UI-level changes (which is all a lot of people want to do). Do I have to make a package, with new content type and a pile of ZCML just because I want my Description to be at the bottom rather than the top of my Document view? That's a fairly drastic reduction in functionality and friendliness for the average Joe, don't you think? Martin -- (muted) ___ 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: CMF 2.0 Release Status
Jens Vagelpohl wrote: As far as the Zope target platform for CMF 2.0 goes, I was under the impression it had already quietly slipped to 2.9, even though there was never any announcement ;) Plone will probably be on CMF 1.5/1.6 in the near term rather than 2.0, so IMHO that is an argument in favor of simplifying CMF's Zope support to just 2.9 and over. This ties into the second question, which Plone core developers can answer better, about the plans for which version of Plone will go with which version of CMF. As an added question, how does the CPS release plan relate to the CMF? CPS 3.4.0 will be in beta before the end of the week. We require Zope 2.9.0 and ship with a CMF 1.6 snapshot to take full advantage of GenericSetup, and probably with a fixed Five 1.3.1 snapshot as well. Florent PS: I'll answer about the other questions relating to events later or tomorrow. -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [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] Re: CMF 2.0 Release Status
On 12 Jan 2006, at 12:44, Lennart Regebro wrote: On 1/12/06, yuppie <[EMAIL PROTECTED]> wrote: +1 for dropping Zope 2.8 support On that, it can be mentioned that for the fiveactions tool, having both 2.8 and 2.9 support requires quite some work and code duplication, so I'm +N on dropping 2.8, where N is an arbitrarily large positive number. :) +1 from me as well then jens ___ 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: CMF 2.0 Release Status
On 1/12/06, yuppie <[EMAIL PROTECTED]> wrote: > +1 for dropping Zope 2.8 support On that, it can be mentioned that for the fiveactions tool, having both 2.8 and 2.9 support requires quite some work and code duplication, so I'm +N on dropping 2.8, where N is an arbitrarily large positive number. :) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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: CMF 2.0 Release Status
Hi Tres! Tres Seaver wrote: I'd like to review the current status of a number of the CMF 2.0 roadmap items, and ask for feedback from the community on how they fit into a near-term release of a beta for CMF 2.0. In fact, I would like to release an alpha this weekend, followed by a more-or-less feature complete beta by the end of the month. I have "posted a blog entry,", http://palladion.com/home/tseaver/obzervationz/2006/cmf_2_0_update_20060111 summarizing what I think is the current status of the project. Please comment here on ths list, correcting my mistakes or omissions, as well as responding to the "open questions" section. Viewification There is also the goldegg-folder_contents branch which contains a quick 'n' dirty folder_contents view. I can try to port it to the tseaver-viewification branch. As long as we don't have a solution for the local skin customization I'd not like to see the views enabled by default. What about keeping the old skins as default for 2.0? People who want to use the views instead can easily enable them using ZCML. GenericSetup I believe it was the Right Thing to split responsibilities for content setup and configuration setup. This way we were able to move faster forward. But the downside is that we implemented similar tasks in different ways. Don't know if trying to share more code is worth the effort. At least we should find a solution for the minimal site structure currently set up by CMFDefault.setuphandlers.importVarious. I tried to use the content handler for that, but that adds the complete site content to a snapshot. Any ideas how to resolve this? I'd really like to get rid of importVarious. Required Zope Version +1 for dropping Zope 2.8 support Cheers, 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: CMF 2.0 Release Status
On Wed, 11 Jan 2006 20:00:18 +0100, Jens Vagelpohl <[EMAIL PROTECTED]> wrote: This ties into the second question, which Plone core developers can answer better, about the plans for which version of Plone will go with which version of CMF. Plone 2.5 (the next release, due this spring) will use CMF 1.6, and I believe the goal is for Plone 3.0 to use CMF 2.0. I'm not the release manager, though - status of the latter is still undecided, since it is still some time away. I assume Zope 2.10 will be out by then. http://plone.org/roadmap -- _ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone ___ 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