Re: [Zope-CMF] [dev] 'add' actions and views - a proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 24, 2008, at 13:27 , yuppie wrote: > Ok. I checked in all my local changes. AFAICS everything works fine, > but > tests are still missing. > > Please note that so far only File has a full add view. All other > content > types use the fallback add view. > > I still use the pattern that adapts ITypeInformation as well. Our add > views are anyway Zope 2 specific, so I don't think requiring explicit > Zope 2 security declarations is unacceptable. All other solutions have > also their drawbacks. Housekeeping question: Do you think https://bugs.launchpad.net/zope-cmf/+bug/161664 is done with what's on the trunk now? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjb+AEACgkQRAx5nvEhZLKukQCfYVli5u+UgsDmyvU0dwmOQiRq HE0AoLPWVJZH1bXgmnomeUbCPk3N6Gqk =az3z -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] CMF Tests: 9 OK
Summary of messages to the cmf-tests list. Period Wed Sep 24 11:00:00 2008 UTC to Thu Sep 25 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 Sep 24 21:28:37 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-September/009965.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Tests Date: Wed Sep 24 21:30:07 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-September/009966.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Tests Date: Wed Sep 24 21:31:38 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-September/009967.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Tests Date: Wed Sep 24 21:33:08 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-September/009968.html Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.4 : Linux From: CMF Tests Date: Wed Sep 24 21:34:38 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-September/009969.html Subject: OK : CMF-2.1 Zope-2.11 Python-2.4.4 : Linux From: CMF Tests Date: Wed Sep 24 21:36:08 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-September/009970.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Tests Date: Wed Sep 24 21:37:38 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-September/009971.html Subject: OK : CMF-trunk Zope-2.11 Python-2.4.4 : Linux From: CMF Tests Date: Wed Sep 24 21:39:08 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-September/009972.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Tests Date: Wed Sep 24 21:40:38 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-September/009973.html ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] actions tool import/export inconsistencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 25, 2008, at 11:10 , yuppie wrote: >> While you still can use the Action tabs, it is no longer recommended > since CMF 2.0 and the export/import machinery moves Actions from those > tabs to the recommended place. Have we made any explicit announcement to that effect or warned people? I must have missed it if there was one. There's no DeprecationWarnings anywhere (yet). I've always been aware of the general direction to move away from old-style actions, but haven't seen any concrete communication to the community, especially the Plone guys. >> The main discrepancy is in the handling of action providers that are >> not 'portal_actions', 'portal_types' or 'portal_workflow'. Their data >> is exported, but they are not re-added to the actions tool during >> import. Also, the BBB note about "CMF 1.6 profiles" is confusing. >> That >> mechanism is still in use today, it hasn't been discarded after 1.6. > > It might not have been the best idea to make implicit migrations on > import. Anyway. We now are talking about CMF 2.2 and most people > should > meanwhile have migrated their 'normal' Actions to portal_actions. So > I'm > fine with removing the migration code. I'll add a big warning on the Actions tab code so people see it when they go to the tab in the ZMI. >> - the old-style action information data should not be handled >> centrally by the actions tool export/import, unless those actions are >> on the actions tool itself. All other providers should export/import >> their old-style actions themselves. > > +1 for making the handler of each tool responsible for its Actions > > But I propose to add deprecation warnings for 'normal' Actions (not > type > Actions) stored in Actions tabs. People did have enough time to move > those Actions to the Actions tool. And if 'normal' oldstyle Actions > are > deprecated, we don't have to provide export/import support for them. I'll try to find some good places for DeprecationWarnings in the ActionProviderBase class. Unfortunately, since there hasn't been any deprecation warning, we'll have to wait for a while to start removing code :-( jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjbWM0ACgkQRAx5nvEhZLI7fACfdaa2GKUkysB+BXucL/u9hy+r ryYAn33bx2Amg2pjQF20ziNptlMWSzDR =WnhW -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] actions tool import/export inconsistencies
Hi Jens! Jens Vagelpohl wrote: > An open Launchpad issue had me take a look at the import/export > machinery for the actions tool and action providers > (https://bugs.launchpad.net/zope-cmf/+bug/177675 > ). I see some inconsistencies and would like to get rid of them. > Here's the behavior I read out of the code: > > Export: > > - _all_ action providers known to the actions tool are written to > actions.xml as "action-provider" nodes > > - if an action provider contains "old-style" actions, those are > exported as children of the corresponding "action-provider" node. > Curiously, that action information export is marked "BBB: for CMF 1.6 > profiles". That's a copy 'n' paste error. For exports that should be "CMF 1.6 settings", not "CMF 1.6 profiles". While you still can use the Action tabs, it is no longer recommended since CMF 2.0 and the export/import machinery moves Actions from those tabs to the recommended place. > Import: > > - the "action-provider" nodes are added to the actions tool if they > do not exist _and_ if their IDs happen to be 'portal_actions', > 'portal_types' or 'portal_workflow'. None of the other "action- > provider" nodes are added. This is migration code. Since CMF 2.0 all 'normal' Actions should be stored in portal_actions. Only 'special' Actions (in CMF type Actions and workflow Actions have special implementations) should be stored in other tools. But the hardcoded _SPECIAL_PROVIDERS list is problematic as described in the bug report. > - if the "action-provider" node has children of type "action", their > data is imported and recreated on the respective provider as "old- > style" actions. This is also marked as "BBB: for CMF 1.6 profiles". No. This is also migration code. They are recreated as newstyle Actions in portal_actions. > The main discrepancy is in the handling of action providers that are > not 'portal_actions', 'portal_types' or 'portal_workflow'. Their data > is exported, but they are not re-added to the actions tool during > import. Also, the BBB note about "CMF 1.6 profiles" is confusing. That > mechanism is still in use today, it hasn't been discarded after 1.6. It might not have been the best idea to make implicit migrations on import. Anyway. We now are talking about CMF 2.2 and most people should meanwhile have migrated their 'normal' Actions to portal_actions. So I'm fine with removing the migration code. > I would like to change the actions tool import/export code so it does > the following: > > - all action-provider nodes from the export should be added to the > actions tool during import if they are not already registered there. +1 > - the old-style action information data should not be handled > centrally by the actions tool export/import, unless those actions are > on the actions tool itself. All other providers should export/import > their old-style actions themselves. +1 for making the handler of each tool responsible for its Actions But I propose to add deprecation warnings for 'normal' Actions (not type Actions) stored in Actions tabs. People did have enough time to move those Actions to the Actions tool. And if 'normal' oldstyle Actions are deprecated, we don't have to provide export/import support for them. > - clarify the BBB comment +1 Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests