Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Zope: CMF

actions tool import/export inconsistencies

 

 

Zope cmf RSS feed   Index | Next | Previous | View Threaded


jens at dataflake

Sep 24, 2008, 2:00 PM

Post #1 of 3 (489 views)
Permalink
actions tool import/export inconsistencies

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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".

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.

- 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".

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.

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.

- 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.

- clarify the BBB comment

jens



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjaqmQACgkQRAx5nvEhZLJvYACcDRd6g9jfqs0EdPlkGgUMCh6T
GoQAnjOtGyiWIn+IDsB3sw/62Dzetn0G
=PfzS
-----END PGP SIGNATURE-----
_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


y.2008 at wcm-solutions

Sep 25, 2008, 2:10 AM

Post #2 of 3 (460 views)
Permalink
Re: actions tool import/export inconsistencies [In reply to]

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[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


jens at dataflake

Sep 25, 2008, 2:24 AM

Post #3 of 3 (451 views)
Permalink
Re: actions tool import/export inconsistencies [In reply to]

-----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[at]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 RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.