[TYPO3-ect] Controller for Typo3

[Michael Scharkow]

Joerg Schoppet wrote:
> Hi list,
> 
> I just want to discuss over some controller-issues for fe-extensions.
> 
> 
> Elmar pointed me to
> http://www.underused.org/code/a-simple-controller-class-for-typo3/ ,
> but there I see some disadvantages in some cases. The
> "simple-controller" needs to have special links (because it uses a
> get/post-var 'cmd' for 'switching'). So you can not use the
> typo3-sitestructure for display of a menu and for access-management.

The simple controller does exactly what each and every TYPO3 plugin
does: rely on piVars for different view modes. And like every better
plugin, you *can* use different pages for different views, as this is
configurable in TS/Flexform. Look at tt_news: No matter what "CODE" or
view mode you use, the same plugin is called every time, and then
processes only the relevant configuration.

So you can use a multi-page layout if you want to, just as always. I 
tend to dislike these setups because of the redundancy in placing the 
plugin (and maybe a lot of flexform config) again and again on pages. 
But that's just a personal preference.

As to URLs: With RealURL we have a very powerful tool to generate them. 
In fact, I'd make tx_bla_pi1['cmd'] a fixed postVar, so that we 
basically have the same URL as ROR has with routes:

http://example.com/references/add
http://example.com/references/view/XXX
http://example.com/references/edit/XXX

> I would prefer an additional instance:
> 
> Example: I created a request system. This system should consists of
> some functionality (!!!) - creating of requests (all users) -
> displaying of self-created requests (all users) - working with
> requests (special users) - reporting of requests (special users)
> 
> Each of this functions should resist on his own page in typo3
> (benefit: Simple linking, access-restrictions by typo3). So I created
> four pages and on each page I included my plugin. The plugin has a
> flexform with a select-box in it. each option of the select-box
> correspond with one of the four functions. In my extension I've build
> up a 3-tier-layer: - process (one class for each function containing
> the business logic) - domain (one class for each persistent object) -
> application (one class for each function)

Sorry, but I find this approach very backwards: You have the same plugin 
in multiple places, you have a lot of redundant configuration, you 
violate the DRY principle a lot.

> In my pi1-class I read out the option of the flexform. With a simple
> switch-statement I get the corresponding process-class and call a
> general function in this class. The process-class knows, which
> domain-classes and which application-class it needs for further
> processing and returns the output of the application-class back to
> the pi1-class, which simple return it.

This is the very same logic as in the simple controller, only my 
approach does not need explicit configuration in FlexForms or elsewhere. 
In fact, I don't see how this differs in terms of functionality at all.

Leaving the model part aside, my approach prefers convention over 
configuration and yours does not.
1. You rely on some config var that tells your controller what to do 
*and* on the path to the plugin, I rely *only* on the path to the plugin 
(with RealURL).
2. You rely on a fixed switch-statement->class-inclusion way while the 
simple controller (and Elmar's proposals for recursion) knows this 
automatically and *only* from the path again.
3. You do access control based on tt_content, we *can* use that and any 
additional filters for finer access control.

So basically, I agree with your ideas of a controller, but IMHO the 
simple controller is much more flexible.

Greetings,
Michael