[TYPO3-ect] TS Action chains for SPL objects

[Elmar Hinz]

Steffen Kamper wrote:

>>
>> defaultAction {
>>  START = model
>>  model = tx_bananas_models_board
>>  model.do.1 = load
>>  model.go.next = view
>>  view = tx_bananas_views_list
>>  view.do.1 = render
>>  view.do.1.1 = listTemplate
>>  view.go.next = translator
>>  translator = tx_lib_translator
>>  translator.1 = translateContent
>>  translator.return = content
>> }
>>
>> Well, there is stell an issue with the return syntax.
>>
>> Regards
>>
>> Elmar

Hi Steffen,

for Daniels new wiki documentation system:

> 
> Ah I see. That's really interesting. You call it defaultAction, that
> implicies that there are othere Actions possible.

Every controller needs one "defaultAction". A simple list view doesn't need
more than this one action.

> So does the TS replace the php-code or is it an alternative ?

It's an alternative. The one end are plain PHP controllers, the other end is
a plain TS configuration. You can mix and merge as you need, you can do it
all in plain PHP.

The TS end is most interesting. Using standard classes of "lib" and
of "lib__addon"-libraries, you will be able to confiugure complex
extensions without touching PHP at all. That's similar to tranditional T3
TS objects. Contrary to them in "lib" there are real objects and you can
extend and customize them all without running into XCLASS conflicts. 

But the special strenght of lib are action chains, that will enable you to
control complex forms and workflows on TS level, in combination with smarty
templates for example.

> Also i don't see - how are parameters handled in TS ? Looks like you do it
> in array, where does return values processed ?

Return values are not used at all. That's the trick. And no variables are
used as parameters. All can be written as literals. Very easy.

The SPL objects contain all data in the internal array. (Additinally you can
(ab)use the controller as data storage register.)

The SPL objects "eat" each other like fishes, to process the data: 

session > model > validation > session > view > translator 

The SPL object chain is the fundament of this TS action chain.

> How does simple switch-case works with the TS ?

They have to be implemented inside PHP objects. Each object returns result
states. In most cases it's one state: "next". Validator objects or captcha
objects return 2 states. You could call them "ok" and "ko" or "passed"
and "failed". 

In the TS setup you assign the next SPL objects to this result states. That
is also the central technique that Struts uses on the controller
level. "lib" transfers this technique to the level of each SPL object. I
think there is more flexibility in this, but there isn't a big difference.

Objects can return as many states as they like. That becomes interesting
when you want to program a configurable business workflow.

> Sorry for asking so lot, but i think the TS in general needs some more
> functionality to work on such high level. In this case TS is used like a
> programming language, and i wouldn't call TS a programming language (atm).

No it's not a programming language. You still need to program PHP objects.
But the success of TS, of mailformplus or of Struts teaches you, that it is
very successful, if you can easily (re)configure the interaction of that
objects.

Thank you for the interview.

Regards

Elmar