[Zope-CMF] Re: CMF 1.6
Florent Guillaume wrote: I'd like to have some clarifications from the Plone team about what they expect to do w.r.t. events in CMF 1.6. I see two possibilities: 1. you guys are prepared to do the work needed for Plone products to use super() in manage_afterAdd & co, in which case I can merge my branch into CMF 1.6 2. you feel that's too dangerous and, as Plone intends to use CMF 1.6, I'll merge for CMF 2.0 only. Be aware that if 2. is chosen, you won't be able to use Zope 3 events at all with CMF 1.6. Actually even if the part of my branch that uses super() is not merged, I'll still merge into 1.6 the change of order in the base classes for File and Image. This way at least CPS can monkey-patch manage_afterAdd to use super(), and use proper events. (reminder: the branch is at http://svn.zope.org/CMF/branches/efge-1.5-five-compatible/?rev=40028&view=rev) Florent -- Florent Guillaume, Nuxeo (Paris, France) 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
[Zope-CMF] Re: CMF 1.6
Alec Mitchell wrote: [..] The big problem with this move is there's no way to give product developers warning. They can't start using super now, because none of the base classes use it, but once super is in place in the base classes developers will need to start using it immediately or risk strange breakages. Maintaining product compatibility between versions of CMF/Plone will become nearly impossible. Given that we have currently 216 add-on products for Plone listed on plone.org/products alone, where the majority I guess is based on Archetypes, this really should be considered a show-stopper. Doesn't look like there are any alternatives for getting add/delete/copy events working under zope2 though. I'm afraid you are right :-( /me holding back my desire to push for events nevertheless Raphael Alec ___ 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
[Zope-CMF] Re: CMF 1.6
Florent Guillaume wrote: I'd like to have some clarifications from the Plone team about what they expect to do w.r.t. events in CMF 1.6. I see two possibilities: 1. you guys are prepared to do the work needed for Plone products to use super() in manage_afterAdd & co, in which case I can merge my branch into CMF 1.6 2. you feel that's too dangerous and, as Plone intends to use CMF 1.6, I'll merge for CMF 2.0 only. Be aware that if 2. is chosen, you won't be able to use Zope 3 events at all with CMF 1.6. As a bystander, I have a suspicion that this discussion might be helped via an IRC appointment? --Paul ___ 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 1.6
Chris Withers wrote: Alec Mitchell wrote: to start using it immediately or risk strange breakages. Maintaining product compatibility between versions of CMF/Plone will become nearly impossible. I'm sorry, I really couldn't resist this... neither can I ... And that differs from other Plone releases how exactly? ;-) not at all, but that's what many people (including yourself?) didn't like so far. So maybe it's time for a change? ;-) Raphael Chris ___ 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 1.6
On Fri, 18 Nov 2005 00:37:47 -0800, Chris Withers <[EMAIL PROTECTED]> wrote: Alec Mitchell wrote: to start using it immediately or risk strange breakages. Maintaining product compatibility between versions of CMF/Plone will become nearly impossible. I'm sorry, I really couldn't resist this... And that differs from other Plone releases how exactly? ;-) And what, exactly, have you done to help Plone have less bugs? I know you get income from Plone consulting, how about making your workday better *and* pay back for the stuff you get for free? You are seriously starting to piss me off, Chris - as the only person in the Zope world so far. An achievement in itself, but not one you should be particularly proud of. -- _ 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
[Zope-CMF] Re: CMF 1.6
Alexander Limi wrote: And that differs from other Plone releases how exactly? ;-) And what, exactly, have you done to help Plone have less bugs? *sigh* there's not a lot I can do, the problems with Plone are cultural. There seems to be a pervasive culture of monkey patching and bludegeoning code to meet functionality requirements while not worrying about software architecture, refactoring, scalability or performance except in passing fads. Yeah, sure it works out of the box like it should, and it has all the checkbox features, and it even looks pretty if that's the look you like, but try and do anything that doesn't ship out of the box and _doesn't_ involve the aforementioned code blugeoning and you end up with a solution that will only work for your specific project because of the Plone-wide assumptions you have to break to get it done. Either that or not give a damn about performance or maintainability and "just make it work". Sure, it'll work for a few releases without change if you're lucky, but it'll likely be dog slow and pig ugly if you look behind the scenes. I'm sorry, that kind of coding just doesn't interest me. But, inspite of that, you will see the odd change I've made to try and help, and I try and provide simple tools like zdb, Stepper, MailingLogger, SimpleUserFolder and MailTemplates that people are free to use without any obnoxious GPHell licensing and without having to worry about some semi-formed ip assignment that may or may not stand up in any given court of law around the world. I know you get income from Plone consulting, how about making your workday better *and* pay back for the stuff you get for free? Because I can't. The win's we've had on the one big Plone-related (and there's not _much_ of Plone actually left now, sorry to tell you) project I work on have been by stripping out all the complexity so that code meets the _project_ requirements and doesn't worry about interacting with any of the myriad of Plone half-interfaces and semi finished rubbish that gets shipped as part of every release. You are seriously starting to piss me off, Chris Don't worry, the quality of code that ships in the Plone bundle has already done much to take me way beyond pissed off. I find it a tragedy that a project with such a large following can't manage to get anyone capable of actually standing back and taking a good hard look at the quality of some of your key components and sorting it out rather than tacking on the next whizz-bang feature in a similarly half-arsed manner. >- as the only person in the Zope world so far. An achievement in itself, but not one you should be particularly proud of. Honestly, I'm sorry you feel that way but at least I make the distinction about what it is I'm pissed off about. The people in the Plone community are great, and I get on with the majority of them very well as far as I know, but sadly, that alone doesn't make them write good software. I am pissed off with the _software_ not the _people_ and if I thought there was a sane way I could make things better, I would. But again, honestly, I think the software that currently makes up Plone above the CMF, and even that could do with a good kick, is beyond help and would only really be improved by a ground-up rewrite. And finally, if you're pissed off with me, that's fine, I don't really give a monkeys how you feel towards me personally. Write some good software, then I might ;-) cheers, Chris PS: Sorry for the rant, I was hoping to avoid this heading to a list but the one liner I posted earlier was as good as I could make it, I even put the smiley in ;-) For Alex to reply like this has now got the response it deserved. Really, I was excited to try Plone 2.1 with all the hype about the quality being so much better and improved performance, but having just had to give up on another project involving Plone 2.1 and LinguaPlone because it was way too slow, particularly on Windows, and trying to fix any of the problems I found felt like playing some sick and twisted version of whack-a-mole, not to mention the fact that Plone still ships with failing unit tests that cause other product's unit tests to fail means that while I have loads of respect for the project in managing to grow such a large community, and particularly for the people who have the patience to take part, I have zero respect for the software that underpins it... -- 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 1.6
On Fri, 18 Nov 2005 05:49:46 -0800, Chris Withers <[EMAIL PROTECTED]> wrote: Rant accepted, and understood. Still, you could try to help out instead of *just* bitching. I am an expert bitcher myself, but at least I do something about it. Thread closed? Feel free to follow up with me in private email if there's anything we can do to facilitate you helping out. -- _ 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
[Zope-CMF] Re: CMF 1.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guys, I'll ask that this end here on the zope-cmf list (well, Alex is entitled to one public rebuttal, I guess). We need to focus the list's discussion and attention on ways to improve the architecture, rather than engaging in a "your code is crap" flamewar. FWIW, the Goldegg work is largely aimed at making it possible to resolve the "product vs. framework" dichotomy in Plone, by making it possible to extract / reuse / reimplement features developed to meet a given need as Z3 components. I am *very* excited to be working with both Plone and CMF developers to make that happen. 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 iD8DBQFDfd74+gerLs4ltQ4RAs5hAKCIQ0rkwjlI1EGW2ewmqlREuIsO8ACfR62U xlpNSVCtCT52zb1pQ8KM3ls= =3KhU -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 1.6 update
Cool, thanks for that work. Florent Rob Miller wrote: okay, brent hendricks and i managed to put a few more hours into CMF 1.6 today. here's an update: - ActionsTool import node now purges auto-created actions and correctly reads in a CMF 1.5 syntax actions.xml file, creating old style actions, w/ a GenericSetup style importer - the backwards-compatible FTI factory methods have been re-added to the TypesTool - a number of z2 interfaces have been switched out for their z3 counterparts, to get the GenericSetup node adapter adaptation working correctly - all CMFCore unit tests are passing again - all CMFDefault unit tests except one are passing (the final one is dependent on readding PortalGenerator to the CMFDefault.Portal module, see below) the following is still to be accomplished: - need to readd the PortalGenerator portal creation mechanism for CMFDefault.Portal, for backwards compatibility - i've removed the CMFTopic setup stuff from the default profile, but have not yet replaced it with the extension profile in the CMFTopic product; for this reason CMFTopic unit tests are broken i'm going to be offline for the next 1-1/2 days... i'll be picking this work up again on monday evening, california time. -r ___ Zope-CMF maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests -- Florent Guillaume, Nuxeo (Paris, France) 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
[Zope-CMF] Re: CMF 1.6 update
Rob Miller wrote: the following is still to be accomplished: - need to readd the PortalGenerator portal creation mechanism for CMFDefault.Portal, for backwards compatibility this is done. the unit test is still failing, however. for some reason, in CMFDefault.tests.test_Portal.CMFSiteTests, globals()["__warningregistry__"] doesn't seem to exist. i'm not sure how this is supposed to work, exactly... it seems as though the self._trap_warning_output() call in the test setup is related, although i've looked at the WarningInterceptor code and don't understand how it's supposed to be working. there's a similar but slightly different use of __warningregistry__ in CMFCore.tests.test_DirectoryView which IS working. if someone can point me in the direction of how this magic is supposed to happen, i'll dig more and get this last CMFDefault test passing. - i've removed the CMFTopic setup stuff from the default profile, but have not yet replaced it with the extension profile in the CMFTopic product; for this reason CMFTopic unit tests are broken this is done and all of the CMFTopic tests are now passing. -r ___ 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 1.6 update
Rob Miller wrote: - i've removed the CMFTopic setup stuff from the default profile, but have not yet replaced it with the extension profile in the CMFTopic product; for this reason CMFTopic unit tests are broken urgh... CMFTopic tests are passing as reported, but forgot to mention that there are a bunch of "WARNING:ZODB.DB:DB.open() has 13 open connections with a pool_size of 7" messages being spit out. will look at it tomorrow, must sleep now. -r ___ 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 1.6 update
Rob Miller wrote: - need to readd the PortalGenerator portal creation mechanism for CMFDefault.Portal, for backwards compatibility this is done. the unit test is still failing, however. for some reason, in CMFDefault.tests.test_Portal.CMFSiteTests, globals()["__warningregistry__"] doesn't seem to exist. i'm not sure how this is supposed to work, exactly... The is put into place by the warnings module as soon as the first warning is emitted. See warnings.py. Florent it seems as though the self._trap_warning_output() call in the test setup is related, although i've looked at the WarningInterceptor code and don't understand how it's supposed to be working. there's a similar but slightly different use of __warningregistry__ in CMFCore.tests.test_DirectoryView which IS working. if someone can point me in the direction of how this magic is supposed to happen, i'll dig more and get this last CMFDefault test passing. - i've removed the CMFTopic setup stuff from the default profile, but have not yet replaced it with the extension profile in the CMFTopic product; for this reason CMFTopic unit tests are broken this is done and all of the CMFTopic tests are now passing. -- Florent Guillaume, Nuxeo (Paris, France) 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
[Zope-CMF] Re: CMF 1.6 update
Florent Guillaume wrote: Rob Miller wrote: - need to readd the PortalGenerator portal creation mechanism for CMFDefault.Portal, for backwards compatibility this is done. the unit test is still failing, however. for some reason, in CMFDefault.tests.test_Portal.CMFSiteTests, globals()["__warningregistry__"] doesn't seem to exist. i'm not sure how this is supposed to work, exactly... The is put into place by the warnings module as soon as the first warning is emitted. See warnings.py. ah, thank you! yes, in the older test_Portal, it is implicitly assumed that the warning registry has been created _before_ the test in question is reached. since all of the other unit tests are now using GenericSetup to create the site, no warnings had yet been generated. fixed and committed the test, all CMFDefault tests are now passing. -r ___ 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 1.6 change broke Plone compatibility
Hi, The following checkin on the 1.6 branch, which looks like a pure cleanup item, completely breaks Plone 2.1 and up on CMF 1.6. I assume that was not the intention. http://svn.zope.org/CMF/branches/1.6/CMFCore/TypesTool.py? rev=40364&r1=40360&r2=40364 Do you know how it breaks Plone, exactly? What was this checkin intended to do? 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 1.6 change broke Plone compatibility
Hi Jens! Jens Vagelpohl wrote: The following checkin on the 1.6 branch, which looks like a pure cleanup item, completely breaks Plone 2.1 and up on CMF 1.6. I assume that was not the intention. http://svn.zope.org/CMF/branches/1.6/CMFCore/TypesTool.py?rev=40364&r1=40360&r2=40364 I'm in the specific situation where I have an existing Plohn 2.1 site and I want to use PAS. The latest PAS depends in a current GenericSetup, so I am trying to move the Plone site onto the current CMF 1.6 branch. Due to the change above this is not possible. Question: If we claim CMF 1.5 compatibility, do you mind reverting this checkin? The intention was to make things consistent. CMF 1.5 and CMF 2.0 have different ways to register custom type info classes. Before that change both machineries were broken on the 1.6 branch because they were merged in an insane way. I fixed the new machinery because - most code used already the new machinery (and I thought that was Rob's intention) - this doesn't break many products I don't mind if you switch the 1.6 branch back to the old machinery, but there are more changes necessary than just reverting the last checkin. 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 1.6 change broke Plone compatibility
On 20 Dec 2005, at 19:53, yuppie wrote: The intention was to make things consistent. CMF 1.5 and CMF 2.0 have different ways to register custom type info classes. Before that change both machineries were broken on the 1.6 branch because they were merged in an insane way. I fixed the new machinery because - most code used already the new machinery (and I thought that was Rob's intention) - this doesn't break many products I don't mind if you switch the 1.6 branch back to the old machinery, but there are more changes necessary than just reverting the last checkin. Like what exactly? With all due respect, the 1.6 branch should *not* break stuff that works find on 1.5. The specific goal for 1.6 was to be "1.5 plus GenericSetup" so that it stays 1.5-compatible. This change has nothing to do with GenericSetup from all I can tell. Please don't just say "OK, change it back if you want, but there may be traps elsewhere". I do not know what all needs to be changed. I'll be happy to do it, but I need to know what else is involved. 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 1.6 change broke Plone compatibility
Jens Vagelpohl wrote: On 20 Dec 2005, at 19:53, yuppie wrote: The intention was to make things consistent. CMF 1.5 and CMF 2.0 have different ways to register custom type info classes. Before that change both machineries were broken on the 1.6 branch because they were merged in an insane way. I fixed the new machinery because - most code used already the new machinery (and I thought that was Rob's intention) - this doesn't break many products I don't mind if you switch the 1.6 branch back to the old machinery, but there are more changes necessary than just reverting the last checkin. Like what exactly? With all due respect, the 1.6 branch should *not* break stuff that works find on 1.5. The specific goal for 1.6 was to be "1.5 plus GenericSetup" so that it stays 1.5-compatible. This change has nothing to do with GenericSetup from all I can tell. Please don't just say "OK, change it back if you want, but there may be traps elsewhere". I do not know what all needs to be changed. I'll be happy to do it, but I need to know what else is involved. yes, i believe the agreement was to try to keep 1.6 as close to 1.5 as possible, with the exception of GenericSetup. the types stuff is the greyest area, however, because the changes in the way TypeInfo objects are handled btn 1.5 and 2.0 has a considerable impact on the setup profiles and the import/export nodes. my original idea was to have the 1.6 types import adapter use the 2.0 style, containment-based profile format, but to generate 1.5 style TypeInfo objects. i haven't had time in recent weeks to keep up w/ all of the stuff that you've been doing, yuppie, but i do have a bit of concern that we're causing too much divergence btn 1.5 and 1.6 operationally. if we stray too far, then tres will stop forward-porting any 1.5 fixes that he might make... ;-). -r ___ 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 1.6 change broke Plone compatibility
Hi Rob! Hi Jens! Rob Miller wrote: Jens Vagelpohl wrote: On 20 Dec 2005, at 19:53, yuppie wrote: The intention was to make things consistent. CMF 1.5 and CMF 2.0 have different ways to register custom type info classes. Before that change both machineries were broken on the 1.6 branch because they were merged in an insane way. I fixed the new machinery because - most code used already the new machinery (and I thought that was Rob's intention) - this doesn't break many products I don't mind if you switch the 1.6 branch back to the old machinery, but there are more changes necessary than just reverting the last checkin. Like what exactly? With all due respect, the 1.6 branch should *not* break stuff that works find on 1.5. The specific goal for 1.6 was to be "1.5 plus GenericSetup" so that it stays 1.5-compatible. This change has nothing to do with GenericSetup from all I can tell. Please don't just say "OK, change it back if you want, but there may be traps elsewhere". I do not know what all needs to be changed. I'll be happy to do it, but I need to know what else is involved. Besides the import/export handlers Rob mentions below this affects all the TypesTool code that used 'typeClasses' (grep for it in 1.5) and the add forms for type infos. yes, i believe the agreement was to try to keep 1.6 as close to 1.5 as possible, with the exception of GenericSetup. the types stuff is the greyest area, however, because the changes in the way TypeInfo objects are handled btn 1.5 and 2.0 has a considerable impact on the setup profiles and the import/export nodes. my original idea was to have the 1.6 types import adapter use the 2.0 style, containment-based profile format, but to generate 1.5 style TypeInfo objects. i haven't had time in recent weeks to keep up w/ all of the stuff that you've been doing, yuppie, but i do have a bit of concern that we're causing too much divergence btn 1.5 and 1.6 operationally. if we stray too far, then tres will stop forward-porting any 1.5 fixes that he might make... ;-). I really don't care much about how this is resolved. But from Rob's checkins and the discussion following this mail http://mail.zope.org/pipermail/zope-cmf/2005-November/023399.html I had the impression that CMF 1.6 should provide backwards compatibility for Products written for Plone 2.1, not for Plone 2.1 itself. CMFDynamicViewFTI is an integral part of Plone 2.2 and I would be surprised if any other Plone product registers its own type info class. AFAICS the same applies to FlexibleTypeInformation and CPS. I don't think that my backports from the trunk widened that gap between 1.5 and 1.6. It existed from the beginning of the 1.6 branch. 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 1.6 change broke Plone compatibility
On 20 Dec 2005, at 21:56, yuppie wrote: yes, i believe the agreement was to try to keep 1.6 as close to 1.5 as possible, with the exception of GenericSetup. the types stuff is the greyest area, however, because the changes in the way TypeInfo objects are handled btn 1.5 and 2.0 has a considerable impact on the setup profiles and the import/export nodes. my original idea was to have the 1.6 types import adapter use the 2.0 style, containment-based profile format, but to generate 1.5 style TypeInfo objects. i haven't had time in recent weeks to keep up w/ all of the stuff that you've been doing, yuppie, but i do have a bit of concern that we're causing too much divergence btn 1.5 and 1.6 operationally. if we stray too far, then tres will stop forward-porting any 1.5 fixes that he might make... ;-). I really don't care much about how this is resolved. But from Rob's checkins and the discussion following this mail http://mail.zope.org/pipermail/zope-cmf/2005-November/023399.html I had the impression that CMF 1.6 should provide backwards compatibility for Products written for Plone 2.1, not for Plone 2.1 itself. CMFDynamicViewFTI is an integral part of Plone 2.2 and I would be surprised if any other Plone product registers its own type info class. AFAICS the same applies to FlexibleTypeInformation and CPS. I don't think that my backports from the trunk widened that gap between 1.5 and 1.6. It existed from the beginning of the 1.6 branch. I have a feeling that I am the first one who tried to run Plone 2.1 on CMF 1.6, which is why no one noticed before. I certainly would have spoken up if I had come across it as I have now. After reading the thread you mention, which isn't all that clear when it comes to outlining what the consequences of some of these code changes are, I'm confused. I think I can boil it down to one question: What is the use of the CMF 1.6 branch if it is not compatible to Plone 2.1/2.1.1 and 2.1.2 when it comes out, and possibly not even 2.2 since that's only a few months down the road? I don't quite understand the distinction between "compatible with products written for Plone 2.1 but not with Plone 2.1", I can't see any sense in that route... it all comes back to one question: What is the goal for the 1.6 branch? What specific audience is it targeted at? I can see what it's apparently *not* targeted at: People who work with Plone 2.1 - including those that might be interested in taking up GenericSetup for their Plone product. I had thought that was our audience. 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 1.6 change broke Plone compatibility
Hi! Jens Vagelpohl wrote: On 20 Dec 2005, at 21:56, yuppie wrote: I really don't care much about how this is resolved. But from Rob's checkins and the discussion following this mail http://mail.zope.org/pipermail/zope-cmf/2005-November/023399.html I had the impression that CMF 1.6 should provide backwards compatibility for Products written for Plone 2.1, not for Plone 2.1 itself. CMFDynamicViewFTI is an integral part of Plone 2.2 and I would be surprised if any other Plone product registers its own type info class. AFAICS the same applies to FlexibleTypeInformation and CPS. I don't think that my backports from the trunk widened that gap between 1.5 and 1.6. It existed from the beginning of the 1.6 branch. I have a feeling that I am the first one who tried to run Plone 2.1 on CMF 1.6, which is why no one noticed before. I certainly would have spoken up if I had come across it as I have now. It might be that the problem was hidden before I removed the typeClasses list. But the typeClasses list wasn't really used on the 1.6 branch. Only in manage_addTypeInformation, where the new way to register type info classes was ignored. After reading the thread you mention, which isn't all that clear when it comes to outlining what the consequences of some of these code changes are, I'm confused. I think I can boil it down to one question: What is the use of the CMF 1.6 branch if it is not compatible to Plone 2.1/2.1.1 and 2.1.2 when it comes out, and possibly not even 2.2 since that's only a few months down the road? I don't quite understand the distinction between "compatible with products written for Plone 2.1 but not with Plone 2.1", I can't see any sense in that route... it all comes back to one question: What is the goal for the 1.6 branch? What specific audience is it targeted at? I can see what it's apparently *not* targeted at: People who work with Plone 2.1 - including those that might be interested in taking up GenericSetup for their Plone product. I had thought that was our audience. AFAICT the original target audience were people that want to switch to Plone 2.2 and reuse Products written for 2.1. That might have changed over time, but the code never reflected that change. I'm fine with any decision as long as someone else does the necessary work. 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 1.6 change broke Plone compatibility
On 20 Dec 2005, at 23:32, yuppie wrote: After reading the thread you mention, which isn't all that clear when it comes to outlining what the consequences of some of these code changes are, I'm confused. I think I can boil it down to one question: What is the use of the CMF 1.6 branch if it is not compatible to Plone 2.1/2.1.1 and 2.1.2 when it comes out, and possibly not even 2.2 since that's only a few months down the road? I don't quite understand the distinction between "compatible with products written for Plone 2.1 but not with Plone 2.1", I can't see any sense in that route... it all comes back to one question: What is the goal for the 1.6 branch? What specific audience is it targeted at? I can see what it's apparently *not* targeted at: People who work with Plone 2.1 - including those that might be interested in taking up GenericSetup for their Plone product. I had thought that was our audience. AFAICT the original target audience were people that want to switch to Plone 2.2 and reuse Products written for 2.1. That might have changed over time, but the code never reflected that change. Unless someone fixes that CMFDynamicsomethingFTI thing (or the CMF 1.6 branch) people cannot even attempt to run Plone 2.1 or 2.2 against CMF 1.6. This is like a stalemate. Can you suggest how to add a new kind of factory information class similar to appending it to that typeClasses structure so Martin can fix the Plone code for whatever release they want to make CMF 1.6-compatible 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
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Unless someone fixes that CMFDynamicsomethingFTI thing (or the CMF 1.6 branch) people cannot even attempt to run Plone 2.1 or 2.2 against CMF 1.6. This is like a stalemate. Can you suggest how to add a new kind of factory information class similar to appending it to that typeClasses structure so Martin can fix the Plone code for whatever release they want to make CMF 1.6-compatible then? We can obviously fix this, so long as we maintain API compatability. A lot of products use CMFDynamicViewFTI, but only through the interfaces defined there and in CMFPlone/interfaces/browserdefault.py. *If* this is indeed a better solution, we'd need to know *how* to change CMFDynamicViewFTI to use the new machinery. That code is fairly small and simple, and someone who knows how an FTI works should hopefully not have much problem understanding how it works. If you can outline how to fix it, I'm sure we could get one applied and into a release timed to the switch to CMF 1.6. 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 1.6 change broke Plone compatibility
On Wed, 21 Dec 2005 00:32:02 +0100, yuppie <[EMAIL PROTECTED]> wrote: AFAICT the original target audience were people that want to switch to Plone 2.2 and reuse Products written for 2.1. Just a terminology correction here, the next version of Plone is 2.5, not 2.2 - we changed our version policy a while back: http://plone.org/products/plone/roadmap/114 http://plone.org/roadmap (Not that important for this discussion, but just a heads-up so you non-Plone people don't get confused about 2.2 vs. 2.5 when we talk about it later. :) -- _ 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
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Jens Vagelpohl wrote: On 20 Dec 2005, at 23:32, yuppie wrote: After reading the thread you mention, which isn't all that clear when it comes to outlining what the consequences of some of these code changes are, I'm confused. I think I can boil it down to one question: What is the use of the CMF 1.6 branch if it is not compatible to Plone 2.1/2.1.1 and 2.1.2 when it comes out, and possibly not even 2.2 since that's only a few months down the road? I don't quite understand the distinction between "compatible with products written for Plone 2.1 but not with Plone 2.1", I can't see any sense in that route... it all comes back to one question: What is the goal for the 1.6 branch? What specific audience is it targeted at? I can see what it's apparently *not* targeted at: People who work with Plone 2.1 - including those that might be interested in taking up GenericSetup for their Plone product. I had thought that was our audience. AFAICT the original target audience were people that want to switch to Plone 2.2 and reuse Products written for 2.1. That might have changed over time, but the code never reflected that change. Unless someone fixes that CMFDynamicsomethingFTI thing (or the CMF 1.6 branch) people cannot even attempt to run Plone 2.1 or 2.2 against CMF 1.6. This is like a stalemate. Can you suggest how to add a new kind of factory information class similar to appending it to that typeClasses structure so Martin can fix the Plone code for whatever release they want to make CMF 1.6-compatible then? The "new way" (exemplified by the way CMFCore itself registers 'Factory-based' type information) is: - make the class provide ITypeInformation (either directly or through ZCML), - five:registerClass the class (this makes it available in Products.meta_types and for IFAwareObjectManager, which the portal_types ZMI add menu uses), - register an IAdding for it, usually coded in browser/. Using the base class provided by CMFCore it's only a few lines. Florent -- 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
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Jens Vagelpohl wrote: [..] Thanks a lot Florent, I assume Martin can go off and do his magic with that description. Just a note in passing to those of us that are more on the CMF-users than developers side: Starting to look into this myself I just wasted a couple of minutes because of my outdated setup (I had a plain Zope-2.8.4-final release) Looking at INSTALL.txt from the CMF-1.6 bundle I found Requirements - Zope 2.8.1 or later ... so I thought I'm on the safe side but digging deeper one actually sees in GenericSetup.DEPENDENCIES.txt: Zope >= 2.8.5 Five >= 1.2 So I got a Zope-2.8.5-final only to realize later that this ships with Five-1.0.2 :-( Instead of upgrading Five, I thought I better get Zope-2.9.0b1 which wanted me to upgrade my Python to 2.4.2. I only have a 2.4.1 around with I took and now everything seems OK. Please don't get me wrong: this isn't to blame anyone but only to maybe save some other peoples time who want to jumb right in (and of course making the docs somewhat more explicit wouldn't hurt either). Raphael PS: the error I got with my outdated setup was: ImportError: cannot import name profile_registry on start-up while trying to load CMFCalendar. PPS: Playing in ZMI a bit I noticed that creating a CMF site TTW and selecting *all* optional extensions produces: Traceback (innermost last): Module ZPublisher.Publish, line 113, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 40, in call_object Module Products.CMFDefault.factory, line 63, in addConfiguredSite Module Products.GenericSetup.tool, line 245, in runAllImportSteps Module Products.GenericSetup.tool, line 711, in _doRunImportStep Module Products.CMFCore.exportimport.workflow, line 139, in importWorkflowTool Module Products.GenericSetup.utils, line 705, in importObjects Module Products.GenericSetup.utils, line 701, in importObjects Module Products.DCWorkflow.exportimport, line 79, in _importBody Module Products.DCWorkflow.exportimport, line 957, in _initDCWorkflow Module Products.DCWorkflow.exportimport, line 974, in _initDCWorkflowVariables Module OFS.ObjectManager, line 297, in _setObject Module Products.DCWorkflow.Variables, line 151, in _checkId Module Products.DCWorkflow.ContainerTab, line 54, in _checkId Bad Request: The id "action" is already in use. ___ 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 1.6 change broke Plone compatibility
Well now I'm *completely* confused. - Rocky Alexander Limi wrote: > On Wed, 21 Dec 2005 00:32:02 +0100, yuppie > <[EMAIL PROTECTED]> wrote: > >> AFAICT the original target audience were people that want to switch >> to Plone 2.2 and reuse Products written for 2.1. > > > Just a terminology correction here, the next version of Plone is 2.5, > not 2.2 - we changed our version policy a while back: > > http://plone.org/products/plone/roadmap/114 > http://plone.org/roadmap > > (Not that important for this discussion, but just a heads-up so you > non-Plone people don't get confused about 2.2 vs. 2.5 when we talk > about it later. :) > -- 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
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Raphael Ritz wrote: > Looking at INSTALL.txt from the CMF-1.6 bundle I found > > Requirements > > - Zope 2.8.1 or later > ... > > so I thought I'm on the safe side but digging deeper one > actually sees in GenericSetup.DEPENDENCIES.txt: > > Zope >= 2.8.5 > Five >= 1.2 > > So I got a Zope-2.8.5-final only to realize later that > this ships with Five-1.0.2 :-( > Your best bet is to install Zope 2.8.5-final and then install Five 1.2b (in your instance home Products dir). Not sure what other troubles Zope 2.9b1 would bring to the table here. - 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
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Florent Guillaume wrote: Jens Vagelpohl wrote: Unless someone fixes that CMFDynamicsomethingFTI thing (or the CMF 1.6 branch) people cannot even attempt to run Plone 2.1 or 2.2 against CMF 1.6. This is like a stalemate. Can you suggest how to add a new kind of factory information class similar to appending it to that typeClasses structure so Martin can fix the Plone code for whatever release they want to make CMF 1.6-compatible then? The "new way" (exemplified by the way CMFCore itself registers 'Factory-based' type information) is: - make the class provide ITypeInformation (either directly or through ZCML), - five:registerClass the class (this makes it available in Products.meta_types and for IFAwareObjectManager, which the portal_types ZMI add menu uses), - register an IAdding for it, usually coded in browser/. Using the base class provided by CMFCore it's only a few lines. Using registerClass in __init__.py should also work. (In Zope 2.8 you have to register the class explicitly for ITypeInformation using the 'interfaces' argument, Zope 2.9 looks itself for z3 interfaces.) In that case you can use a Zope 2 style add form instead of an add view. BTW: Custom catalog indexes and custom workflow definitions are registered the same way. They have to implement IPluggableIndex or IWorkflowDefinition. 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 1.6 change broke Plone compatibility
Rocky Burt wrote: Raphael Ritz wrote: Looking at INSTALL.txt from the CMF-1.6 bundle I found Requirements - Zope 2.8.1 or later ... so I thought I'm on the safe side but digging deeper one actually sees in GenericSetup.DEPENDENCIES.txt: Zope >= 2.8.5 Five >= 1.2 So I got a Zope-2.8.5-final only to realize later that this ships with Five-1.0.2 :-( Your best bet is to install Zope 2.8.5-final and then install Five 1.2b (in your instance home Products dir). Not sure what other troubles Zope 2.9b1 would bring to the table here. I'm currently working on having CPS work with CMF 1.6 branch and Zope 2.9 branch. I've had a few fixes to make already, today most things should work. A few more may come when I test deeper. Florent -- 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
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
apologies in advance for not engaging this conversation as deeply as i'd like to... i'm under the gun to get something done before leaving tomorrow for a brief holiday, back on the 29th. Jens Vagelpohl wrote: I don't quite understand the distinction between "compatible with products written for Plone 2.1 but not with Plone 2.1", I can't see any sense in that route... it all comes back to one question: What is the goal for the 1.6 branch? What specific audience is it targeted at? I can see what it's apparently *not* targeted at: People who work with Plone 2.1 - including those that might be interested in taking up GenericSetup for their Plone product. I had thought that was our audience. the original motivation behind my request for a CMF 1.6 release was so that it could be used as a basis for the next major Plone release, what is now being called Plone 2.5. this is because Plone would like to switch to using GenericSetup for its site instantiation and configuration, but using CMF 2.0 for our next release would cause too much breakage of Plone add-on products. CMF 1.6 makes it easier for Plone to not fall (again!) terribly behind CMF's development cycle. it would be great if Plone 2.1.X could work w/ CMF 1.6, but it is not absolutely necessary. yuppie implies that some of my commits contribute to the 2.1 breakage... that may be, b/c i wasn't really thinking too much about 2.1 when i was working. unfortunately, i don't have time to look even at my own work right now, for reasons mentioned above. if there are some reasonable changes we can make that would ensure CMF 1.6 would work with both Plone 2.1 and 2.5, then i'd probably be +1 for making the changes. this would need to be weighed against the amount of distance that it would put between the CMF 1.6 and CMF 2.0 setup code, though. when i get back from my visiting my family i'll take a look at the code and will actually formulate an informed opinion on what we should do... ;-) -r ___ 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 1.6 change broke Plone compatibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: > > On 22 Dec 2005, at 03:10, Rob Miller wrote: > >> Jens Vagelpohl wrote: >> >>> I don't quite understand the distinction between "compatible with >>> products written for Plone 2.1 but not with Plone 2.1", I can't see >>> any sense in that route... it all comes back to one question: What >>> is the goal for the 1.6 branch? What specific audience is it >>> targeted at? I can see what it's apparently *not* targeted at: >>> People who work with Plone 2.1 - including those that might be >>> interested in taking up GenericSetup for their Plone product. I had >>> thought that was our audience. >> >> >> the original motivation behind my request for a CMF 1.6 release was >> so that it could be used as a basis for the next major Plone release, >> what is now being called Plone 2.5. this is because Plone would like >> to switch to using GenericSetup for its site instantiation and >> configuration, but using CMF 2.0 for our next release would cause too >> much breakage of Plone add-on products. CMF 1.6 makes it easier for >> Plone to not fall (again!) terribly behind CMF's development cycle. > > > Just to put this into perspective, this is not some life-and-death > issue for me at this point, more a clarification issue. It wasn't clear > to me how limited the target audience for CMF 1.6 really will be. > > I think this brings up the need for a slightly more formalized planning > and release process. Given the requisite backing by at least the main > developers (meaning their agreement that they would actually use such a > thing) I'd like to set up a release plan page on zope.org that explains > a bit more what the goals for each major release are and which contains > timing information as well. The Plone roadmap page at > http://plone.org/roadmap (plone.org seems down currently) does a nice > job in that regard. I agree we need such a document, and already owe you some words around the topic. I'll work on setting up a back-channel conversation about it. > By the way, my technical problem of satisfying dependencies on > GenericSetup introduced by us switching to PAS without breaking a > production Plone 2.1 site have been solved by simply using GenericSetup > from the 1.6 branch and keeping everything else at CMF 1.5.4. I intend that "GenericSetup 1.0" will be releaseable (and released) from exactly that point (the tip of the 1.6 branch). 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 iD8DBQFDqtwl+gerLs4ltQ4RAgLhAJ0QeKCa6aad0Oi9mDJMDJ3Dx0ILwACghGN7 Q7K8P018LvFxJhcx79B/WZI= =6tOD -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 1.6 change broke Plone compatibility
Jens Vagelpohl wrote: I think this brings up the need for a slightly more formalized planning and release process. Given the requisite backing by at least the main developers (meaning their agreement that they would actually use such a thing) I'd like to set up a release plan page on zope.org that explains a bit more what the goals for each major release are and which contains timing information as well. The Plone roadmap page at http://plone.org/roadmap (plone.org seems down currently) does a nice job in that regard. Tres said: I agree we need such a document, and already owe you some words around the topic. I'll work on setting up a back-channel conversation about it. You can of course use the PloneSoftwareCenter :-) Either, you can create a project on plone.org/products and use the features there, or you can set up a standard Plone 2.1 site and install PloneSoftwareCenter (note that you currently need the 2.1-integration branch; we're working on getting a real release out) and its dependencies (ArchAddOn, ExternalStorage optional). Here, you can get the same roadmap features for any project. 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 1.6 change broke Plone compatibility
On Wed, 21 Dec 2005 13:29:09 +0100, Rocky Burt <[EMAIL PROTECTED]> wrote: Just a terminology correction here, the next version of Plone is 2.5, not 2.2 - we changed our version policy a while back: Well now I'm *completely* confused. s/Plone 2.2/Plone 2.5/g Better? ;) -- _ 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
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
On Thu, 22 Dec 2005 04:10:30 +0100, Rob Miller <[EMAIL PROTECTED]> wrote: it would be great if Plone 2.1.X could work w/ CMF 1.6, but it is not absolutely necessary. In general, we consider Plone tied to one particular CMF version (which is also why we ship with a particular version of the CMF), and we have never supported newer/older CMF releases in any version of Plone. This has practical consequences in making it one less deprecation chain cascading to pay attention to. So if the breakage (haven't followed the thread in detail) only occurs if you try using Plone 2.1 with CMF 1.6, that is indeed a non-issue. Plone 2.5 is the version that targets CMF 1.6. -- _ 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
Re: [Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
On 20 Dec 2005, at 13:10, Martin Aspeli wrote: Hi, The following checkin on the 1.6 branch, which looks like a pure cleanup item, completely breaks Plone 2.1 and up on CMF 1.6. I assume that was not the intention. http://svn.zope.org/CMF/branches/1.6/CMFCore/TypesTool.py? rev=40364&r1=40360&r2=40364 Do you know how it breaks Plone, exactly? What was this checkin intended to do? I don't know what the checkin was supposed to do apart from a cleanup, that's why I am asking Yvo. That "CMFDynamicViewFTI" doohickey (no idea what that is, really, but Plone needs it for some reason) tries to import "typeClasses" from CMFCore.TypesTool and add information about itself to it. See "fti.py" module. 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 1.6 change broke Plone compatibility
On 21 Dec 2005, at 11:14, Florent Guillaume wrote: Unless someone fixes that CMFDynamicsomethingFTI thing (or the CMF 1.6 branch) people cannot even attempt to run Plone 2.1 or 2.2 against CMF 1.6. This is like a stalemate. Can you suggest how to add a new kind of factory information class similar to appending it to that typeClasses structure so Martin can fix the Plone code for whatever release they want to make CMF 1.6- compatible then? The "new way" (exemplified by the way CMFCore itself registers 'Factory-based' type information) is: - make the class provide ITypeInformation (either directly or through ZCML), - five:registerClass the class (this makes it available in Products.meta_types and for IFAwareObjectManager, which the portal_types ZMI add menu uses), - register an IAdding for it, usually coded in browser/. Using the base class provided by CMFCore it's only a few lines. Thanks a lot Florent, I assume Martin can go off and do his magic with that description. 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 1.6 change broke Plone compatibility
On 21 Dec 2005, at 12:06, Raphael Ritz wrote: Starting to look into this myself I just wasted a couple of minutes because of my outdated setup (I had a plain Zope-2.8.4-final release) Looking at INSTALL.txt from the CMF-1.6 bundle I found Requirements - Zope 2.8.1 or later ... so I thought I'm on the safe side but digging deeper one actually sees in GenericSetup.DEPENDENCIES.txt: Yes, this will need some cleanup before the first beta. Instead of upgrading Five, I thought I better get Zope-2.9.0b1 which wanted me to upgrade my Python to 2.4.2. I only have a 2.4.1 around with I took and now everything seems OK. You can just download and put Five 1.2b into your INSTANCE_HOME, it will be loaded in preference to the stuff in the SOFTWARE_HOME 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 1.6 change broke Plone compatibility
On 22 Dec 2005, at 03:10, Rob Miller wrote: Jens Vagelpohl wrote: I don't quite understand the distinction between "compatible with products written for Plone 2.1 but not with Plone 2.1", I can't see any sense in that route... it all comes back to one question: What is the goal for the 1.6 branch? What specific audience is it targeted at? I can see what it's apparently *not* targeted at: People who work with Plone 2.1 - including those that might be interested in taking up GenericSetup for their Plone product. I had thought that was our audience. the original motivation behind my request for a CMF 1.6 release was so that it could be used as a basis for the next major Plone release, what is now being called Plone 2.5. this is because Plone would like to switch to using GenericSetup for its site instantiation and configuration, but using CMF 2.0 for our next release would cause too much breakage of Plone add-on products. CMF 1.6 makes it easier for Plone to not fall (again!) terribly behind CMF's development cycle. Just to put this into perspective, this is not some life-and-death issue for me at this point, more a clarification issue. It wasn't clear to me how limited the target audience for CMF 1.6 really will be. I think this brings up the need for a slightly more formalized planning and release process. Given the requisite backing by at least the main developers (meaning their agreement that they would actually use such a thing) I'd like to set up a release plan page on zope.org that explains a bit more what the goals for each major release are and which contains timing information as well. The Plone roadmap page at http://plone.org/roadmap (plone.org seems down currently) does a nice job in that regard. By the way, my technical problem of satisfying dependencies on GenericSetup introduced by us switching to PAS without breaking a production Plone 2.1 site have been solved by simply using GenericSetup from the 1.6 branch and keeping everything else at CMF 1.5.4. 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 1.6 change broke Plone compatibility
On 22 Dec 2005, at 17:09, Martin Aspeli wrote: Jens Vagelpohl wrote: I think this brings up the need for a slightly more formalized planning and release process. Given the requisite backing by at least the main developers (meaning their agreement that they would actually use such a thing) I'd like to set up a release plan page on zope.org that explains a bit more what the goals for each major release are and which contains timing information as well. The Plone roadmap page at http://plone.org/roadmap (plone.org seems down currently) does a nice job in that regard. Tres said: I agree we need such a document, and already owe you some words around the topic. I'll work on setting up a back-channel conversation about it. You can of course use the PloneSoftwareCenter :-) Complete overkill, sorry. We're dealing with one project here, and for starters we need a simple document, and then go from there. Matter of fact a simple Wiki would be good, probably right underneath www.zope.org/Products/CMF. 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-1.6 branch created (was Re: backporting GenericSetup to CMF-1.5)
Jens Vagelpohl wrote: On 14 Nov 2005, at 22:28, Rob Miller wrote: okay, i've created a CMF-1.6 branch that has branched everything from CMF-1.5 with the exception of CMFSetup and GenericSetup, which are svn:externals from the CMF trunk. note that i've haven't actually started any backporting yet, and as such this branch is completely non-functional. i hope to actually start work on it tomorrow evening (california time). By the way, since this discussion is happening on the zope-dev list right now as well, please don't just jump in and create release branches. The release manager should do that, after reaching a consensus of what it should contain and when to cut it. We should maintain some semblance of order here. ah, okay. sorry 'bout that. -r ___ 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
