[TYPO3-ect] Draft: Specification of Dispatch and Action Controller Framework

[Michael Scharkow]

Elmar Hinz wrote:
> Michael Scharkow schrieb:
>> 1. Why append Action to every class method? I prefer less typing...
> 
> Your argument is a storng one. I set three against:
> 
> 1.) Zend Framework does it this way.

I don't count this as an argument ;)

> 2.) The suffix prevents unwanted overriding of methods inherited from
> the parent classes.
> 3.) If I can give names that serve as documentation for other users I
> am disposed to do a little bit more of typing. It pays back in writing
> less comments. It pays back in quicker understanding by users of my
> code including myself within a few monthes.

Fine.

> I would feel bad to twist the meaning of index to the meaning of
> default. To defend Zend. Their controllers and actions are completly
> directory based.

So we simply dispatch to $this->defaultAction which per default is 
'index'? I only want the possibility to define *one* action method in 
the controller class that gets called by sensible default.

> Arrrgh. Let's abandon "pi1". A number doesn't tell anything about the
> task. :-)

My bad, I just realized that the whole pi1 is arbitrarily created by the 
kickstarter.

> I understand that you want to do this automatically without additional
> configuration. My way would require a registration of the valid
> subcontrollers in the parent controller to prevent abuse:
> 
> class tx_office_controllers_article extends tx_lib_controller{
> 
>   private $controllerDirectory = 'controllers'; // inherited default
> 
>   private $subControllers = array(
>    'editArticle',
>    'searchArticle'
>   );
> 
> }

I would rather *only* register actions and leave it to the controller to 
either include a subController or call a simple method. And by 
convention, a subcontroller overrides a method. (And a 
localconf-registered class overrides both)

> The hooks way is a good proposal. I wouldn't register every single
> action with one line, but the subcontrollers class with the actions as
> array. To simplify programming here.
> 
> $TYPO3_CONF_VARS['CONTROLLERS']['tx_office_controllers_article']['tx_moreOffice_controllers_article']
> = array ('print', 'list', 'calculate');
> 
> Hmmm. We list the actions here only to speed up the controller search.
> They could also be detected by introspection of the registered classes
> (action suffix), wich would simplify registration and reduce bugs.
> 
> $TYPO3_CONF_VARS['CONTROLLERS']['tx_office_controllers_article'][]='tx_moreOffice_controllers_article';

The difficulty with all this is "action recursion": If we use the above 
way to register a class, do we just intend 
tx_moreOffice_controllers_article to be a container for static 
(alternative) methods, or do we also use this as a full-fledged action 
subcontroller?

This is an essential question that needs to be answered for regular 
subcontrollers as well:

should tx_office_controllers_article_edit also implement 
t3_action_controller (thus allowing infinite controller recursion) or 
should we just see it as a more simple object that gets called with a 
reference to the controller and does not do its own dispatching/link 
building/etc.

I'd much prefer the most simple way because of the YOU WON'T NEED IT law ;)

Greetings,
Michael