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

[Elmar Hinz]

Michael Scharkow schrieb:
> In TYPO3, this is done via a tt_content record on a page that calls an
> extension class (currently of pi_base inheritance). I find this still a
> very good way to connect content with plugins. It also manages caching.
> 

That's right. The field has the misleading name "list" and the call of
the plugin is controlled by TypoScript. Only to come back to the
proposals of Steve Ryan. ;-)

> 
> I agree to this but have a few comments:
> 
> 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.
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.

> 2. Is it more elegant to set $this->defaultAction = 'index' (some people
> would probably even add a setter-method for this), or leave this by

Me, too. See the text.

"index" is used by Zend Framework.

But an index is a list of a directories content. It is a rare case
that a plugin will list a directories content by it's default action.

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.

>> The DispatchController

> class.tx_myextension_pi1_controller is called per default. This

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

> controller can have exposed methods index() and foo(). If you need to
> split the controller up (because it gets too large), you create
> class.tx_myextension_pi_controller_edit in the controllers dir, and the

or tx_myextension_controllers_pi_edit

If article WAS pi1 and book WAS pi2 I prefer names like.

tx_office_controllers_editArticle
tx_office_controllers_editBook

Main plugin controllers are

tx_office_controllers_article
tx_office_controllers_book

(Called instanced by TS steered by tt_content::list as usual.)

It's better to read. Indeed, an additional level for each plugin like
you propose would be more systematically. But inside the small
namespace of an extension a fullblown hierarchy seems oversized. I
prefer speaking classnames without a  hierarchy here. But that could
be the decision of the developers personal style.

> controller class checks for this subcontroller class like it checks for
> methods. If it exists, than the subcontroller is instanciated with a

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 propose to instead use an action registration like with XClasses or
> Hooks in TYPO3 used today. With this, you explicitly link a certain
> controller action to a controller class.
> 
> $actionRegister['tx_myextension_pi1_controller']['edit'] =
> 'tx_anotherext_controller_edit']
> 
> This is still as flexible, keeps the list of exposed actions tight and
> secure, enables dynamic overrides of certain actions without inheritance.
> 

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';

> So what the basic controller dispatching method does for action foo is:
> 
> 1. Check if a class for foo is registered in the action register and if
> yes call it
> 
> 2. Check if a controller class controller_foo exists in the controllers
> dir and if yes call it
> 
> 3. Check if an exposed method foo() exists and call it
> 
> 4. Call notFound action
> 
> Note that the order of 2 and 3 could be reversed for performance reasons
> but would result in less "magic" if you just want to replace the foo()
> method with a larger foo class.
> 
> Greetings,
> Michael

The main difference to my proposal is, that you don't use a hierrarchy
of additional controller parameters to extend the controller.

disadvantage:

* partly longer action names

advantages:

* saving of the controller parameter
* possibility to overwrite actions

Both advantages are convincing.


Regards

Elmar