[Typo3-dev] TypoScript 2: a bit of a RFC

[Christopher]

On 30/11/05, JoH <info at cybercraft.de> wrote:
> > Thought #2 - do not invent a new language / syntax
> > if one exists already. If you think TS is just a
> > config language, use an XML language; if it is a
> > functional language, use a python-like syntax; if
> > it is a fully functional language, use PHP...
> > there's no point in building new stuff when old
> > stuff exists....
>
> Oh yeah! - Maybe we should drop all these "languages" then and start coding
> everything in assembler?
>
> TS as a config language is much better than XML since it's easier to
> read/write and less overhead.
> Why should one want to write XML Tags instead of some dots, equal signs and
> /or brackets?
> For the same reasons TS as a (fully) functional language (which it is not
> and AFAIK it was never aimed to be) would be much better than Python or PHP.
> It's like stenography for PHP functions and/or arrays and this is what makes
> it so use- and powerful.


Elmar has _repeatedly_ said that he is not interested in doing
anything TS-related with xml _except_ storage and validation. Everyone
in the thread so far, including Dan and Elmar have agreed that one of
the notable advantages of TS is its brevity. The overhead is a
legitimate concern, but if it's stored as a serialized array...


> Take tt_news as an example:
> If you (as an exprienced XML- and PHP-coder) will be able to code the whole
> plugin.tt_news setup + additional functionality using GIFBUILDER and other
> natty things in XML and/or PHP _by hand_ within the same time I can do it
> using the existing TypoScript, then you might be able to convince me that
> you are on the right track.


Agreed, but this is not quite what anyone has said.


> At the moment I just get the impression that you are trying to prove it can
> be done another way. I don't see the reason though. And I don't see how this
> could push TYPO3 to the next level.
>
> IMHO it would be much better (and less time consuming!) to improve the
> existing TS by
> 1. Adding missing functionality wherever necessary
> 2. Removing inconsistencies/redundancies in naming and functionality
> 3. Improving the performance of the functions "behind" TS (especially
> stdWrap)

Provided a way could be found to parse/validate/error-check TS and
identify/report errors, the first two of these points are _exactly_
what this thread is already about. In the process of tturning
TS--whether it is a configuration language or something else--into a
tool that can  actually be [semi-] automatically _checked_ for errors,
it would be _necessary_ to make it vastly more consistent--which would
cover points 1 and 2 by 'filling in' the gaps where otherwise similar
objects are unevenly implemented or named.

As for point 3, I simply agree ;)

> You did a big step in this direction by publishing ObTS, but now you made a
> complete turnaround and I can't understand why ...
>
> BTW: There's another reason why you should improve TS instead of replacing
> it with other things:
> Thousands and thousands of existing TYPO3 installations that are depending
> on it.

This is a flimsy reason given how simple it'd be to avoid the problem:

e.g. config.use_original_typoscript = 1

Additionally, some backwards compatibility is already _planned_ to be
discarded with TYPO3 5. Still, I agree; given the installed base and
the amount of time & resources the TYPO3 community has already spent
building expertise in the original flavour of TS, a sudden break would
be crazy...


-Christopher