[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 - 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 - CMFCalendar weekday locale issue, [Pending] http://www.zope.org/Collectors/CMF/237 - 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 - CMFSetup: Workflow Tool export fails with workflows which have scripts, [Pending] http://www.zope.org/Collectors/CMF/373 - CMFCore.Skinnable.SkinnableObjectManager can merge skin data, [Pending] http://www.zope.org/Collectors/CMF/375 - Proxy Roles does't work for a Script using portal_catalog.searchResults, [Pending] http://www.zope.org/Collectors/CMF/380 - WorkflowAction deprecated warning should not printed for WorkflowMethod, [Pending] http://www.zope.org/Collectors/CMF/388 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 - 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 - 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 - Nested Skins, [Pending] http://www.zope.org/Collectors/CMF/377 - CatalogVariableProvider code + tests, [Pending] http://www.zope.org/Collectors/CMF/378 - manage_doCustomize() : minor additions, [Pending] http://www.zope.org/Collectors/CMF/382 ___ 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] Trying to customize CMF login to use email rather than userid
Deb Lewis wrote: Configuration: Zope 2.7.7, CMF 1.4.8; also GRUF (GroupUserFolder) 3.3 Why are you using such old and crufty software? 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] Help with Frostbite
I installed Frostbite managed to complete most of the Installation steps from the README.txt file. I am stuck on step 7. 7. Add an instance of your generated product's class to the skins tool of your site. The skins tool (portal_skins folder, i assumed) has only 2 items in the dropdown: 1. Filesystem directory view 2. Skin custom folder So how do I add an instance of my generated product's class? Any and all help appreciated. Suresh ___ 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] [dev] CMFSetup/GenericSetup: moving code around - a small proposal
Hi! Right now the structure of the setup modules is a bit wired. I hope we can simplify that (on the trunk / for CMF 2.0). The big picture: In the long run CMFSetup becomes obsolete. The framework was already moved to GenericSetup and the setup handlers should become part of the related products. For now CMFSetup is a legacy product that a) provides backwards compatibility for CMF 1.5 profiles / setup tools and b) contains some setup handlers that depend on the old ImportConfiguratorBase / ExportConfiguratorBase classes. The current structure of setup modules in other products: CMFActionIcons exportimport CMFCalendar setuphandlers CMFCore exportimport nodeadapters CMFDefault setuphandlers and on behalf of Zope products GenericSetup.MailHost adapters GenericSetup.PluginIndexes adapters GenericSetup.ZCatalog adapters GenericSetup.ZCTextIndex adapters Proposed changes: 1.) CMFCalendar.setuphandlers and CMFDefault.setuphandlers contain provisional 'importVarious' handlers. As soon as these handlers become obsolete these modules should be removed. 2.) All setup related code should be in *one* sub-module of each product. I propose to use 'exportimport'. The also means to rename GenericSetup.*.adapters to GenericSetup.*.exportimport. If there are no objections or better ideas I'll convert CMFCore.exportimport to a folder and move the CMFCore.nodeadapters code into it. And rename 'adapters' modules to 'exportimport'. 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 and Five views: hooking up POST
On 10/17/05, yuppie [EMAIL PROTECTED] wrote: I know that pattern, but I don't like it. [...] The code on the goldegg-folder_contents branch processes the input in the __call__ method of the view class. The template is only invoked if needed. It's much cleaner to use the template just for displaying results, not for triggering controllers. That's purely a matter of taste. From a principal standpoint I don't think there is any difference, really. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF and Five views: hooking up POST
Hi Lennart! Lennart Regebro wrote: On 10/17/05, yuppie y.2005--E2EsyBC0hj3+aS/[EMAIL PROTECTED] wrote: I know that pattern, but I don't like it. [...] The code on the goldegg-folder_contents branch processes the input in the __call__ method of the view class. The template is only invoked if needed. It's much cleaner to use the template just for displaying results, not for triggering controllers. That's purely a matter of taste. From a principal standpoint I don't think there is any difference, really. I don't think so: 1.) If you start rendering the default view before the controller has finished you need extra code to abort the rendering if necessary. E.g. a tal:condition that wraps the whole template. 2.) A cleaner separation of controller calls and view rendering makes the code simpler and therefore easier to write and maintain. 3.) Rendering useless views wastes resources. 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 and Five views: hooking up POST
Hi Tres! Tres Seaver wrote: Lennart Regebro wrote: On 10/17/05, yuppie y.2005--E2EsyBC0hj3+aS/[EMAIL PROTECTED] wrote: I know that pattern, but I don't like it. [...] The code on the goldegg-folder_contents branch processes the input in the __call__ method of the view class. The template is only invoked if needed. It's much cleaner to use the template just for displaying results, not for triggering controllers. That's purely a matter of taste. From a principal standpoint I don't think there is any difference, really. I think we might be able to come up with a heuristic for choosing between the two patterns (this might be a mini pattern language, if refined): - For simple forms, which redisplay themselves even after a successful POST, and which do not redirect, prefer a template-driven version, and make the form self-posting; in ZCML, use browser:page with the 'template' attribute). The classic 'document_edit' form fits this bill, I think. I don't know many use cases for 'simple' forms. 'document_edit' redirects to itself if 'change' was successful and to view if 'change_and_view' was successful. The redirect after a successful update is necessary to avoid further changes if people reload the page. And even if we have a 'simple' form: A customized '__call__' method is simpler than a 'Update' method that has to be called from the template. - If you have to add logic to the template to cope with possible redirects, then publish a method of the view, and have the view redirect or return a template; in ZCML, use browser:page with the 'attribute' variant. Add forms fit this pattern, as well as the folder_contents stuff that Yuppie has done. If we call an 'attribute' we can't specify the template in ZCML. We have to hard-code the template in the view class. Using the '__call__' method we can get the advantages of both patterns. The folder_contents stuff uses the '__call__' method. - For a set of inter-related pages sharing common view logic, you may end up mixing and matching -- the ':method' bit on submit button names is a way to get off the original template when needed. ZCML for this case may either be a mixture of the 'template' and 'attribute' variants of browser:page, or else brower:view with several page subdirectives. I don't like using ':method' because that pattern uses the same URL for different pages. But I never tried to use ':method' with views. Does that even 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] Five views / redirects
Sorry in advance if this is a dumbo question, but I'm having trouble seeing the style to follow in the following situation: - user calls a url, say /object/tuesday_message - if today's date is a tuesday, render 'tuesday.pt' - otherwise render 'no_message.pt' both tuesday.pt and no_message.pt are proper templates which need to follow the site's main template, and have some logic in a view class. Without views, I would make tuesday_message a python script, and return the required template directly with context.tuesday() or context.no_message(). But what's the best way to do this with a view: I don't want users to be able to access the templates directly, so I can't redirect between them, and the two templates are sufficiently different not to be combined together in an if-else type way. TIA pete ___ 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: Help with Frostbite
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sureshvv wrote: Tres Seaver wrote: I don't see how that could be -- the skins tool add list is not filtered at all in stock CMF or in Plone. What software provides your skins tool? Plone 2.1 I can't reproduce this issue in a Zope with Plone 2.1 installed, Unless you can tell me what the skins tool is doing that keeps you from being able to add arbitrary objects to it, I doubt I can help you (it might be the source of the rest of your problem, as well). 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 iD8DBQFDU/fe+gerLs4ltQ4RAj5WAJ43MFiW3M98YhwiLDa+g8wvOAN+kACgy/3o FKZEYak7B3A7PHLzKppm1Wc= =sLzU -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] View classes / testing
Hi, I've been looking at making a view class for the RSS syndication in CMFDefault, and I've got all the forms and templates working fine. So now it's on to testing! Has anyone written many tests for a view class? I'm not quite sure how to set the tests up, i.e. put the request and context in the right place. If there is an example floating round, please point me in the right direction! Also, what's the approach to backwards compatibility. For example, in the goldegg_folder_contents branch, the templates all fail gracefully if the view class is not available, by calling python scripts or whatever. And the templates have remained in the skins folder rather than moving somewhere new. Is this the general approach? Thanks, pete ___ 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] View classes / testing
On Mon, 2005-10-17 at 20:37 +0100, pete wrote: Hi, I've been looking at making a view class for the RSS syndication in CMFDefault, and I've got all the forms and templates working fine. So now it's on to testing! Has anyone written many tests for a view class? I'm not quite sure how to set the tests up, i.e. put the request and context in the right place. If there is an example floating round, please point me in the right direction! All the tests I've written in this vein have been for a non-OSS customer project and thus are not shareable, but usually it's enough to make a dummy context (any instance) and pass it in to the view class as the first argument. If your view relies on attributes or methods of the context instance, give those to your dummy class. Pass an empty dictionary in as the request object. If your view uses the RESPONSE object of the REQUEST, create a dummy one of those too and put it in the dictionary. If your view uses adapters, have your test case subclass the PlacelessSetup class (from zope.app.tests.placelesssetup import PlacelessSetup) along with unittest.TestCase; you should be able to use ztapi.provideAdapter then to set up dummy adapters. ___ 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
