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

Robert Lemke robert at typo3.org
Thu Jul 19 11:35:19 CEST 2007


Hi Joey,

Am 19.07.2007 um 11:19 schrieb JoH asenau:

>> "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.

Well, no: A dot marks

   - a property of the current object
   - a sub object of the current object
   - an index of the current array

It's not possible to distinguish between a property name or an object  
name.

> 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.".

But we don't work with arrays anymore, we now have true objects. Take  
the Page
object for example: It is a regular PHP object which has properties  
(title,
page id, ...) and sub objects (10, 20, 30 ...). In the TS object  
tree, the Page
object is an object too, not a PHP array!

> 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.

If the array has no other properties (like probably a dumb  
ContentArray) that is
true. But it's not true for objects like Page, Template or the like.

> 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.
>
> 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?

I agree, I want to change as few as possible, too. But we decided  
(for very good
reasons, as I think) to use real PHP objects which represent  
TypoScript objects.
They give us all the flexibility and consistency we were seeking for.

So, I'm afraid, leaving it just like it is is probably not possible.

robert
-- 
http://typo3.org/gimmefive




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