Re: [Zope-CMF] Re: Plone participation in the CMF list
Geoff Davis wrote at 2005-8-1 12:53 -0400: > ... >* Are there any particular things in Plone that you think should be pushed >down into CMF? "PloneBatch" seems quite useful. I do not use Plone (due to its GPL) but I found the "FactoryTool" useful. Because it is GPL, I studied its functionality and then made my own implementation (independant of the Plone one). -- Dieter ___ 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.5.3 beta?
Florent Guillaume wrote: However I'd like to urge the "Plone guys" (95% of which don't bother to read or post in this list) count me among the "plone guys" who lurk on this list... and among the growing pool of reasonable folks who will advocate for and work towards convergence. -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: Plone participation in the CMF list
Florent Guillaume wrote: Tres Seaver <[EMAIL PROTECTED]> wrote: I think the discussion around Archetypes, in particular, ended up stalled over the question of whether to "code generation" design should be preferred over "configuration-based" design (as found in CPSSchemas, for instance). Also now that Zope 3 is taking more and more importance in CMF, any schema-based solution should be based on Zope 3 schemas. IMO both Archetypes and CPSSchemas are too big frameworks to include in CMF. maybe i'm being naive here, but what's wrong w/ trying to get them all to play together? i've been doing work on ATSchemaEditor and have been thinking about ways to bring it forward. the first obvious choice is to use adapters to designate an object as a schema consumer (ISchemaConsumer), able to be served up its schema from a schema provider (ISchemaProvider). even just within the AT world, there is the problem of schemas that will be partly defined via python code, and partly defined in blob space via a TTW schema editor. the use of an ISchemaDefiner interface could possibly be used as a bridge between any schema definition framework (AT, Z3, CPS, XML, blob-space, etc.) and the schema providing layer. of course, some things are bound to get lost in translation, and there will probably be some strongly held (and differing) opinions on what, exactly, a ready-to-be-consumed schema should specify, but an abstraction layer like this in CMF would at least make it easier for the rest of us to plug in. -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: Plone participation in the CMF list
Jens Vagelpohl wrote: On 2 Aug 2005, at 13:27, Florent Guillaume wrote: Tres Seaver <[EMAIL PROTECTED]> wrote: I think the discussion around Archetypes, in particular, ended up stalled over the question of whether to "code generation" design should be preferred over "configuration-based" design (as found in CPSSchemas, for instance). Also now that Zope 3 is taking more and more importance in CMF, any schema-based solution should be based on Zope 3 schemas. IMO both Archetypes and CPSSchemas are too big frameworks to include in CMF. Absolutely. I think at least at the CMF developer level we're in agreement that the direction is "towards Zope 3 via Five". Any decision we make about including new code must be made with that in mind. Which leaves the question, because I simply don't know: What is the direction Plone is moving in? the plone developer community is far from monolithic, and i don't claim to speak for everyone, but i'd say the moving "towards Zope 3 via Five" is a fair description. the most likely major initial effort here will probably be to reimplement the Archetypes template system, replacing the skins template mess that we have currently with an entirely views-based system. sidnei has already started a "Fate" product that is likely to be the basis for this effort. -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: Plone participation in the CMF list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: > >> The general mindset of most Plone developers, as I perceive it from >> the CMF side, seems to be one of "I'm in Plone code, and I know what >> to do here, and I don't need to look beyond my world". Very few >> developers have a broader view and even think of pushing generic >> functionality or even specific improvements to core functionality >> that originates in the CMF down to the CMF level. It seems easier for >> them to monkeypatch and override directly inside Plone code. > > > I think you're right, at least as pertains to myself. It's not a > concious decision, I have nothing against CMF and the developers I've > met that are in CMF core I get on with well. However, I think this > mentality resides in a lot (if not the majority) of Plone developers. > Some speculations as to why this may be are: > > - There is no clear strategy or leadership on how this integration > should work. What code is CMF worthy? What isn't? Plone gets stuff > done principally because people yell at other people to help out. If > person X in Plone could say "this looks like something that should be > in CMF, send an email to person Y in CMF and get him to take a look", > and then person Y could respond in a positive way immediately, then the > poor programmer would be more likely to feel like he knew what he was > doing. Currently, that happens rarely. Maybe because... > > - CMF is "infrastructure" and low-level. Such code tends to have more > intertia, and the risk of making mistakes is higher, so one may presume > the best thing to do is to "leave it to the professionals" > > - Plone still has a lot of "process" problems, but with the > PloneHelpCenter, the PLIP process, the collector (sucky though it is) > and the active leadership of people like limi and lurker, we have at > least a fairly good idea of how new features get in, how bugs get > tracked, and rough areas of responsibility that emerge. To an outside, > at least, the CMF world seems to be more difficult to slot into. I'm > sure it isn't, just that I don't know where to go to find out how to > behave well in the community. > > - The CMF community feels less active (perhaps for obvious reasons - > it's more of a stable technology; just reading the list intermittently, > it feels like it's in maintenance-and-blue-skies-future mode, which may > not be true, of course). There's always life and excitement on the > plone-dev and plone-user lists, and in #plone on IRC, so our attention > tends to be focused there. We get to know some other developers, we > start helping out, and so our world becomes confined to that one. This > is obviously a self-reinforcing process. > > - It's yet another contributor agreement and bureaucratic process to > go through; in fact, it sounds even worse than Plone's. So, the > marginal cost for a developer to do it "just for one little fix" is too > high (of course over time, it may not be, but that's moot there and then). > > - The release cycles are not synced. We seem to work best to > deadlines, so there's been a great push towards Plone 2.1 in the past > couple of months. Hence, there may not be time to generalise, test, > talk to CMF and CPS and other people and get something reusable into > CMF. A lot (well, maybe not that much) of stuff in Plone is marked > "XXX: Should probably move to CMF". > > - CMF is less sexy. Getting features into Plone typically mean higher > visibility. For those of us who base custom CMS solutions on top of > Plone, it also puts them closer to our own skillset and toolchain. > > - Plone is (probably) better documented and more widely understood > than the CMF underpinnings. It's not that hard when you know Plone, so > it's probably more of a psychological barrier, but it seems easier to > get a grasp on Plone. > > So, I guess my suggestions for what we can do to improve this situation > may be (some of these may already be happening, but it doesn't hurt to > spell it out) > > - Encourage Plone people to read the CMF list > > - Encourage CMF people to read the Plone dev list, and shoot in > whenever something seems to be CMF material > > - Encourage CMF people to be in #plone, for the same reason > > - Have the senior Plone and CMF people work out some guidelines for > how better to encourage cross-pollination of ideas and code, and > follow through on it day-to-day. > > - Make the CMF contribution process as seamless as possible > > - Produce "how to be a good CMF contributor" documentation that's easy > for a Plone developer to grasp without taking the whole weekend off > reading logs, code and lengthy manuals (incidentally, we're working on > a similar thing for Plone core. We should collaborate here too. I can > give you access to the in-process document if you're interested in > seeing where we are so far). > > - Work *transparently* and *open
[Zope-CMF] Re: Re: Plone participation in the CMF list
The general mindset of most Plone developers, as I perceive it from the CMF side, seems to be one of "I'm in Plone code, and I know what to do here, and I don't need to look beyond my world". Very few developers have a broader view and even think of pushing generic functionality or even specific improvements to core functionality that originates in the CMF down to the CMF level. It seems easier for them to monkeypatch and override directly inside Plone code. I think you're right, at least as pertains to myself. It's not a concious decision, I have nothing against CMF and the developers I've met that are in CMF core I get on with well. However, I think this mentality resides in a lot (if not the majority) of Plone developers. Some speculations as to why this may be are: - There is no clear strategy or leadership on how this integration should work. What code is CMF worthy? What isn't? Plone gets stuff done principally because people yell at other people to help out. If person X in Plone could say "this looks like something that should be in CMF, send an email to person Y in CMF and get him to take a look", and then person Y could respond in a positive way immediately, then the poor programmer would be more likely to feel like he knew what he was doing. Currently, that happens rarely. Maybe because... - CMF is "infrastructure" and low-level. Such code tends to have more intertia, and the risk of making mistakes is higher, so one may presume the best thing to do is to "leave it to the professionals" - Plone still has a lot of "process" problems, but with the PloneHelpCenter, the PLIP process, the collector (sucky though it is) and the active leadership of people like limi and lurker, we have at least a fairly good idea of how new features get in, how bugs get tracked, and rough areas of responsibility that emerge. To an outside, at least, the CMF world seems to be more difficult to slot into. I'm sure it isn't, just that I don't know where to go to find out how to behave well in the community. - The CMF community feels less active (perhaps for obvious reasons - it's more of a stable technology; just reading the list intermittently, it feels like it's in maintenance-and-blue-skies-future mode, which may not be true, of course). There's always life and excitement on the plone-dev and plone-user lists, and in #plone on IRC, so our attention tends to be focused there. We get to know some other developers, we start helping out, and so our world becomes confined to that one. This is obviously a self-reinforcing process. - It's yet another contributor agreement and bureaucratic process to go through; in fact, it sounds even worse than Plone's. So, the marginal cost for a developer to do it "just for one little fix" is too high (of course over time, it may not be, but that's moot there and then). - The release cycles are not synced. We seem to work best to deadlines, so there's been a great push towards Plone 2.1 in the past couple of months. Hence, there may not be time to generalise, test, talk to CMF and CPS and other people and get something reusable into CMF. A lot (well, maybe not that much) of stuff in Plone is marked "XXX: Should probably move to CMF". - CMF is less sexy. Getting features into Plone typically mean higher visibility. For those of us who base custom CMS solutions on top of Plone, it also puts them closer to our own skillset and toolchain. - Plone is (probably) better documented and more widely understood than the CMF underpinnings. It's not that hard when you know Plone, so it's probably more of a psychological barrier, but it seems easier to get a grasp on Plone. So, I guess my suggestions for what we can do to improve this situation may be (some of these may already be happening, but it doesn't hurt to spell it out) - Encourage Plone people to read the CMF list - Encourage CMF people to read the Plone dev list, and shoot in whenever something seems to be CMF material - Encourage CMF people to be in #plone, for the same reason - Have the senior Plone and CMF people work out some guidelines for how better to encourage cross-pollination of ideas and code, and follow through on it day-to-day. - Make the CMF contribution process as seamless as possible - Produce "how to be a good CMF contributor" documentation that's easy for a Plone developer to grasp without taking the whole weekend off reading logs, code and lengthy manuals (incidentally, we're working on a similar thing for Plone core. We should collaborate here too. I can give you access to the in-process document if you're interested in seeing where we are so far). - Work *transparently* and *openly* on the Z3/Five/ECM efforts, with Plone, CMF and non-Plone CMF users. Cross-post major discussions here to all relevant lists, and produce easy-to-follow documentation about the stat
[Zope-CMF] Re: Plone participation in the CMF list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florent Guillaume wrote: > Tres Seaver <[EMAIL PROTECTED]> wrote: > >>I think the discussion around Archetypes, in particular, ended up >>stalled over the question of whether to "code generation" design >>should be preferred over "configuration-based" design (as found in >>CPSSchemas, for instance). > > > Also now that Zope 3 is taking more and more importance in CMF, any > schema-based solution should be based on Zope 3 schemas. IMO both > Archetypes and CPSSchemas are too big frameworks to include in CMF. +1, as long as that doesn't mean slavish adherence to the "all schemas must be defined as interfaces in Python code" model prevalent today in Z3. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC74ad+gerLs4ltQ4RAtkpAJ0TTXObeMsj3KFNCFDvhbGQsHnQVACfU47g HKVJ5ZkgC7X7Z7cW5ASKgig= =z0hZ -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: Plone participation in the CMF list
On 2 Aug 2005, at 13:27, Florent Guillaume wrote: Tres Seaver <[EMAIL PROTECTED]> wrote: I think the discussion around Archetypes, in particular, ended up stalled over the question of whether to "code generation" design should be preferred over "configuration-based" design (as found in CPSSchemas, for instance). Also now that Zope 3 is taking more and more importance in CMF, any schema-based solution should be based on Zope 3 schemas. IMO both Archetypes and CPSSchemas are too big frameworks to include in CMF. Absolutely. I think at least at the CMF developer level we're in agreement that the direction is "towards Zope 3 via Five". Any decision we make about including new code must be made with that in mind. Which leaves the question, because I simply don't know: What is the direction Plone is moving in? 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: Plone participation in the CMF list
Tres Seaver <[EMAIL PROTECTED]> wrote: > I think the discussion around Archetypes, in particular, ended up > stalled over the question of whether to "code generation" design > should be preferred over "configuration-based" design (as found in > CPSSchemas, for instance). Also now that Zope 3 is taking more and more importance in CMF, any schema-based solution should be based on Zope 3 schemas. IMO both Archetypes and CPSSchemas are too big frameworks to include in CMF. 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: Plone participation in the CMF list
Hi! Geoff Davis wrote: On Mon, 01 Aug 2005 17:30:20 +0100, Jens Vagelpohl wrote: It would help everyone if the CMF side opened up a little more to ideas coming down from Plone, and if the Plone side stopped reinventing wheels that would be much better off (and benefit everyone) in the CMF or other non-Plone core products. Perhaps some specifics would help. * What wheels do you think Plone has reinvented? * Are there any particular things in Plone that you think should be pushed down into CMF? If you ask me most of the install/setup/migration stuff of Plone is implemented in the wrong layer. The way Plone uses the CMFDefault PortalGenerator and customizes CMFDefault settings looks quite strange. AFAICS Plone could benefit from CMFSetup and CMFSetup could benefit from the experience Plone people have with install/setup/migration tasks. CMFSetup still needs a lot of work, but it could became a generic framework that replaces (at least big parts of) CMFQuickInstallerTool and the Plone migrations machinery. CPS people already contribute to CMFSetup. In general I'm skeptic if people want to contribute new products. CMF still needs a lot of consolidation work. And CMF has to be modernized to benefit from Five features. I guess the first thing we need is a unit test framework that is more similar to Zope 3 and Plone tests. Most people not familiar with CMF unit tests have problems writing new ones. I don't like the idea to depend on an external product, but maybe CMFTestCase could become part of CMF? Just my 2 cents. 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: xsl/xul and FSPageTemplate
On 2 Aug 2005, at 11:11, Duncan Booth wrote: Julien Anguenot wrote: Why don't you create your own FSXSLTemplate object ? It's pretty easy to register this kind of objects within the CMF using the dedicated registry. It might even sub-class FSPageTemplate if it makes sense in your case. I would do it like this myself. We could, but kupu seems like the wrong place to be registering such as general purpose object. A better place might be Archetypes (both kupu and archetypes currently register xsl file extensions), but it sounds to me like a general enough requirement that possibly it should just be in CMFCore (also, kupu can run without Archetypes being present & vice versa, so if either defined a suitable class they would both need to define it). CMFCore is probably a good-enough place. If you want to provide code I'll shepherd it into Subversion, into the trunk and, after the 1.5.3 final is released, the 1.5 branch. Don't forget to add the necessary unit tests etc. 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: xsl/xul and FSPageTemplate
Julien Anguenot wrote: > Why don't you create your own FSXSLTemplate object ? It's pretty easy to > register this kind of objects within the CMF using the dedicated > registry. It might even sub-class FSPageTemplate if it makes sense in > your case. I would do it like this myself. We could, but kupu seems like the wrong place to be registering such as general purpose object. A better place might be Archetypes (both kupu and archetypes currently register xsl file extensions), but it sounds to me like a general enough requirement that possibly it should just be in CMFCore (also, kupu can run without Archetypes being present & vice versa, so if either defined a suitable class they would both need to define it). Yes, subclassing FSPageTemplate to not lose the extension by default would be sufficient. ___ 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] CMF 1.5.3 beta?
Alright, it's out now. I probably spent 90% of the last two hours fighting zope.org which was near-unresponsive... Anyway, since this is a beta the usual precautions apply: - No non-critical-bugfix checkins on the CMF 1.5 branch until CMF 1.5.3 final is out - Please help test the release, especially the changes shown below that have flown in since the last release. CMF 1.5.3 will be the release Plone 2.1 final is based on (if nothing bad happens in the meantime), it will see very widespread use, so good quality control is important. I am hoping we can have a quick beta cycle with just this beta release. Please test! ;) --- Bugs Fixed - Changed the INSTALL_SVN instructions to conform to the new branch and tag naming scheme instituted for the subversion repository. - Apply an interim fix for slow pathwalking implementation in development mode on Windows (http://www.zope.org/Collectors/ CMF/367) Note that a better fix would be to leverage pywin32 APIs for file / directory monitoring. - FSObject.manage_doCustomize() was broken for folderish objects on Zope 2.8 because manage_permission requires a context to work. (see http://www.zope.org/Collectors/CMF/368) - CMFCore/FSPropertiesObject and CMFCore/FSMetadata: Removed a wrongly inserted DeprecationWarning in the FSPropertiesObject class and put it into the FSMetadata class. We are not deprecating ".props" files, but ".properties" and ".security". - Change CVS checkout documentation to their equivalent Subversion instructions - In CMFSetup, make sure to give special treatment to both CVS and .svn folders where this is necessary (e.g. to implicitly skip them when importing profiles) - Made sure FSDVTest always deletes its temporary folder on tearDown. (http://www.zope.org/Collectors/CMF/106) - Fix DefaultWorkflowDefinition bug on isActionSupported() for the keywargs support to reflect DCWorkflowDefinition changes. Add a test case for this definition as well. Others - CMFCatalogAware: reindexObjectSecurity() now always reindexes the catalog objects without changing their catalog uid. This is useful for third-party code that indexes objects with special uids. - 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] CMF 1.5.3-beta released
The CMF developer community and Zope Corporation are pleased to announce the release of version 1.5.3-beta of the Zope Content Management Framework (CMF). This release is intended for testing purposes only; we do not recommend deploying it to production servers. The final release of version 1.5.3 is expected to land within about 10 days. What is the CMF? The Zope Content Management Framework provides a set of services and content objects useful for building highly dynamic, content-oriented portal sites. As packaged, the CMF generates a site much like the Zope.org site. The CMF is intended to be easily customizable, in terms of both the types of content used and the policies and services it provides. Where do I get it? Download it from http://zope.org/Products/CMF/CMF-1.5.3-beta Points of interest include: - "Windows ZIP file", http://zope.org/Products/CMF/CMF-1.5.3-beta/CMF-1.5.3-beta.zip - "Unix tar/gzip archive", http://zope.org/Products/CMF/CMF-1.5.3-beta/CMF-1.5.3- beta.tar.gz . - "Release notes", http://zope.org/Products/CMF/CMF-1.5.3-beta/README.txt - "Change history", http://zope.org/Products/CMF/CMF-1.5.3-beta/CHANGES.txt - "Installation instructions", http://zope.org/Products/CMF/CMF-1.5.3-beta/INSTALL.txt Where do I go to learn more? The CMF mailing list ([EMAIL PROTECTED]) has many participants who are active in supporting the CMF. ...to report bugs? The "CMF Collector":http://zope.org/Collectors/CMF is the place to report bugs (please search for existing reports of your issue first!) - Jens Vagelpohl [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] CMF Collector: Open Issues
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open efge - "CMFSetup: provide non-ascii im- and exports", [Accepted] http://www.zope.org/Collectors/CMF/292 - "CMFSetup doesn't correctly detect DCWorkflow on export", [Accepted] http://www.zope.org/Collectors/CMF/298 jens - "Confusing date criteria in CMFTopic", [Accepted] http://www.zope.org/Collectors/CMF/339 - "FSPropertiesObject.py cannot handle multiline input for lines, text attributes", [Accepted] http://www.zope.org/Collectors/CMF/271 mhammond - "Windows DevelopmentMode penalty in CMFCore.DirectoryView", [Accepted] http://www.zope.org/Collectors/CMF/366 mj - "CMFSetup doesn't correctly detect DCWorkflow on export", [Accepted] http://www.zope.org/Collectors/CMF/298 Pending / Deferred Issues - "Debuggable scripts", [Deferred] http://www.zope.org/Collectors/CMF/194 - "CMFCalendar weekday locale issue", [Pending] http://www.zope.org/Collectors/CMF/237 - "CMFCalendar: Events ending on midnight", [Pending] http://www.zope.org/Collectors/CMF/246 - "Wrong cache association for FSObject", [Pending] http://www.zope.org/Collectors/CMF/255 - "CMFSetup: Windows exports contain CR/LF, LF and even CR newlines", [Pending] http://www.zope.org/Collectors/CMF/266 - "PortalCatalog.ZopeFindAndApply should probably also search in opaqueItems", [Pending] http://www.zope.org/Collectors/CMF/296 - "WorkflowTool should recurse into opaqueItems", [Pending] http://www.zope.org/Collectors/CMF/297 - "add External Methods to workflow script handling", [Pending] http://www.zope.org/Collectors/CMF/329 - "Can't invalidate skin items in a RAMCacheManager", [Pending] http://www.zope.org/Collectors/CMF/343 - "reconfig_form page fails", [Pending] http://www.zope.org/Collectors/CMF/364 Pending / Deferred Features - "Favorite.py: queries and anchors in remote_url", [Pending] http://www.zope.org/Collectors/CMF/26 - "Allow flexible date editing in Event.py (CMFCalendar)", [Pending] http://www.zope.org/Collectors/CMF/40 - "Topic should be catalogued", [Pending] http://www.zope.org/Collectors/CMF/53 - "DefaultDublinCore should have Creator property", [Pending] http://www.zope.org/Collectors/CMF/61 - "Make changeFromProperties accept sequences too", [Pending] http://www.zope.org/Collectors/CMF/99 - "path criteria on Topic should honor VHM", [Pending] http://www.zope.org/Collectors/CMF/111 - "Document.py: universal newlines", [Pending] http://www.zope.org/Collectors/CMF/174 - "Permissions in PortalFolder: invokeFactory()", [Pending] http://www.zope.org/Collectors/CMF/175 - "Add condition for transition's action like other action", [Pending] http://www.zope.org/Collectors/CMF/207 - "Major action enhancement", [Pending] http://www.zope.org/Collectors/CMF/232 - "portal_type is undefined in initialization code", [Pending] http://www.zope.org/Collectors/CMF/248 - "Action._listsActions() should be more safe", [Pending] http://www.zope.org/Collectors/CMF/253 - "FSZSQLMethod.py", [Pending] http://www.zope.org/Collectors/CMF/273 - "Expose Document text_format metadata", [Pending] http://www.zope.org/Collectors/CMF/285 - "customization of type of homefolder on creation", [Pending] http://www.zope.org/Collectors/CMF/288 - "Allow contentFilter to use review_state", [Pending] http://www.zope.org/Collectors/CMF/294 - "CMFTopic Does Not Cache", [Pending] http://www.zope.org/Collectors/CMF/295 - "Wishlist: a flag that tags the selected action.", [Pending] http://www.zope.org/Collectors/CMF/301 - "CMFDefault should make use of allowCreate()", [Pending] http://www.zope.org/Collectors/CMF/340 ___ 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
