[Zope-CMF] Re: [dev] type infos and 'add' actions - a proposal
Hi! Martin Aspeli wrote: - 'url': requires a new type info property, I propose to use 'url_expr' to keep it in sync with normal Action objects I wonder whether addview_url or something similar would be more appropriate, since the url of a type is somewhat ambiguous. Ok. I changed that to 'add_view_expr'. The '_expr' suffix is used to implement special behavior for expressions. So instead of adding separate 'add' actions we can extend the type info classes, making them implement IAction as well. How about making them adaptable to IAction instead of directly implementing it? That sounds cleaner than trying to bend some of the old properties. Don't think so. IAction just adds one method: getInfoData(). The names I mentioned are keys in the data structure returned by that method, not bent properties. My changes are now checked in on the trunk. So far I didn't add a 'portal_type' variable to the expression context because I don't know an easy way to do that. The action machinery expects that all callable attributes of all actions take the same expression context as argument. 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] type infos and 'add' actions - a proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: Hi! This is a proposal for implementing one part of what we discussed in this thread: http://mail.zope.org/pipermail/zope-cmf/2008-July/027500.html Using add views instead of folder_factories for creating content makes it necessary to provide some kind of menu items for them. In CMF menu items are usually represented by 'actions'. Type infos already define most data required for actions: - 'id': can be reused - 'title': can be reused; if we want action titles like 'Add File ...' instead of 'File' we can change that in the template - 'description': has already the same purpose as in actions - 'icon': 'content_icon' is a path relative to the site root, but we can use the same icon and compute the required absolute path - 'available': can be computed using allowType of the container - 'allowed': can be computed using isConstructionAllowed Missing are these properties: - 'category': can be hardcoded, e.g. as 'folder/add' - 'url': requires a new type info property, I propose to use 'url_expr' to keep it in sync with normal Action objects - 'visible': can be hardcoded as True So instead of adding separate 'add' actions we can extend the type info classes, making them implement IAction as well. listActions of the types tool would include type infos if they provide IAction *and* have an url specified. As always, feedback is welcome. +1. Seems a simple, straighforward extension, with zero BBB problems. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIhJgu+gerLs4ltQ4RAmZpAKCzp8t3m5Xf/NAq+ShK8tQwULR5LACgjhU+ oBdD84fizqzDGOmUFR5d9wI= =rcl2 -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: [dev] type infos and 'add' actions - a proposal
Hi Yuppie, This is a proposal for implementing one part of what we discussed in this thread: http://mail.zope.org/pipermail/zope-cmf/2008-July/027500.html Using add views instead of folder_factories for creating content makes it necessary to provide some kind of menu items for them. In CMF menu items are usually represented by 'actions'. Type infos already define most data required for actions: - 'id': can be reused - 'title': can be reused; if we want action titles like 'Add File ...' instead of 'File' we can change that in the template - 'description': has already the same purpose as in actions - 'icon': 'content_icon' is a path relative to the site root, but we can use the same icon and compute the required absolute path - 'available': can be computed using allowType of the container - 'allowed': can be computed using isConstructionAllowed Missing are these properties: - 'category': can be hardcoded, e.g. as 'folder/add' - 'url': requires a new type info property, I propose to use 'url_expr' to keep it in sync with normal Action objects I wonder whether addview_url or something similar would be more appropriate, since the url of a type is somewhat ambiguous. - 'visible': can be hardcoded as True So instead of adding separate 'add' actions we can extend the type info classes, making them implement IAction as well. How about making them adaptable to IAction instead of directly implementing it? That sounds cleaner than trying to bend some of the old properties. listActions of the types tool would include type infos if they provide IAction *and* have an url specified. Apart from the two comments above, a great +1. :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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
