[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 jens - CachingPolicyManager: Make Max-Age parameter dynamic, [Accepted] http://www.zope.org/Collectors/CMF/405 mhammond - Windows DevelopmentMode penalty in CMFCore.DirectoryView, [Accepted] http://www.zope.org/Collectors/CMF/366 Pending / Deferred Issues - 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 - FSPropertiesObject.py cannot handle multiline input for lines, text attributes, [Deferred] http://www.zope.org/Collectors/CMF/271 - 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 - workflow notify success should be after reindex, [Pending] http://www.zope.org/Collectors/CMF/389 - Content in Setup gets Cleared (Content Import Handler), [Pending] http://www.zope.org/Collectors/CMF/404 - index_html manage_workspace and view error, [Pending] http://www.zope.org/Collectors/CMF/406 Pending / Deferred Features - Favorite.py: queries and anchors in remote_url, [Pending] http://www.zope.org/Collectors/CMF/26 - DefaultDublinCore should have Creator property, [Pending] http://www.zope.org/Collectors/CMF/61 - 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 - 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 - CMFTopic Does Not Cache, [Deferred] 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, [Deferred] 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 - First Day of Week, [Pending] http://www.zope.org/Collectors/CMF/400 ___ 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: [dev] CMF 2.0 browser views and Five traversal
Hi Philipp! Philipp von Weitershausen wrote: yuppie wrote: Some details: - I'd like to keep the changes the extension profile makes as small as possible. So I don't want to change the visible action targets. All we need are some Method Aliases that point to the views. - We need new names for the views. I'd like to use @@view.html, @@edit.html and @@properties.html for the views that already exist. +1 for saner view names. document_view or document_edit_form is just a lame legacy from the one flat view namespace that portal_skins provide. Well. Actually I propose to hide those saner view names for now. Changing the visible names using Method Aliases is possible since CMF 1.5. That has nothing to do with switching to browser views and should be part of a different proposal. All I want for now are browser view names that have a good chance to become the official visible names some time in the future. By the way, unless you make @@view.html the default view name for documents or whatever (using five:defaultViewable and browser:defaultView), why not call it @@index.html?? The 'view' view is not always the default view. Image and File have download as default. I guess index.html should always be an alias for the default view. I proposed to use Method Aliases, so the default view would still be set in the types tool (or profile XML), not in ZCML. 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] Classes whose instances appear in ZODB
If I want a class to appear in the ZODB, is that just a matter of subclassing SimpleItem? What additional attributes do I need to set -- for instance, do I need to define 'meta_type' for the class? Can a class be persistent but not have its instances appear in the ZODB -- for instance, does subclassing Persistent do this? (I want to define two classes, one of which stores instances of the other as an attribute.) Thanks; peace, George ___ 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] Classes whose instances appear in ZODB
On 3/8/06, George Lee [EMAIL PROTECTED] wrote: If I want a class to appear in the ZODB, is that just a matter of subclassing SimpleItem? Define Appear? :-) Do you mean that you want it to pop up in the Add menu of the ZMI? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Classes whose instances appear in ZODB
Instances show up in the list of objects in a container (which may be equivalent to the class showing up in the Add menu?) Peace, George On 3/8/06, Lennart Regebro [EMAIL PROTECTED] wrote: On 3/8/06, George Lee [EMAIL PROTECTED] wrote: If I want a class to appear in the ZODB, is that just a matter of subclassing SimpleItem? Define Appear? :-) Do you mean that you want it to pop up in the Add menu of the ZMI? -- 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: Classes whose instances appear in ZODB
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: On 3/8/06, George Lee [EMAIL PROTECTED] wrote: Instances show up in the list of objects in a container (which may be equivalent to the class showing up in the Add menu?) Nope, that's not equivalent. I'm not exactly sure what the requirements are. A getId method, a title attribute and a meta_type probably. Subclassing from SimpleItem is definitely a good idea. Oh, and you need to add the object to the container, of course. ;) Right, vie '_setObject', rather than just assigning an attribute. 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 iD8DBQFEDxlI+gerLs4ltQ4RAkwAAJ9tNHfbXXuWqsXgJEgpVgY7lhDDVgCgh/i+ otk6Lr0MG+wm0yTJgrMg+48= =lKQ3 -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] Classes whose instances appear in ZODB
George Lee wrote at 2006-3-8 10:17 -0500: If I want a class to appear in the ZODB, is that just a matter of subclassing SimpleItem? Usually, classes do not appear in the ZODB -- just their instances. SimpleItem is the base class of all (what I call) Zope site building objects -- the term Zope site building object may correspond to your may appear in the ZODB. Perhaps, you will find reading http://www.dieter.handshake.de/pyprojects/zope/book/chap3.html useful. What additional attributes do I need to set -- for instance, do I need to define 'meta_type' for the class? meta_type is usually used in the so called add list. It should be a unique description of your object class such that you are able to select the object from the add list when you need it. You use ObjectManager._setObject(id, obj) to put obj into the ObjectManager. Note, that you must also give obj the identical id. Otherwise, URL generation will break. Can a class be persistent but not have its instances appear in the ZODB Yes. You can instanciate a class deriving from Persistent without the instance to actually get persisted. It only gets persisted when you assign it to an attribute of a persisted object. You may want to read the ZODB guide. -- 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: [dev] CMF 2.0 browser views and Five traversal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: Hi Philipp! Philipp von Weitershausen wrote: yuppie wrote: Some details: - I'd like to keep the changes the extension profile makes as small as possible. So I don't want to change the visible action targets. All we need are some Method Aliases that point to the views. - We need new names for the views. I'd like to use @@view.html, @@edit.html and @@properties.html for the views that already exist. +1 for saner view names. document_view or document_edit_form is just a lame legacy from the one flat view namespace that portal_skins provide. Well. Actually I propose to hide those saner view names for now. Changing the visible names using Method Aliases is possible since CMF 1.5. That has nothing to do with switching to browser views and should be part of a different proposal. All I want for now are browser view names that have a good chance to become the official visible names some time in the future. By the way, unless you make @@view.html the default view name for documents or whatever (using five:defaultViewable and browser:defaultView), why not call it @@index.html?? The 'view' view is not always the default view. Image and File have download as default. I guess index.html should always be an alias for the default view. I proposed to use Method Aliases, so the default view would still be set in the types tool (or profile XML), not in ZCML. +1 to your proposal. +1 to Phillip's suggestion that 'index.html' should be the name for the default view. 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 iD8DBQFEDzPv+gerLs4ltQ4RAt2EAJ9EX8jsDlQgvY2OLmBeNnAtXtiQlgCgyGIP PlwButphwQygjD46HtiCG3E= =Ctou -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] [DCWorkflow]Problem with initial state
Dieter Maurer a écrit : Encolpe Degoute wrote at 2006-3-7 20:33 +0100: I found something funny yesterday that makes me spend some hours: If you delete the state marked as initial state the variable initial_sate always contains its id. Any workflow needs an initial state. Any workflow needs initial transitions. Thus, maybe, you should mark a new state as initial once you deleted the old one? That time I forgot. In many cases, deleting state is not a good idea (at least not when there are objects in the deleted state). If you rename a state you will have the same problem. The method _executeTransition should test this case, at least to said the value stored in self.initial_state is invalid. Regards, -- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales ___ 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] [dev] CMF 2.0 browser views and Five traversal
- We need new names for the views. I'd like to use @@view.html, @@edit.html and @@properties.html for the views that already exist. I think 'metadata_edit_form' and 'folder_edit_form' are both in fact properties views and 'folder_contents' is just a special edit view. I'd like to use the same names for container views as for content views. Love the proposal, hate the @@ naming. Do we need that? Or is the goal to align better with the Zope 3 way of naming views? I'd like a simple index.html or edit.html etc much better. 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: [dev] CMF 2.0 browser views and Five traversal
Hi Jens! Jens Vagelpohl wrote: - We need new names for the views. I'd like to use @@view.html, @@edit.html and @@properties.html for the views that already exist. I think 'metadata_edit_form' and 'folder_edit_form' are both in fact properties views and 'folder_contents' is just a special edit view. I'd like to use the same names for container views as for content views. Love the proposal, hate the @@ naming. Do we need that? Or is the goal to align better with the Zope 3 way of naming views? I'd like a simple index.html or edit.html etc much better. For now I just propose to use the '@@' names internally. The users will still see the old names, the Method Aliases machinery maps them to the new names. For example this profile XML is for the Document aliases: ?xml version=1.0? object name=Document alias from=(Default) to=@@view.html/ alias from=view to=@@view.html/ alias from=document_view to=@@view.html/ alias from=document_edit_form to=@@edit.html/ alias from=metadata_edit_form to=@@properties.html/ /object You could access the edit view with 'edit.html' instead of '@@edit.html', but that has a major drawback: View names are not protected in any way if used without '@@'. You can easily screw up your site by adding content with the ID 'edit.html'. Names used by Method Aliases are protected *and* Method Aliases are looked up first. So it would be safe to define an 'edit.html' alias for 'document_edit_form' or '@@edit.html'. I actually do that on my sites. But changing the visible names is not part of my proposal. 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: [dev] CMF 2.0 browser views and Five traversal
On 8 Mar 2006, at 16:52, yuppie wrote: You could access the edit view with 'edit.html' instead of '@@edit.html', but that has a major drawback: View names are not protected in any way if used without '@@'. You can easily screw up your site by adding content with the ID 'edit.html'. Names used by Method Aliases are protected *and* Method Aliases are looked up first. So it would be safe to define an 'edit.html' alias for 'document_edit_form' or '@@edit.html'. I actually do that on my sites. OK, thanks for explaining. Sounds good then. But changing the visible names is not part of my proposal. Well, I personally would love to change the visible names. The old names are worse than the @@-prefixed new names ;) 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] GenericSetup on zope.org
Just FYI, there's now a place for GenericSetup on zope.org: http://www.zope.org/Products/GenericSetup/swpackage_view 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: [dev] CMF 2.0 browser views and Five traversal
On 8 Mar 2006, at 17:36, yuppie wrote: Hi Jens! Jens Vagelpohl wrote: But changing the visible names is not part of my proposal. Well, I personally would love to change the visible names. The old names are worse than the @@-prefixed new names ;) I agree. But the old names are the status quo. Replacing them by Method Aliases is possible since CMF 1.5 and has nothing to do with the viewification. If we change the visible names this should be done in a consistent way, not just for the few methods that are converted to views. Maybe you should discuss with the release manager if the beta phase is the right time for a change like that ;) Oh god no, I was just voicing my general dislike of the old names. Changes like that in the beta phase? Over my dead body ;) 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: [dev] CMF 2.0 browser views and Five traversal
On Wed, Mar 08, 2006 at 11:14:59PM +0100, yuppie wrote: Paul Winkler wrote: On Wed, Mar 08, 2006 at 10:52:09PM +0100, yuppie wrote: You could access the edit view with 'edit.html' instead of '@@edit.html', but that has a major drawback: View names are not protected in any way if used without '@@'. You can easily screw up your site by adding content with the ID 'edit.html'. Could you elaborate? Does not protected mean that security is bypassed??? or what? Sorry. I thought the context makes clear what I mean. Protected against overriding. Any user who is allowed to add content can override them with content objects. Ah, obvious in retrospect. I totally mis-parsed your message. Thanks. -- Paul Winkler http://www.slinkp.com ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
