[TYPO3-ect] RFC: Namings and addressing data of the pipeline

[Elmar Hinz]

> * "give" the concept of extendability, because one can "through in" a
> new "plugin" (renderer, widget, service, extended SQL-queries,
> html-skins, new features for the main-extension) so that it gets into
> the whole tree.

But it also may lead to wrong expectations. The "plugins" have to be
connected to the tree. That is not always done by simple plugging, often
it's a form of binding.

The resultbrowser as example needs to be "weaved" into the HTML template as
a marker  AND into the action pipe as a processor. (That could be
implemented by TS.)

> 
> == the actions ==
>> b) Descibing the actions as "pipeline of processors":
>> 
>> We called that "action chain" before. It results in the acronym "PLOP".
> 
> not good IMHO. why not "workflow", "action chain", "pipeline" or
> "pipeline elements"?
> 
> == processor ==
> That sounds to big INMHO. something like "action", "task", "job",
> "workflow-item" sounds better.

"Workflow item" isn't bad. But item itself is passiv and could be mistaken
for the processed data. Leo.org doesn't offer that much alternatives for
the german term "verarbeiten". "Worker" maybe. That would match with the
image of a workflow.

> == Addressing data of the pipeline ==
> array-element what contains a string. Why isn't that possible in this
> case? For example $internalArray['content_ResultBrowser'] = 'xyz'

In the moment you process the list of uniform objects, for example in the
foreach-loop of the template, the loop stumbles over this extraordinary
value and breaks, because of an unexpected data format and unfitting data.

To sort the data by datatypes would be possible, but is a specialized
solution. A problem for general automation.

Regards

Elmar