[Typo3-dev] TypoScript - my point of view

[Martin Kutschker]

Hi!

Too much posts recently, so I decided to start my own thread :-)

* What is TypoScript?

To me it is a simple declaratice language suited for configuration. It's 
main advantage over xml is being more terse and so easier to edit 
manually. The syntax itself if is also easy to grasp. Bascically it 
comes down to <object>.<property> = <value>

The hard part is to learn all those objects. But this is similar to any 
language. PHP is easy, but still you have to learn all the funtions 
provided by the various extensions.

TS is also something that lives in an enviroment. TS features both 
constants that are decalred outside the scope of TS and conditionals. 
The latter depends only on the context (TS config, TS setup).

* Storing of TypoScript

Naturally TS itself will be stored in it's native formar, which is text. 
To speed up TS processing TS could be stored in such other format for 
caching purposes. IMHO xml is a bad choice for cache data, PHP 
serializing should be more efficient. But we must keep the conditionals 
in mind!

Anyway, the format of any cache must no influence the language itself. 
This is an implementation detail and has nothing to do with the syntax.

* Changing Typoscript

Changes are fine, but should IMHO be made with care. The migration must 
be easy, so I think only small changes are allowed. If we find that we 
must change many details, we should reconsider if we not simply drop TS 
altogether. But I don't think this is necessary.

But of course the most important thing is to define real goals for a new 
TS. Eg adding xml in itself has no value. Proper goals as I perceive it 
are finding a way to help users write correct TS.

* Formalizing Typoscript

IMHO the main problem of existing TS is that it has no formal 
description. This shortcoming defies any reasonable debugging or editing 
help like syntax highlighting or property tooltips (like in MS visual 
studio, etc).

If a way can be found to describe the syntax and define the objects and 
their properties, we can both validate the code and provide better 
assistance.

I think that for this part xml is a good choice.

* COBJ_COLLECTION / COC

To make a formal description easier I introduce the COC object. The only 
property of a COC is an associative array. Each member of the array is 
of the type COBJ. COBJ is the base class for all other TS objects.

COCobj = COBJ_COLLECTION
COCobj.property1 = <COBJ>
COCobj.property2 = <COBJ>

* the global object (root)

In any TS enviroment there is one global, but anonymous object. This 
object is of the type COBJ_COLLECTION.

This is why we can write stuff like this:

page = PAGE
mystuff = COA

page and mystuff are properties of the global object. That means we have 
no ambiguties when it comes to object creation are value assignment.

This is invalid:

mystring = foo bar

The global object is a COC which requires that its members are content 
objects.

With this change we do not need any new operators like * for object 
creation. But yet we gained the possibilty to validate TS code.

* default properties of the global object

The typical TS enviroment comes with a set of predefined properties. 
These are temp and lib. Their type is also COBJ_COLLECTION.

This is backwards compatible as long as you remember to use only objects.

Valid:

temp.foo = IMAGE
lib.tx_wonder = COA

Invalid:

temp.bar = blah blah

* implicit numeric arrays

Some objects like PAGE have currently numeric arrays in as properties 
which are adressed implicitly.

page.10 = COBJ

which should be more like one of those

page.body.10 = OBJ
page.body[10] = OBJ

Perhaps it is possible to describe this implicit property in a formal 
way. If not, a transition from TS to TSv2 will be hard.

* implicit stdWrap property of TEXT

I have no way how to solve this.

Same as above but even harder as the numeric arrays have one distinct 
feature: the key is a number.

But a transition is possible if all TEXT objects are converted to HTML 
objects or either all properties except "value" are moved to "stdWrap".

* conclusion

Making TS validatable is possible. What's more it is possible without 
too many changes to the syntax. In fact none are necessary. All that is 
for TS itself needed to be done, is to introduce COBJ_COLLECTION (and 
the global object).

The main task is to write the formal description. This description must 
define the syntax and list (in an extandable way) the object types and 
their properties.

Masi