[Typo3-dev] ObTS - answers to questions (was: [Typo3] Accessibility and Typo3)

[dan frost]

> I`m also waiting for Dan Frost's OO-TS. This sounds really great.

First - my laptop has broken, putting me back by at least a week. Sorry 
about this - i'll get back on track asap. Also - anyone (preferably in 
england) know a linux-friendly laptop supplier who builds on site/in the 
country??

Second - this is in reply to an email on the english list, but is copied 
to the dev list to answer some questions.

Ok - I will now try briefly to describe how ObTS will work, what it will 
do, what it won't do and what problems it will cause. I will make 
reference to the (existing) source code.

TypoScript was, Kasper has told me, originally design to configure a 
very few variables. It has since grown to be what some have called a 
"language", although the issue remains contentious. This beginning and 
this grown explains perfectly why it appears "inconsistent" and, to the 
new comer, behaves strangely at times.

Having spent some time arguing on the dev-list, I said i'd go away and 
work on an alternative. Kasper encouraged me to think of my project as a 
different thing entirely, but I'm not sure I have done.

These were some of my thoughts:
- TypoScript is a system (language) of configuring webpages
- TypoScript is very useful for non-phpers and phpers with little time
- TypoScript offers an interface to programming-code for 
non-programmers, enabling them to use complex programs and code (e.g. 
extensions)
- TypoScript implies OO programming because different datatypes use the 
same, or similar functions; different datatypes often behave in similar 
ways; the code in tslib_content.php is similar from datatype to datatype.
- Because TypoScript uses the datatypes (listed in the huge switch 
statement near the top of tslib_content.php) we can regard TypoScript 
and the datatypes as the thing which determines what the html is like.

Here are the features of my system (at present):
- make a "TypoScript class" which describes how all TypoScript "object" 
behave.  This is ts_object in my system.
- Implement TypoScript objects as children (i.e. child extends...) which 
define how the particular child behaves and what it looks like. These 
are classes "tso_sometype" in my system.
- Implement a layer of abstraction between markup (html) and logic 
(typoscript).
- Implement all functions as php functions, and make them available to 
all datatypes, at all levels
- Improve debugging - in the finished system, you will be able to click 
on part of the (preview) page and see the configuration of that object; 
there will also be c4 debug levels: none, to log, to content, to admin 
panel.
- A backdoor - some of the internals of TypoScript (e.g. the arrangement 
of html tags and placing of data inside them) 'appear' to be built in 
TypoScript. I have built a "backdoor" function which gives TypoScripters 
access to the internal configuration of each TypoScrip datatype. This 
can also be used for building new (light-weight, low logic) datatypes
- Because TypoScript objects/datatypes are implemented in a modular way, 
it will be possible to give non-admin users access to some of typoScript 
(e.g. text, image, and no database functions..).


And what of xhtml and accessibility:
- The layer of (logic-markup) abstraction will ensure that each element 
of mark-up is good xhtml. It does this by using a php-array version of 
the xhtml DTD - it _will not_ render bad xhtml, because it can't (unless 
explicitly forced).
- There wil be "templates" used in the Form datatypes for things like 
<input../>, meaning that unless the TypoScripter forces the system not 
to, the input will be rendered with the input tag will always be 
rendered along-side a <label../> (See WAI guidelines)
- TypoScript objects don't return (i.e. make) html - them return mark-up 
objects. This means that, at each stage in building the page xhtml will 
be forced.
- In short: it will be able (if configured properly) to force xhtml 
compliance and, by using templates for some tags, accessibility. It will 
also, because of the debugging feature, be able warn when it generates 
something which might not be accessible.

So, Kasper, why have i implemented this as a replacement for TypoScript, 
and not a completely different system? The reasons are:
- my employer wants all TypoScript to be like Object-TypoScript
- I realised that "hi-jacking" the data-type calls from the switch 
statement in tslib_content.php is quite easy and
- Implementing different datatype in the system is, i found, quite simple.

So - that's (some of) it so far. This is how I plan to proceed.

Future development plan
#1 - I plan - and hope - to release the beta version in the next couple 
of weeks. (See laptop problem at start). This will be implemented as an 
extension (installed normally) and a patch (slight change) to 
tslib_content.php.

#2 - Once the parent "TypoScript class" is nearly finalised and it's 
behaviour is settled, anybody else can work on datatypes. I have already 
written most of the documentation on how to build new datatypes, new 
functions, and implement new XMLs etc.
If people are interested, I will set up a CVS server where developers 
can add new types, but only a few can change the parent "TypoScript class".
FYI: building a new datatype is pretty damn easy. Once the datatype is 
installed on a system, it is automatically available and can be tested.
FYI2: it would probably be possible to implement some extensions as 
simple TypoScript functions - e.g. to add example.getFromNewsFeed = 
url://.....

#3 - move the existing data-types over to ObTS. (Group effort).
#4 - build new data-types (Group effort).

I expect that we could start seeing a stable, and easily used extension 
by the end of January.

Some things which might be nice, and are made quite easy in ObTS:
- An XML implementation of ObTS to allow other tools to be used
- a GUI for ObTS
- A TypoScript "content element", or similar so typoScript benefits from 
the versioning, user-permissions and so on that real content elements have

I'm sorry to blast this out in one go, and before i've released it. I 
hope this answers lots of questions. I have almost got ObTS stable, but 
it's not been easy or quick.

Thanks for you patience...

Regards,
dan

P.s. I would like to thank Synergy Communications, who are paying for 
all of this work, and everyone who argued with and supported me some 5 
months ago on the dev list.