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

[Elmar Hinz]

Michael Scharkow schrieb:
> 
> 
> 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 ;)
> 

That is a difficult question. I have rather a feeling about this then a
clear view. I think that has to do with the question if we use a single
action parameter or additional parameters for the controller.

I think it is like this:

a) If we work with one controller parameter, we can register controllers by
localconf that take precedence for the given controller parameter. The
original controller passes the request to the precedent controller wich
runs the request seeing it has the precedence of all controllers.

This is rather controller replacement than real recursion. The original
controller replaces itself with a second one according to the precedence
rules. There are no further levels of recursion.

This doesn't make more sense than precedence for actions. For real
controller recursion we would need an unlimited number of parameters. One
parameter as switch for each level of recursion.


b) If we work with a single action parameter the original controller
replaces it's own action with a second one according to the precedence rules.

b 1.) We could do this with a static method and pass on a reference to the
original controller.

b. 2.) We could do this by instanciating the owner of the precedent action
and calling it's main method from the orignal controller. This main method
runs the own action seeing it has precedence of all.

The b 1.) would be faster but looks more complicated to implement. Either
programmers have to deal with two different types of actions, static and
non-static, or they would deal with static actions everywhere, even to
calls in the own class.

I prefer a unique programming style to optimized speed here. The original
controller can be reused as subcontroller without changing the action from
non-static to static.

/el