[Zope-CMF] Re: [dev] CMF 1.5 roadmap?

[Dieter Maurer]

yuppie wrote at 2004-2-27 16:13 +0100:
> ...
>Things I don't like about CMFFormController:
>--------------------------------------------
>
>- It 'bypasses' Zope and CMF infrastructure instead of improving the
>   existing features:
>   o The State object duplicates the concept of the REQUEST object.

I do not think that REQUEST should get this special purpose
task as well.

"REQUEST" is already a very complex object. Adding additional
functionality that is relevant only for specific tasks may not
be a good idea.

> ...
>   o FormController actions duplicate the concept of invisible CMF
>     Actions.

There is no real concept for "invisible" CMF actions.

At least from my point of view, CMF actions have been designed
as UI actions. The "visible" attribute seems to be only a minor
feature to make actions temporarily not shown in the user
interface.

Sure, you can still use it via a program. But, there is nothing
that specifies how such actions are activated "automatically" under
special conditions. Such rules are provided by "CMFFormController".


It might be possible to use the "condition" and "action" attributes
of CMF actions to specify the "CMFFormController" actions.
However, the corresponding expressions would be weird and maybe
inefficient.

The "redirect_to:string:abc" of CMFFormController, would e.g. look like:

    python: request.RESPONSE.redirect(object_url+'abc?' + modules['ZTUtils'].make_query(request.STATE.getKwargs())

I assume here, that "CMFFormController"s "state" object is available via
"request.STATE".

The "redirect_to_action" would (with current CMF 1.4) be a nightmare
as a standard TALES expression. It will hopefully improve with
your "action" addressing enhancements for CMF 1.5.


I recognize that one could move these monsters into specialized
scripts, e.g. a "FC_redirect_to" script. Normal Python Scripts
would almost surely not be sufficient, as the general
handling needs to parse the query string which is difficult
even in unrestricted Python (and wrong in the "RC2" release
of "CMFFormController"). This would mean, you have probably
a "portal_form_controller" that interprets such requests.

I am not against specialized syntax, when this syntax allows to
express clearer and in a more standardized way what is intended.
I think, "CMFFormController"s syntax is not bad in this respect.


As CMFFormController actions are *NOT* an UI concept,
order is not relevant (order is highly relevant for UI actions).
This allows CMFFormController actions to be customized in a much
more modular way than this is the case for CMF actions.

   A product or content type can come with a full set of validators
   and actions. A site adminstrator can adapt actions and
   validators on an individual bases.

   Due to the order requirements for UI actions,
   a content type can specify the complete set of CMF actions.
   Customization however, is possible only on the complete set
   and not at the level of individual actions.

Thus, the "automatic" actions of CMFFormController
are in an essential point different from the "UI" actions of CMF.

>- In this context I can't see a systematic difference between
>   validators and 'actions' that modify the data. Both can be seen as
>   state transformations. Methods like 'document_edit' should be
>   configured and called the same way as validators are called - I
>   can't see why we need the traverse_to actions.

Validators are a simple sequence.

At some point, you need a chance to branch depending on the
accumulated state.
The "traverse_to" enters the play at this branch point.

Of cause, this is a restriction in the CMFFormController model.
Branch points are only at the end of a chain.
When branching could happen anywhere, there would be no
need to distinquish between a validator and a template or script.

However, a more complex model is more complex to customize.
An intuitive design for the customization of an arbitrary branching
schema with the restricted means of HTML UI (or config
file) features is a challenge...

-- 
Dieter