[Typo3-dev] Normalisation / OOP - a Case Study (ObTS)

[dan frost]

Dear all,

We have been talking about normalisation and OOPing TYPO3. A few have 
even mentioned MVC and AOP.

There are a few problems that would get in the way of this: backwards 
compatibility, performance, people's unwillingness to change, extensions 
breaking, the community breaking...

By way of a case study, I'd like to tell you about building ObTS.

I came up with the idea of ObTS when I discovered that TypoScript was 
implemented in a scripty way. Each datatype is "found" by a large switch 
statement in tslib_cObj and then rendered by a function in the same 
class. In addition, functions (e.g. wrap.) have to be implemented by the 
datatype's function explicitly checking for it.

The problems with this are:
- Can't add new datatypes without changing the core
- Functions aren't guaranteed
- Changing the behaviour of several datatypes will probably mean change 
lots of code
And so on - basically, the system is inconsistent

(BUT: it made sense when it was written. Kasper tells me that TypoScript 
was originally built to configure one variable!)

So, what did i do? Does it work with traditional TypoScript? How hard 
was it.

All I did was:
1. Add a hook at the top of the switch statement and make the "look-up" 
use an associative array instead of a switch statement. This means that 
new datatypes are added by adding them into the associative array - not 
by adding more code into the switch statement

2. Make a parent "datatype" class which controls
- - finding and running functions
- - finding and running "child datatypes (e.g. in page.10 = TEXT, "10" 
is a child datatype of "page")
- - the rendering

3. Make datatypes (such as TEXT, MENU etc) as classes which extend the 
parent

4. All "old datatypes" (from the switch statement) to be seen and 
rendered using tslib_cOBJ inside ObTS datatypes

Does it work with trad-TS (as i call it!)
Yes - as of TYPO3 3.7. You can use ObTS datatypes inside TS datatypes 
and visa-versa. However, functions (e.g. wrap. stdwrap.) don't work the 
same.

How hard was it?
Very - but i didn't even know TypoScript! If i did it now it would be 
easier.


My conclusions are:
- In TYPO3 there is often a "hook" point where we could hijack the flow 
into alternative classes (like i did in the switch statement)
- This often just requires a specific hook for the purpose
- The hook can eventually become *the* official way of doing things

There will always be teathing problems - but I would like to reasure 
people: it is possible to change things with very small changes to the 
code. For example, to OOP a set of class (or 1 class) in TYPO3 you can 
hijack part of it into your own family of classes (as i've done).

This might help with DB-normalisation. We could refactor the classes at 
the same time as normalising the database.


In my opinion: it is best to start with the attitude "breaking stuff 
doesn't matter - just make it great" and work back.

Dan