[Zope-CMF] Re: [dev] enhancing Actions: a rough proposal

[Dieter Maurer]

Hi Yuppie,

yuppie wrote at 2004-11-26 09:27 +0100:
> ...
>Yes. Seems to be time to elaborate on some details. I hope this will 
>allay your concerns a bit.

It does a bit...

>1.) timetable
>
>For now I just want to replace normal Actions. Type Actions and workflow 
>Actions are out of the scope of the more detailed proposal I'm going to 
>write based on this discussion.

Fine, that reduces the amount of work to adapt existing applications
to your new  proposal considerably.

>In the long run I'd like to use the new machinery for all kinds of 
>Actions. But that could be done in different ways. Moving all Actions to 
>the ActionsTool is just one option. Reusing the new machinery in the 
>TypesTool and the WorkflowTool is an other. I don't think we should 
>decide that now.

You often have the distinction between new and existing applications.
Therefore, you often have several ways to do something; maybe
some deprecated.

> ...
>2.) migration
>
>The proposed folderish Action provider will be able to live side by side 
>with all existing Action providers. Technically it is just another 
>Action provider.

That sounds good (in my ears).


>Migrating Actions of existing instances can be done using CMFSetup: 
>exporting - importing - done.

Maybe, your proposal comes to early, at least for me.
I did not yet look at CMFSetup (or CMF 1.5 in general).
What I know about it is what I read in this mailing list.

If it really is that easy, fine.

> ...
>The only problem I can see is code that queries / manipulates Action 
>providers directly. I guess 90% of that code is setup code. My proposal 
>is based on the assumption that people will have to rewrite the setup of 
>their products anyway:
>CMFSetup introduces a completely different setup 
>machinery, and I doubt it would be a good idea to maintain the old *and* 
>the new machinery in the long run.

Fortunately (for me), the number of my tools with actions is
far smaller than the number of types.

Nevertheless, a script taking care of the current standard
case (a class with a sequences of action definitions) by
generating the corresponding CMFSetup profile would
greatly increase acceptability of your proposal.

It would probably be very similar to a CMFSetup export.


>> Your proposal may be something for CMF-NG (or CMF2 or CMF for Zope 3)
>> but it should not remove essential infrastructure in CMF
>> (like "ActionProviderBase") that are essential for todays tools
>> build on top of CMF.
>
>Removing ActionProviderBase is not an essential part of my proposal. But 
>at least I'd like to recommend using the new centralized Action provider 
>and change the products in the CMF repository accordingly.

There is a disadvantage of inheritance.

    When you inherit from a class, you assume some implementation
    details (e.g. that is behaves like an "ActionProvider").

When you can make the changes to the standard tools
in a way that inheriting classes
can easily add "ActionProviderBase" to work around
the loss of this base class in the inherited class,
then this loss should not be a problem.

-- 
Dieter