[TYPO3-50-general] TypoScript syntax: Array indexes

JoH asenau info at cybercraft.de
Thu Jul 19 11:19:00 CEST 2007


> So far so good. But not for the parser and not if we don't use
> numerical indexes. Consider this:
>
>     myObject = Template
>     myObject.file = xyz
>     myObject.subParts.footer = Text
>
> "file" is a property of the "Template" object and so is "subParts".
> However, subParts has Array behaviour (although it's no object) and
> footer is the index in that array. Now, from the parser's view this
> looks very ambiguous: How can it know (without knowing the internals
> of an object) that subParts behaves like an array?

Just because there is subparts "dot" footer.
A dot always marks a new array just like it is done by the current TS
parser.

> A cleaner approach would be to distinguish between properties and
> array indexes by using a different syntax:
>
>     myArrayObject = ContentArray
>
>     myArrayObject[10] = Text
>     myArrayObject[10].value = "Hello "
>
>     myArrayObject[20] = Text
>     myArrayObject[20].value = "world!"
>
> and
>
>     myObject = Template
>     myObject.file = xyz
>     myObject.subParts["footer"] = Text
>
> To me that looks intuitive enough and the parser is especially happy
> because he now gets a hint.

It already got the hint by the "dot".
For each array there are 2 keys, one using "name" and one using "name." They
contain a value for the key "name" and a subarray for the key "name.".
For simple elements that don't behave like an array there is just a "name"
and no dot.
The just contain a value but no subarray.
This is how it's currently done and it works fine regarding the handling of
subarrays.

> But there's even more trouble at the horizon: TypoScript allows for
> implicitly defining array objects, on the fly:
>
>     anotherObject.sub1.sub2.sub3 = ContentArray
>     anotherObject.sub1.sub2.sub3.1 = Text
>     anotherObject.sub1.sub2.sub3.1.value = "Yawn"
>
> This definition implies that "anotherObject", "sub1" and "sub2"
> should behave like an array, but they haven't been defined anywhere!
> We could agree on that if objects are created _implicitly_, they
> don't become true "ContentArray" objects but are just dumb PHP arrays
> which don't have any object behaviour, they only exist for containing
> sub arrays or objects. This compromise would read like this with the
> new syntax:
>
>     anotherObject.sub1.sub2.sub3 = ContentArray
>     anotherObject.sub1.sub2.sub3[1] = Text
>     anotherObject.sub1.sub2.sub3[1].value = "Yawn"
>
> So, what's your opinion? Can you live with that new syntax? Is it
> intuitive enough? Or do you see another loophole out of the parser
> dilemma?

Leave it as is, since this already works fine.
There are just a few elements in current TypoScript that behave like a real
content array.
i.e. PAGE, COA, GIFBUILDER and CASE. The rest can be a dumb PHP array and
still use these content arrays without changing the syntax in the end.

anotherObject.sub1.sub2.sub3 = ContentArray
anotherObject.sub1.sub2.sub3.1 = Text
anotherObject.sub1.sub2.sub3.1.value = "Yawn"

I know that 5.0 doesn't have to be backwards compatible, but why should we
confuse people who are already used to the syntax if it's not really
necessary?

Just my 0,02?

Joey

-- 
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your gob sometimes!)
Dieter Nuhr, German comedian
openBC/Xing: http://www.cybercraft.de
T3 cookbook: http://www.typo3experts.com




More information about the TYPO3-project-5_0-general mailing list