[TYPO3-ect] Cool overview of architecture

[Elmar Hinz]

Hello,

for those who are interested I want to give a short overview how cool will
work. 

# Outer API:

Naturally kt is like that of every plugin, because you want to run a cool
plugin just like every other plugin inside the framwork of T3.

# TS configuration:

The TS configuration consists of 2 parts, the typical configuration and the
configuration of object relations

## Typical TS configuration:

Just as usual.

## TS configuration of object realtions:

This is the interesting new part, that is much inspired by the spring
framework and adapted to the needs of PHP. It is somwhow similar to
services, but much easier to use and implemnt. 

Every object has a task. Normally already the classname informs about it.
There are factories, loaders, containers, finders, resolvers, etc. In the
TS configuration we setyp key/value pairs of the tasks and classnames, to
break it down. 

Whenever you need an object for a task, you call it by this task ID.

   Example: $this->Factory->find('Translator');

Here *Factory* is an objects property name for a task. *Translator* is a
public task ID. In the configuration you specify, which class should be
used for  each task ID. A very flexible way to extend and modify the
system.

### Setters are better than finders

In fact to call *find* is not always the best solution. I.e. you can
unit-test such objects only indirectly. We prefer setters to join the
objects. That is configured in the TS configuration.

1.) Resolver = tx_cool_Resolver
2.) Dispatcher = tx_cool_Dispatcher
3.) Dispatcher.set.Resolver.reference = Resolver

This is translated to this:

$Resolver = new tx_cool_Resolver();
$Dispatcher = new tx_cool_Dispatcher():
$Dispatcher->setResolver($Resolver);

This translation doesn't happen lineary, but is done by the main factory
upon demand. As a result one *find* call in a key position, can trigger the
creation of a dozen of related objects by this setter mechanism. Does this
sound paradox to you? It is. That's the *Inversion of control*. 

# From Request to response

1.) The outer T3 frameworks translates the TS to a PHP array and feeds it to
our plugin. 

2.) The *main* object, the *Factory*, also acts as a local and temporary
*container*.

3.) The *InfoSource* object is created.

4.) The *Controller* is created

5.) The *Parameters* object is created.

6.) The *signal* *Resolver* (action resolver) is created.

7.) The *task* *Dispatcher* is created.

8.) The first *Task* object is called. 

9.) Maybe further tasks are called until all is done.


# Comparism to lib/div?

 * Controller is splitted into Factory, Controller, Resolver, Dispatcher. 

 * Configurations becomes InfoSource and some more specific information
access objects.

 * Parameters stay Parameters.

 * Action methods become *Task* objects.

 * Action parameters become *Signals* send by links and submit buttons.

 * Designator becomes *Namespace*.

 * Object becomes Data and SelfAwarness is gone.

 * ViewBase becomes Transformer (maybe Caster).

 * Translator stays Translator.

 * ResultBrowser becomes Pager.

 * Div is gone.

Regards

Elmar