[Typo3-dev] TS inconsistencies...

[dan frost]

Kasper,

Thanks for your reply - interesting (on the other thread-fork) what you 
say about throwing TypoScript away. To make things a bit clearer: I use 
Php when I can because I know it. However, I work with people who don't 
know php, so they use TS. As the Php/Typo3 developer, I need to answer 
loads of questions on how-to-do this-and-that. So my problems is that 
TypoScript is not optional, it's essential.

And, in reply to throwing it away - I consider TypoScript as good an 
answer as any to the various problems. Its syntax is relatively

>... and my goal will be to have a strict way to define relations between objects and properties; so strict that the information can be transformed into a *semantics checker* that can tell you IF you use non-existing properties or WHAT properties are available to you anyways.
>
This sounds really exciting. Have you looked at Php5 - i think this 
would be a whole load easier with the new object model and class 
functions. I was thinking about this over the weekend - here's a 
thumbnail sketch:

1. The general datatype property contains all the properties and methods 
that everything needs - for example: name; parent; debug messages; and 
so on. It implements a number of interfaces which contains _all_ the 
methods/functions used - this is where stdWrap gets into the object.

2. Each TypoScript datatype extends or implements the general datatype 
or one or its children - e.g. HTML might extend TEXT, which in turn 
extends the general datatype

3. In the general datatype class, using PHP5's need __call (catch-all) 
function, you catch all the attempts to access functions and properties 
which any datatype does _not_ have. So, if, in writing a TS template, if 
try:

somedata.realproperty = 10
...this is fine. But if i try to use a non-existant function, or set a 
non-existant property,
somedata.not_real_function = 20
...then what will happen is:
- the TS parser will create an instance of the datatype "somedata"
- for each function used and property set, or called in the TS, those 
functions will be called in the instance of "somedata"
- when the property "realproperty" is set, the property in the class is 
set - this is fine
- when the function "not_real_function" is run (or tried to run), the 
catch-all (__call) function will return a TypoScript error.

So, in one fell swoop you built the strict relationships (datatypes are 
objects, and are extended; general functions are interfaces, and are 
implemented) _and_ built a way of debugging. If you want to change the 
way the debugger works, you change the __call function in the general 
datatype class. For example, you could have two flags:
$TS_BUG_VAR["log"] = true/false
$TS_BUG_VAR["echo"] = true/false
$TS_BUG_VAR["strict"] = true/false

...each of which would be checked by the __call function, and the 
appropriate result produced. You could "log" TS errors - so they can be 
printed onto the TS-editing screen; you could echo a warning into the 
html-page which is produced (for un-published pages). The last example 
flag could be for a transition between the current TypoScript to a 
stricter version - not sure what I mean by this, but threw it in anyway.

I'm still going to try to build this myself (over the next few months - 
too little time at the moment). I hope the ideas help... I can draw up a 
more formal spec if you - or anyone else - is interested.

Cheers,
dan