Re: [Zope-CMF] Re: CMF roadmap update
Tres Seaver wrote: Customization is hard: without TTW modules we *can't* do customization of arbitrary view logic. What's the blocker on this? Same thing that's blocking TTW schemas? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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 roadmap update
Tres Seaver wrote: Paul Winkler wrote: I saw Philip W. do a working prototype of this at the PyCon Dallas sprints. I don't know if anything happened with this after PyCon, and it would need at least some UI work. If the UI is to integrate with the CMF skins tool, I suspect there will need to be a thin layer of CMF-specific UI written as well. IIRC, Philip's prototype just dumped the templates into the Zope root, or maybe into the current folder, I forget. I believe the work which Philipp and I did at PyCon will land for Zope 2.10 / Five 1.4. Until then, we don't have any story for view customization: sites which depend on such customization will need to continue using the skins. Once that work lands, we should be able to integrate the UI from the prototype, which shows the template-driven views for a given object, and allows creation of a new templatee in the nearest site, shadowing the global view. Are you talking about the 'zpt customization prototype' that won't be ready in time for Five 1.5/Zope 2.10 according to the log message for http://mail.zope.org/pipermail/checkins/2006-April/001310.html? I'm not happy with limiting TTW customizations to zpt customizations. That will force people to add their custom logic to the templates. The goal of views was to move in the opposite direction. But I have no time to work on something better. 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 roadmap update
I am using it rather heavily. The overengineery impression comes from the fact that it is intended to be highly pluggable (CMF-style, i.e. by replacing tools). For example I always replace the generator with something more robust than a simple counter. Using it is straight forward, you just do uid = handler.register(anObject) and anObject = handler.getObjectByUid(uid). Stefan On 25. Apr 2006, at 16:46, Jens Vagelpohl wrote: Well, I have my own opinion about that, but the course of action depends mostly on those people who are using it. No one seems to, judged by the complete silence. -- Anything that happens, happens. --Douglas Adams ___ 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 roadmap update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: Tres Seaver wrote: Paul Winkler wrote: I saw Philip W. do a working prototype of this at the PyCon Dallas sprints. I don't know if anything happened with this after PyCon, and it would need at least some UI work. If the UI is to integrate with the CMF skins tool, I suspect there will need to be a thin layer of CMF-specific UI written as well. IIRC, Philip's prototype just dumped the templates into the Zope root, or maybe into the current folder, I forget. I believe the work which Philipp and I did at PyCon will land for Zope 2.10 / Five 1.4. Until then, we don't have any story for view customization: sites which depend on such customization will need to continue using the skins. Once that work lands, we should be able to integrate the UI from the prototype, which shows the template-driven views for a given object, and allows creation of a new templatee in the nearest site, shadowing the global view. Are you talking about the 'zpt customization prototype' that won't be ready in time for Five 1.5/Zope 2.10 according to the log message for http://mail.zope.org/pipermail/checkins/2006-April/001310.html? Yes. I am most disappointed to see that work shelved for another six months. I am not convinced our release cycle is working in our favor here. I'm not happy with limiting TTW customizations to zpt customizations. That will force people to add their custom logic to the templates. The goal of views was to move in the opposite direction. Customization is hard: without TTW modules we *can't* do customization of arbitrary view logic. The templates which the prototype produced were going to enable the inline Python feature (currently possible in Z3's ZPT Page content type), which would have allowed a somewhat more manageable chunk of that use case. Those templates would then be wired together with the original view class from which the customization was done to create the overriding view. But I have no time to work on something better. Nor I. CMF can't do more than Zope2 / Zope3 / Five will support. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFET0Dq+gerLs4ltQ4RAhTXAJ4jp9UhaCX7hL+S+E1NONBuixFhbwCg2Ozu QqI2op4uKLxDj4pbRqYX6LU= =Bhn+ -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
Re: [Zope-CMF] Re: CMF roadmap update
Jens Vagelpohl wrote: I sent an email about this a couple days ago. Basically, I'm down to one failing unit test in CMFUid and have discovered that CMFUid is basically broken in 2.0/trunk. I also sent an email on this issue to the list, hoping that the developers who wrote CMFUid and lobbied hard to get it included would take notice and do something about it (or at least acknowledge it), but all I see is silence so far. At least I have found what the problem with CMFUid is, and it is mostly a misunderstanding how it is supposed to work. Mea culpa. I'm still left with the one failing unit test on the events branch, though. Having such an unknown and unmaintained piece of code in the core of the cmf scares me. How would people feel about deprecating it for 2.1 and removing it in 2.3 if no-one steps up who wants it? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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 roadmap update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25 Apr 2006, at 15:08, Chris Withers wrote: Jens Vagelpohl wrote: I sent an email about this a couple days ago. Basically, I'm down to one failing unit test in CMFUid and have discovered that CMFUid is basically broken in 2.0/trunk. I also sent an email on this issue to the list, hoping that the developers who wrote CMFUid and lobbied hard to get it included would take notice and do something about it (or at least acknowledge it), but all I see is silence so far. At least I have found what the problem with CMFUid is, and it is mostly a misunderstanding how it is supposed to work. Mea culpa. I'm still left with the one failing unit test on the events branch, though. Having such an unknown and unmaintained piece of code in the core of the cmf scares me. How would people feel about deprecating it for 2.1 and removing it in 2.3 if no-one steps up who wants it? Well, I have my own opinion about that, but the course of action depends mostly on those people who are using it. No one seems to, judged by the complete silence. As I have found, it is only used in one specific situations: If you create a Favorite pointing to a piece of content, then that piece gets tagged with a UID, and the UID identifies the content piece for the Favorite. So you can copy/paste/whatever the content and the Favorite still knows how to find it. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFETjZXRAx5nvEhZLIRAjXvAJwKHXTisxiklmJJSx90XX67IBfD0QCghZzg 8IQx6SgTQpE68yce7gVsEPw= =Jqjt -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 roadmap update
Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25 Apr 2006, at 15:08, Chris Withers wrote: Jens Vagelpohl wrote: I sent an email about this a couple days ago. Basically, I'm down to one failing unit test in CMFUid and have discovered that CMFUid is basically broken in 2.0/trunk. I also sent an email on this issue to the list, hoping that the developers who wrote CMFUid and lobbied hard to get it included would take notice and do something about it (or at least acknowledge it), but all I see is silence so far. At least I have found what the problem with CMFUid is, and it is mostly a misunderstanding how it is supposed to work. Mea culpa. I'm still left with the one failing unit test on the events branch, though. Having such an unknown and unmaintained piece of code in the core of the cmf scares me. How would people feel about deprecating it for 2.1 and removing it in 2.3 if no-one steps up who wants it? Well, I have my own opinion about that, but the course of action depends mostly on those people who are using it. No one seems to, judged by the complete silence. Grégoire Weber is the one that coded it and included it. As I have found, it is only used in one specific situations: If you create a Favorite pointing to a piece of content, then that piece gets tagged with a UID, and the UID identifies the content piece for the Favorite. So you can copy/paste/whatever the content and the Favorite still knows how to find it. Given that it's unmaintained, that Plone has its own UID tool, that CPS does it differently, I'm for deprecating it quickly and slating it for removal earlier than the usual 1 year. I've also alreay pointed out the overengineering of having 3 tools for a simple UID management. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +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 roadmap update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25 Apr 2006, at 15:51, Florent Guillaume wrote: How would people feel about deprecating it for 2.1 and removing it in 2.3 if no-one steps up who wants it? Well, I have my own opinion about that, but the course of action depends mostly on those people who are using it. No one seems to, judged by the complete silence. Grégoire Weber is the one that coded it and included it. As I have found, it is only used in one specific situations: If you create a Favorite pointing to a piece of content, then that piece gets tagged with a UID, and the UID identifies the content piece for the Favorite. So you can copy/paste/whatever the content and the Favorite still knows how to find it. Given that it's unmaintained, that Plone has its own UID tool, that CPS does it differently, I'm for deprecating it quickly and slating it for removal earlier than the usual 1 year. Thanks for speaking up, Florent. +1 from me. My proposal would be to add deprecation warnings on the 2.0 branch and trunk and delete it on the trunk as soon as the 2.1 branch has been cut in a few months. And yes, three separate tools for this one tiny piece of functionality is quite odd. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFETjk0RAx5nvEhZLIRAj5nAJ46fw+eAh6dpwpiMXqsrj4zhgk28ACgkyp7 DgB//iZBRjMAVckthzeI7Lw= =Yko2 -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
Re: [Zope-CMF] Re: CMF roadmap update
Hi Jens. Z3 has it own uid facilities. I guess folks could pick this up through five could they not? Its all moving in that direction in any case. Regards David Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25 Apr 2006, at 15:51, Florent Guillaume wrote: How would people feel about deprecating it for 2.1 and removing it in 2.3 if no-one steps up who wants it? Well, I have my own opinion about that, but the course of action depends mostly on those people who are using it. No one seems to, judged by the complete silence. Grégoire Weber is the one that coded it and included it. As I have found, it is only used in one specific situations: If you create a Favorite pointing to a piece of content, then that piece gets tagged with a UID, and the UID identifies the content piece for the Favorite. So you can copy/paste/whatever the content and the Favorite still knows how to find it. Given that it's unmaintained, that Plone has its own UID tool, that CPS does it differently, I'm for deprecating it quickly and slating it for removal earlier than the usual 1 year. Thanks for speaking up, Florent. +1 from me. My proposal would be to add deprecation warnings on the 2.0 branch and trunk and delete it on the trunk as soon as the 2.1 branch has been cut in a few months. And yes, three separate tools for this one tiny piece of functionality is quite odd. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFETjk0RAx5nvEhZLIRAj5nAJ46fw+eAh6dpwpiMXqsrj4zhgk28ACgkyp7 DgB//iZBRjMAVckthzeI7Lw= =Yko2 -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 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 roadmap update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25 Apr 2006, at 16:33, David Pratt wrote: added text at bottom Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25 Apr 2006, at 15:51, Florent Guillaume wrote: How would people feel about deprecating it for 2.1 and removing it in 2.3 if no-one steps up who wants it? Well, I have my own opinion about that, but the course of action depends mostly on those people who are using it. No one seems to, judged by the complete silence. Grégoire Weber is the one that coded it and included it. As I have found, it is only used in one specific situations: If you create a Favorite pointing to a piece of content, then that piece gets tagged with a UID, and the UID identifies the content piece for the Favorite. So you can copy/paste/whatever the content and the Favorite still knows how to find it. Given that it's unmaintained, that Plone has its own UID tool, that CPS does it differently, I'm for deprecating it quickly and slating it for removal earlier than the usual 1 year. Thanks for speaking up, Florent. +1 from me. My proposal would be to add deprecation warnings on the 2.0 branch and trunk and delete it on the trunk as soon as the 2.1 branch has been cut in a few months. And yes, three separate tools for this one tiny piece of functionality is quite odd. jens Hi Jens. Z3 has it own uid facilities. I guess folks could pick this up through five could they not? Its all moving in that direction in any case. Yes, they could. For the CMF I wouldn't look to replace it, I'd rather throw it out. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFETkTIRAx5nvEhZLIRAta5AJ48RijcRxiP+j+lFVAPkT2WWbZYngCcDM7h qMzqlREITw/tgVNw7jH3cKA= =1Ebl -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 roadmap update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florent Guillaume wrote: Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25 Apr 2006, at 15:08, Chris Withers wrote: Jens Vagelpohl wrote: I sent an email about this a couple days ago. Basically, I'm down to one failing unit test in CMFUid and have discovered that CMFUid is basically broken in 2.0/trunk. I also sent an email on this issue to the list, hoping that the developers who wrote CMFUid and lobbied hard to get it included would take notice and do something about it (or at least acknowledge it), but all I see is silence so far. At least I have found what the problem with CMFUid is, and it is mostly a misunderstanding how it is supposed to work. Mea culpa. I'm still left with the one failing unit test on the events branch, though. Having such an unknown and unmaintained piece of code in the core of the cmf scares me. How would people feel about deprecating it for 2.1 and removing it in 2.3 if no-one steps up who wants it? Well, I have my own opinion about that, but the course of action depends mostly on those people who are using it. No one seems to, judged by the complete silence. Grégoire Weber is the one that coded it and included it. As I have found, it is only used in one specific situations: If you create a Favorite pointing to a piece of content, then that piece gets tagged with a UID, and the UID identifies the content piece for the Favorite. So you can copy/paste/whatever the content and the Favorite still knows how to find it. Given that it's unmaintained, that Plone has its own UID tool, that CPS does it differently, I'm for deprecating it quickly and slating it for removal earlier than the usual 1 year. I've also alreay pointed out the overengineering of having 3 tools for a simple UID management. The intent was to allow replacement of one bit of policy (e.g., the generation of a UID / UUID for a given object) without requiring replacement of the other bits. Another, similarly-pluggable implementaiton would be to have a single tool containing a plugin registry (as PAS does), with interfaces for each of the plugins. - -0 on deprecating it yet; let's see what the folks who *do* use it have to say about their future intent. For instance, the Plone implementation might want to fold into what we are doing in the CMF. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFETlIm+gerLs4ltQ4RAiMhAJ9Kez80u0ZBtBsarJKQdPr1f0kX+QCgkzO6 HHsJfNRXf7ZyS1pbhQD5NGI= =9Jv8 -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
Re: [Zope-CMF] Re: CMF roadmap update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25 Apr 2006, at 17:49, Tres Seaver wrote: I believe the work which Philipp and I did at PyCon will land for Zope 2.10 / Five 1.4. Until then, we don't have any story for view customization: sites which depend on such customization will need to continue using the skins. OK, I have added this dependency to the roadmap. The same goes for the views refactoring before making them the default throughout. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFETlV1RAx5nvEhZLIRAuRDAJ9JURqsqDLLRiaveCYCCcSgw5vg+QCeOm6X 0aHJthz0buTWMoU/waXWaL0= =3A5G -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 roadmap update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: Hi Jens! Jens Vagelpohl wrote: CMF 2.0.0 is now out the door and I have made some updates to the roadmap document. Please take a look and give me some feedback on the dates (well, the only dates we have set are the dates for CMF 2.1) and the description of 2.1: http://www.zope.org/Products/CMF/docs/roadmap/document_view The roadmap doesn't specify the status of the mentioned changes. I quote the CMF 2.1 section here to add my comments and questions: Adding missing pieces to the Zope 3 integration puzzle which could not make it into the 2.0 release for time reasons will be the main objective for CMF 2.1. At this point the following items are planned to land in CMF 2.1: * Local skin customization (take an item from the skins tool and customize it for a particular CMF site instance) Is anybody working on this? AFAICS everybody agrees we need a solution for this, but so far we don't even have a rough proposal. * Release CMF as Eggs The related work is on the tseaver-pkg_resources branch, right? What's the status of that branch? I'm actually not happy with the status of that branch: it was mostly aimed at making CMF releasable as zip-safe eggs. However, almost *no* Zope-related eggs are zip-safe, due to package-local data everywhere. At this point, I think I would rather punt on zip-safety, and just release CMF 2.1 as eggs (at least as one alternative). We might come up with an entry point convention (beyond the one defined by Basket) to support QuickInstaller-like setup / configuration. * convert all views over to Zope 3-style views I think we can go on converting views step by step using the patterns used in CMF 2.0. These patterns make it relatively easy to convert the existing skin methods in a traceable way. But the resulting views are far from perfect. Before we can make them the default views they need a lot of refactoring. I plan to have a look at formlib and viewlets to find out what we can reuse in CMF. * Make the new Zope 3-style views the standard views This depends on 'Local skin customization' and 'convert all views'. Not necessarily. We could reverse the default from CMF 2.0, and provide the skins-based profile as an alternative for those who need customization. * Use of Zope 3-style container events throughout, removal of all manage_* methods. Is this already implemented on the tseaver-catalog_events branch or is more work necessary than merging that branch? We would need to review the diff by hand, I think: $ svn diff -r 41511:HEAD $ZSVN/CMF/branches/tseaver-catalog_events I've lost most of my context for the branch at this point. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFETlch+gerLs4ltQ4RAqwxAJ4yX6C8rX+SXfNeGKT/W61fd2XiOwCff5r6 ijRQ30hq0lQbNaFw3Jc/Q6I= =LX4B -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 roadmap update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adding missing pieces to the Zope 3 integration puzzle which could not make it into the 2.0 release for time reasons will be the main objective for CMF 2.1. At this point the following items are planned to land in CMF 2.1: * Local skin customization (take an item from the skins tool and customize it for a particular CMF site instance) Is anybody working on this? AFAICS everybody agrees we need a solution for this, but so far we don't even have a rough proposal. It was my impression (please correct me if I am wrong) that this is a Zope 3/Five issue rather than something we solve in CMF. And that there are people working on it, but I'm not sure who and how far it has progressed. * Release CMF as Eggs The related work is on the tseaver-pkg_resources branch, right? What's the status of that branch? Tres will probably know. * convert all views over to Zope 3-style views I think we can go on converting views step by step using the patterns used in CMF 2.0. These patterns make it relatively easy to convert the existing skin methods in a traceable way. But the resulting views are far from perfect. Before we can make them the default views they need a lot of refactoring. I plan to have a look at formlib and viewlets to find out what we can reuse in CMF. * Make the new Zope 3-style views the standard views This depends on 'Local skin customization' and 'convert all views'. Yes, absolutely. * Use of Zope 3-style container events throughout, removal of all manage_* methods. Is this already implemented on the tseaver-catalog_events branch or is more work necessary than merging that branch? I sent an email about this a couple days ago. Basically, I'm down to one failing unit test in CMFUid and have discovered that CMFUid is basically broken in 2.0/trunk. I also sent an email on this issue to the list, hoping that the developers who wrote CMFUid and lobbied hard to get it included would take notice and do something about it (or at least acknowledge it), but all I see is silence so far. I am a little upset because I had hoped the original developers would continue maintaining it (or at least help maintaining it), but I'm not so sure anymore. It seems CMFUid is now the least-maintained package we have, and the fact that no one even noticed the complete breakage (which the unit tests do not reveal) seems to imply no one uses it and no one cares. I certainly never came across many people who use it. I will, grudgingly, spend a little more time trying to unwedge it for 2.0/trunk, hoping that will help me solve the last failing unittest on the tseaver-catalog_events branch. However, the going is a bit hard because I don't know the code at all. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFETT+JRAx5nvEhZLIRAkkkAJ4jRTwN3Qpy+FUuvzzDI4NKp8+H0gCfYxSJ 4fuZrsso1vyXtRsz4hDpqxo= =yWSN -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
Re: [Zope-CMF] Re: CMF roadmap update
On Mon, Apr 24, 2006 at 10:13:45PM +0100, Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adding missing pieces to the Zope 3 integration puzzle which could not make it into the 2.0 release for time reasons will be the main objective for CMF 2.1. At this point the following items are planned to land in CMF 2.1: * Local skin customization (take an item from the skins tool and customize it for a particular CMF site instance) Is anybody working on this? AFAICS everybody agrees we need a solution for this, but so far we don't even have a rough proposal. It was my impression (please correct me if I am wrong) that this is a Zope 3/Five issue rather than something we solve in CMF. And that there are people working on it, but I'm not sure who and how far it has progressed. I saw Philip W. do a working prototype of this at the PyCon Dallas sprints. I don't know if anything happened with this after PyCon, and it would need at least some UI work. If the UI is to integrate with the CMF skins tool, I suspect there will need to be a thin layer of CMF-specific UI written as well. IIRC, Philip's prototype just dumped the templates into the Zope root, or maybe into the current folder, I forget. -- Paul Winkler http://www.slinkp.com ___ 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 roadmap update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24 Apr 2006, at 22:13, Jens Vagelpohl wrote: * Use of Zope 3-style container events throughout, removal of all manage_* methods. Is this already implemented on the tseaver-catalog_events branch or is more work necessary than merging that branch? I sent an email about this a couple days ago. Basically, I'm down to one failing unit test in CMFUid and have discovered that CMFUid is basically broken in 2.0/trunk. I also sent an email on this issue to the list, hoping that the developers who wrote CMFUid and lobbied hard to get it included would take notice and do something about it (or at least acknowledge it), but all I see is silence so far. At least I have found what the problem with CMFUid is, and it is mostly a misunderstanding how it is supposed to work. Mea culpa. I'm still left with the one failing unit test on the events branch, though. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFETU0HRAx5nvEhZLIRAobBAJ9tQwsFDYX8mudmzGzXr5N0/piUJACdEtpG eZLvvkQdEMHqPzbgFYExn+g= =CTJq -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 roadmap update
Hi Jens, CMF 2.0.0 is now out the door and I have made some updates to the roadmap document. Please take a look and give me some feedback on the dates (well, the only dates we have set are the dates for CMF 2.1) and the description of 2.1: http://www.zope.org/Products/CMF/docs/roadmap/document_view The roadmap feels largely on track. Some of the stories we're still trying to get straight in Plone are: - We'd like to use Five views wholesale, but we can't stop people from doing local customisations. The way we solve that now is to register view classes without templates and then acquire them: tal:define=view context/@@plone_view And leave page templates in portal_skins as usual. I would personally settle for a mechanism by which we could use views with page templates associated, but where the *page template* could be customised TTW. If someone needed additional logic, they would either have to fall back on python: expressions or old-fashioned scripts, or make a new view to override the existing one - the most important use case is the tinkerer who just wants to fiddle some basic HTML or TAL to get Plone (or CMF) to look the way he wants. - We'd like to investigate the possibility of using Zope 3 schemas to create content types. I haven't had time to go in a detail yet, but Alec Mitchell already did some of this in 'listen' by deriving from PortalType and manually constructing an FTI. If more of the FTI mechanisms and the context-dependent things like the add menu (which is of course constructed by portal_types) could be implemented with more general adapters, I think we may be able to make the glue between CMF content types and Zope 3 content types thinner. - Content import/export via things like ContentSetup, would be very useful to standardise. There are currently a few efforts, like Marshall, xmlio and XMLForrest (which I believe form a stack, with XMLForrest being the most usable one). However, these things are dependent on Archetypes as far as I understand. If CMF land and Zope 3 land have ideas for content import/export it makes sense to consolidate these. Thanks again - we look forward to integrating with CMF 2 :-) 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 roadmap
Jens Vagelpohl wrote: There's one specific item that I couldn't find enough information on to make a comment, which is events support. Florent, what is the status on the trunk and the 1.6 branch? In 1.6 and 2.0 events are not used beyond what Zope has. So events are not used to trigger cataloging on modifications for instance. Also, manage_afterAdd co still exist and have not been converted to events, so are still flagged using five:deprecatedManageAddDelete. As mentioned, Tres has a branch where he works on this. Is this something we need to wait for for the first 2.0 beta in 1.5 weeks? High +1 on getting this fixed for 2.0. There's a lot of contrived cataloging code out there (*cough* Archetypes) and it would be beneficial to have a clean model for events in CMF, not just for cataloging things. I do realize there are always parties who would *like* something to happen, but this was a question directed at the people who *do* make it happen. If we're not sticking to some kind of schedule but wait till all wish lists are considered we won't get anywhere I am afraid. I'd love to help but I won't have much bandwidth before 1 month. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +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
[Zope-CMF] Re: CMF roadmap
Jens Vagelpohl wrote: Hi all, I finally sat down and put up a CMF roadmap page. It is pretty condensed right now, and I'm asking for feedback: http://www.zope.org/Products/CMF/docs/roadmap There's one specific item that I couldn't find enough information on to make a comment, which is events support. Florent, what is the status on the trunk and the 1.6 branch? In 1.6 and 2.0 events are not used beyond what Zope has. So events are not used to trigger cataloging on modifications for instance. Also, manage_afterAdd co still exist and have not been converted to events, so are still flagged using five:deprecatedManageAddDelete. As mentioned, Tres has a branch where he works on this. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +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 roadmap
On 15 Feb 2006, at 14:12, Florent Guillaume wrote: Jens Vagelpohl wrote: There's one specific item that I couldn't find enough information on to make a comment, which is events support. Florent, what is the status on the trunk and the 1.6 branch? In 1.6 and 2.0 events are not used beyond what Zope has. So events are not used to trigger cataloging on modifications for instance. Also, manage_afterAdd co still exist and have not been converted to events, so are still flagged using five:deprecatedManageAddDelete. As mentioned, Tres has a branch where he works on this. Is this something we need to wait for for the first 2.0 beta in 1.5 weeks? 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 roadmap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: On 15 Feb 2006, at 23:53, Martin Aspeli wrote: There's one specific item that I couldn't find enough information on to make a comment, which is events support. Florent, what is the status on the trunk and the 1.6 branch? In 1.6 and 2.0 events are not used beyond what Zope has. So events are not used to trigger cataloging on modifications for instance. Also, manage_afterAdd co still exist and have not been converted to events, so are still flagged using five:deprecatedManageAddDelete. As mentioned, Tres has a branch where he works on this. Is this something we need to wait for for the first 2.0 beta in 1.5 weeks? High +1 on getting this fixed for 2.0. There's a lot of contrived cataloging code out there (*cough* Archetypes) and it would be beneficial to have a clean model for events in CMF, not just for cataloging things. I do realize there are always parties who would *like* something to happen, but this was a question directed at the people who *do* make it happen. If we're not sticking to some kind of schedule but wait till all wish lists are considered we won't get anywhere I am afraid. I have just checked in the stab I made on another branch[1]: perhaps some of the interested parties can help work out the remaining glitches (some test failures) and extend it further (e.g., to handle workflow notifiication). [1] svn+ssh://svn.zope.org/repos/main/CMF/branches/tseaver-catalog_events Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD9AMp+gerLs4ltQ4RAqPIAKCg14oqaG3guVQ9p36JuxzMylm+CgCfWB/8 OgS2inOzZmULcWbCil/omL0= =Qxq3 -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 roadmap
Hi Jens! Jens Vagelpohl wrote: I finally sat down and put up a CMF roadmap page. It is pretty condensed right now, and I'm asking for feedback: http://www.zope.org/Products/CMF/docs/roadmap Great! I have one comment: While we first worked on CMF 2.0 and later backported some stuff to CMF 1.6 the lists of new features are a bit confusing now. I think for CMF 2.0 we should only list changes compared to CMF 1.6. (The CHANGES.txt files are also confusing in this point.) CMF 2.0 release: How close are we to a beta? I know the tseaver-viewification branch needs merging, can we go ahead and do that? Tres has planned to work on this, but it looks like he was distracted by other things. The tseaver-viewification branch is currently not ready for merging. From earlier discussions we have decided to not make them the default for 2.0, which would mean we need a GenericSetup profile to enable them. I would like to be able to get to 2.0.0 final by the end of March at the latest. I can offer to work on the viewification and merge the branch next weekend if Tres has no time. But I would just add a ZCML file that needs to be enabled to use the views - not a GenericSetup profile. And I will have no time to write unittest. 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 roadmap
On 12 Feb 2006, at 15:38, yuppie wrote: I have one comment: While we first worked on CMF 2.0 and later backported some stuff to CMF 1.6 the lists of new features are a bit confusing now. I think for CMF 2.0 we should only list changes compared to CMF 1.6. (The CHANGES.txt files are also confusing in this point.) Yes, I agree. Due to the release timing where in reality they are concurrent and not 1.6 comes before 2.0 I was never really sure where to put things in the various CHANGES.txt files. What I will do tonight is go through and remove all items from the HEAD CHANGES.txt that are already mentioned in the 1.6 branch and thus act like 1.6 really came before 2.0. I think I will also tweak HISTORY.txt on the trunk to reflect the new ordering. From earlier discussions we have decided to not make them the default for 2.0, which would mean we need a GenericSetup profile to enable them. I would like to be able to get to 2.0.0 final by the end of March at the latest. I can offer to work on the viewification and merge the branch next weekend if Tres has no time. But I would just add a ZCML file that needs to be enabled to use the views - not a GenericSetup profile. And I will have no time to write unittest. IMHO the zcml file route is good enough as long as something explains how to do it, maybe in a README. So with this in mind, how does 2 weeks from now sound for the beta? 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 roadmap
Hi Jens! Jens Vagelpohl wrote: On 12 Feb 2006, at 15:38, yuppie wrote: I have one comment: While we first worked on CMF 2.0 and later backported some stuff to CMF 1.6 the lists of new features are a bit confusing now. I think for CMF 2.0 we should only list changes compared to CMF 1.6. (The CHANGES.txt files are also confusing in this point.) Yes, I agree. Due to the release timing where in reality they are concurrent and not 1.6 comes before 2.0 I was never really sure where to put things in the various CHANGES.txt files. What I will do tonight is go through and remove all items from the HEAD CHANGES.txt that are already mentioned in the 1.6 branch and thus act like 1.6 really came before 2.0. I think I will also tweak HISTORY.txt on the trunk to reflect the new ordering. +1 From earlier discussions we have decided to not make them the default for 2.0, which would mean we need a GenericSetup profile to enable them. I would like to be able to get to 2.0.0 final by the end of March at the latest. I can offer to work on the viewification and merge the branch next weekend if Tres has no time. But I would just add a ZCML file that needs to be enabled to use the views - not a GenericSetup profile. And I will have no time to write unittest. IMHO the zcml file route is good enough as long as something explains how to do it, maybe in a README. So with this in mind, how does 2 weeks from now sound for the beta? Sounds good to me. I'll merge the viewification branch in time if Tres doesn't want to do it himself. 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
