[TYPO3-core] RFC #17420: Add LOOP cObject

[Xavier Perseguers]

Hi,

> .... which is why I wouldn't fiddle with cObj->data, because it is not
> intended to be used like that. It expects data['uid'] etc.

Well, it works great even without "standard TYPO3" columns. I'm using 
->cObj->start() with any array content without problem :-).

> Why not introduce a new ->dataArray which could be anything implementing
> the "Iterator" class? This allows much more flexible ways of passing
> data to this LOOP without having to "pre-fill" an array.

Then it should not be named "dataArray" but "input" or "dataIterator" 
because it would not be an array all the time.

> And I was thinking: would this be more like a new feature on top of
> "CONTENT"? So that you could say CONTENT.selectArray (selecting from the
> internal array) instead of CONTENT.select (which selects from SQL)?

CONTENT is really DB-oriented, I'm not sure this is a good idea to mess 
up with non-DB input. If something from CONTENT and not available in 
LOOP would be useful, we could "borrow" it but having a dedicated cObj 
for this looks cleaner to me.

> Maybe we then also need some ways in TypoScript to manipulate this new
> dataArray? :)

There's a lack of real support for arrays in tslib_content, this should 
be another RFC to add such support. I did some quick "easy" changes that 
would allow to loop over GET array variables:

page.10 = LOOP
page.10.input.data = GP:foo
page.10.renderObj = TEXT
page.10.renderObj.field = 0
page.10.renderObj.noTrimWrap = |GET variable: |<br />|

(renamed current 'data' property into 'input' to be more eye-friendly).

and call your page with

?foo[]=value1&foo[]=value2

But as said, support for arrays does not work currently (I had to modify 
the end is_scalar() test of getGlobal() to support them) and this should 
be another RFC.

Xavier