[Zope-CMF] [dev] more add menu changes
Hi! We now have to support two ways to add content: 1.) oldstyle (no add view specified) The addable types are listed in folder_factories. After specifying type and ID the object is added. constructContent redirects to the immediate view. 2.) newstyle (add view is specified) The addable types are listed as actions. These actions should show up in a menu. The add action points to a type specific add form. After completion of the form the object is added. The add form redirects to the immediate view. Some parts are still missing: - add a traverser that allows to use pretty URLs and better portal type handling for add views (not part of this proposal) - don't show newstyle types in folder_factories - show add actions in the CMFDefault skin Proposal 1: allowedContentTypes --- This PortalFolder method is used by folder_factories and by folder_contents to decide if the 'New...' button is added. I propose to add a new skip_add_views argument to allowedContentTypes. If true, newstyle types are skipped. Proposal 2: main_template - CMFDefault menus are implemented in main_template. I propose to add a new section for 'folder/add' actions. If there are no objections I'll make these changes on trunk. 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] CMF Tests: 9 OK
Summary of messages to the cmf-tests list. Period Wed Aug 6 11:00:00 2008 UTC to Thu Aug 7 11:00:00 2008 UTC. There were 9 messages: 9 from CMF Tests. Tests passed OK --- Subject: OK : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Tests Date: Wed Aug 6 21:26:14 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-August/009524.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Tests Date: Wed Aug 6 21:27:44 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-August/009525.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Tests Date: Wed Aug 6 21:29:14 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-August/009526.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Tests Date: Wed Aug 6 21:30:45 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-August/009527.html Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.4 : Linux From: CMF Tests Date: Wed Aug 6 21:32:15 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-August/009528.html Subject: OK : CMF-2.1 Zope-2.11 Python-2.4.4 : Linux From: CMF Tests Date: Wed Aug 6 21:33:45 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-August/009529.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Tests Date: Wed Aug 6 21:35:15 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-August/009530.html Subject: OK : CMF-trunk Zope-2.11 Python-2.4.4 : Linux From: CMF Tests Date: Wed Aug 6 21:36:50 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-August/009531.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Tests Date: Wed Aug 6 21:38:20 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-August/009532.html ___ 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] more add menu changes
On Aug 7, 2008, at 12:26 , yuppie wrote: Proposal 1: allowedContentTypes --- This PortalFolder method is used by folder_factories and by folder_contents to decide if the 'New...' button is added. I propose to add a new skip_add_views argument to allowedContentTypes. If true, newstyle types are skipped. Proposal 2: main_template - CMFDefault menus are implemented in main_template. I propose to add a new section for 'folder/add' actions. If there are no objections I'll make these changes on trunk. +1 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] [dev] more add menu changes
Hi Yuppie, yuppie-4 wrote: Hi! We now have to support two ways to add content: 1.) oldstyle (no add view specified) The addable types are listed in folder_factories. After specifying type and ID the object is added. constructContent redirects to the immediate view. 2.) newstyle (add view is specified) The addable types are listed as actions. These actions should show up in a menu. The add action points to a type specific add form. After completion of the form the object is added. The add form redirects to the immediate view. Some parts are still missing: - add a traverser that allows to use pretty URLs and better portal type handling for add views (not part of this proposal) - don't show newstyle types in folder_factories - show add actions in the CMFDefault skin Proposal 1: allowedContentTypes --- This PortalFolder method is used by folder_factories and by folder_contents to decide if the 'New...' button is added. I propose to add a new skip_add_views argument to allowedContentTypes. If true, newstyle types are skipped. Please let this default to False. I wonder if it's better to have a separate method that does the skipping. allowedContentTypes may be used by other things already. Plone uses it in a few places, for example. :) I don't suppose there's a way to make all FTI's expose actions, and just construct an appropriate fallback URL (e.g. createObject or whatever) if no add view has been specified? That'd mean folder_factories could just loop through the actions. Proposal 2: main_template - CMFDefault menus are implemented in main_template. I propose to add a new section for 'folder/add' actions. If there are no objections I'll make these changes on trunk. +0 - Plone would need this in its content menu implementation, but that's custom anyway. Martin -- View this message in context: http://www.nabble.com/-dev--more-add-menu-changes-tp18867664p18873994.html Sent from the Zope - CMF list2 mailing list archive at Nabble.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
[Zope-CMF] Re: [dev] more add menu changes
Hi Martin! Martin Aspeli wrote: yuppie-4 wrote: Some parts are still missing: - add a traverser that allows to use pretty URLs and better portal type handling for add views (not part of this proposal) - don't show newstyle types in folder_factories - show add actions in the CMFDefault skin Proposal 1: allowedContentTypes --- This PortalFolder method is used by folder_factories and by folder_contents to decide if the 'New...' button is added. I propose to add a new skip_add_views argument to allowedContentTypes. If true, newstyle types are skipped. Please let this default to False. Sure. I wonder if it's better to have a separate method that does the skipping. allowedContentTypes may be used by other things already. Plone uses it in a few places, for example. :) I have no strong opinion about this. What would be a good name for a separate method? I don't suppose there's a way to make all FTI's expose actions, and just construct an appropriate fallback URL (e.g. createObject or whatever) if no add view has been specified? That'd mean folder_factories could just loop through the actions. Not sure I understand what you propose. folder_factories is a form that allows to specify type and ID. I don't think we should ask for the ID *before* showing the add view. And if we have no add view, we need folder_factories' ID input field. But this might work: If we also implement the traverser, the traverser could return a default add view that just asks for the ID. In that case we could use actions for newstyle and oldstyle types. That solution would change the add procedure for oldstyle types, but maybe that's better than listing newstyle and oldstyle types in two different places. Any opinions? 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] [dev] more add menu changes
Hi Yuppie, yuppie-4 wrote: I don't suppose there's a way to make all FTI's expose actions, and just construct an appropriate fallback URL (e.g. createObject or whatever) if no add view has been specified? That'd mean folder_factories could just loop through the actions. Not sure I understand what you propose. folder_factories is a form that allows to specify type and ID. I don't think we should ask for the ID *before* showing the add view. And if we have no add view, we need folder_factories' ID input field. Ah In Plone, folder_factories is a list of addable types. You click Add next to each one and it's created with a temporary ID. Then you save it, and it's renamed to a better ID, usually. But this might work: If we also implement the traverser, the traverser could return a default add view that just asks for the ID. In that case we could use actions for newstyle and oldstyle types. That may be nice. That solution would change the add procedure for oldstyle types, but maybe that's better than listing newstyle and oldstyle types in two different places. I think so. Why should the user have to know whether something is old or new? Martin -- View this message in context: http://www.nabble.com/-dev--more-add-menu-changes-tp18867664p18875455.html Sent from the Zope - CMF list2 mailing list archive at Nabble.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
[Zope-CMF] genericsetup:upgradeDepends
hi all, i've got a GenericSetup branch called 'ra-depends-tag' with a working implementation of a genericsetup:upgradeDepends ZCML tag. this tag can be used anywhere that you could use a genericsetup:upgradeStep tag (i.e. either standalone, or nested within a genericsetup:upgradeSteps). in fact, upgradeDepends is simply a special case of upgradeStep that allows you to specify a set of profile import steps to be re-applied to the site, rather than calling a generic python handler. here's an example of how it looks: genericsetup:upgradeDepends profile=Products.Something:default source=1.0 destination=1.1 sortkey=10 title=Re-run 'foo' import step import_steps=foo purge=True run_deps=False / or alternatively: genericsetup:upgradeSteps profile=Products.Something:default source=1.0 destination=1.1 sortkey=10 / genericsetup:upgradeDepends title=Re-run 'foo' and 'bar' import steps import_steps=foo bar purge=True run_deps=False / genericsetup:upgradeStep title=Do something else handler=Products.Something.upgrades.do_something_else / /genericsetup:upgradeSteps some notes: - there is no problem nesting both upgradeStep and upgradeDepends tags within the same upgradeSteps tag - the purge and run_deps attributes are optional and both default to False - the import_steps attribute is of token type, so you can list multiple steps separated by whitespace and they will all be run - the import_steps attribute is optional, if it is omitted then the entire profile will be reapplied - it's not demonstrated in the examples above, but the 'checker' attribute (which points to a callable that can be run to determine whether or not the upgrade action should be performed) is supported, it functions exactly as it does within an upgradeStep tag the justification for the existence of this tag should be pretty obvious. one of the most frequent actions that need to be performed when upgrading to a new version of a product is the reapplication of whichever import steps have been modified since the last profile revision. you could use the upgradeStep tag to point to a handler that performs this operation, but that requires boilerplate python code, and there's no easy way to express whether or not you want the dependencies to be run, or purge_old to be set, or even which steps should be run. this tag resolves those issues. please feel free to peek at the branch and provide feedback on the work. if there are no objections, i'd like to merge this to the GS trunk as soon as it is deemed appropriate by the release manager. thanks, -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
Re: [Zope-CMF] [dev] more add menu changes
Am 07.08.2008 um 19:21 schrieb Martin Aspeli: Ah In Plone, folder_factories is a list of addable types. You click Add next to each one and it's created with a temporary ID. Then you save it, and it's renamed to a better ID, usually. Add forms are much nicer than that. Objects are only created if the add form is correctly completed. I haven't looked at yuppie's latest implementation but the use of INameChooser for default id's is very usable - in many context management situations auto-generated id's are preferable although Plone's are a bit verbose. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] more add menu changes
Charlie Clark wrote: Am 07.08.2008 um 19:21 schrieb Martin Aspeli: Ah In Plone, folder_factories is a list of addable types. You click Add next to each one and it's created with a temporary ID. Then you save it, and it's renamed to a better ID, usually. Add forms are much nicer than that. Of course. We just haven't had many of them until recently. Objects are only created if the add form is correctly completed. Yes, that's why they call them add forms I haven't looked at yuppie's latest implementation but the use of INameChooser for default id's is very usable - in many context management situations auto-generated id's are preferable although Plone's are a bit verbose. No kidding. :) 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
