[TYPO3-50-general] OrthoScript

[Robert Lemke]

Hi Elmar and the Martins,

the last two days I could experiment a little with the TypoScript 2.0  
implementation and made some nice progress (well, that's what I think  
at least ...). I'd like to give you my view on some ideas you  
mentioned in this thread.

> you probably share the experience, that many new developers are  
> irritated
> by the PHP representation of Typoscript with dots at the end of the
> key names. I suggest an inversion of this for TYPO3 5.0 by the  
> following
> model:
>
> TypoScript 2.0 (OrthoScript):
>
> $TS['we']['all']['love']['='] = 'typo3';
> $TS['we']['all']['love']['case']['='] = 'upper';

As Martin already mentioned, the plan is to represent TypoScript  
objects by real PHP objects. To give you an idea of how elegant that  
might look like please have a look at the implemenation of the good  
old "TEXT" object I committed today [1]. There's hardly any code in  
that class and I expect that it won't grow very much either.

What we currently call "stdWrap features" are then called  
"processors" and they can be used with any TypoScript property.  
Processors are invoked in a chain, which means you can do a wrap,  
then a crop, then a wrap again etc., just like in this example:

10 = Text
10.content = 'world!'
10.content.processors.1.wrap('Hello my ', '')
10.content.processors.2.crop(14, ' ...')
10.content.processors.2.wrap('<strong>', '</strong>')

Result:
Hello my world ...

Anyway, there are a lot more ideas and I still have to write them  
down ... and I will do that soon.

> But I have serious doubts, if it is a wise idea to use objects for the
> internal represantation of the mere TS configuration. That looks a  
> little
> to eager to me.
>
> Kind of oversized. Performance decreases. The work to manipulate the
> configuration within your PHP code increaes. You can't overwrite a  
> simple
> array anymore. I wonder, what shall be gained, while such a high  
> price is
> to pay.

The point is that we only parse the TypoScript source code once and  
the cache the objects. As TYPO3 5.0 will have good mechanisms for  
caching and persisting objects that is the most natural thing to do.  
And in theory, all that will consume even less memory than the  
current approach as we can apply, for example, the "Flyweight"  
pattern [2].

What we gain from it is a much more natural way to read the code and  
more powerful options for managing and validating the object tree.

> However that doesn't answer the question how the stored  
> configuration is
> treated internally before the object tree is build and how easy you  
> can
> work with this format.
>
> Now probably there is no configuration format any more, but the  
> objects
> themself from the very beginning. If it works this way that's  
> indeed clever
> and direct.

TypoScript will be just a representation of the TypoScript objects,  
it's there to make objects human readable and writeable. But we  
probably won't store TypoScript objects as TS source code - we'll  
have a content repository which can perfectly manage tree structures!

And why not use XML as an additional import or export format if  
there's a practical application for it.

> i suggest to examine alternative datastructures before deciding how  
> ts-2
> should be parsed at all.
>
> why not think about parsing ts to an internal xml-structure. i also
> think that it's makes no sense to use xml as a writing format (in the
> post above i just wanted to point out some similarities) and i do'nt
> think that the xml-structure should be serialized to a string at  
> all. so
> imho the verbosity of xml does not really count in case of internal  
> using.

A programming language like PHP doesn't work very effectively with  
XML internally, but it does a great job with handling objects - so I  
still believe that using objects are therefore the natural consequence.

> another alternative would be the use of the composite pattern but i  
> fear
> that would cause major performance problems.

The Composite Pattern doesn't exactly fit but it woldn't be a  
performance problem either (at most it would be a memory problem). As  
mentioned, we can easily reuse objects so I don't see a problem  
having an object tree made of composites and components.

> Currently the cache is in the "native" charset of the BE language (eg
> latin1 for German) regardless of the BE charset (eg utf8) or the  
> source
> of the data (locallang.php or locallang.xml). This means if the  
> "native"
> charset differs from the BE charset (eg when you use UTF8 on a German
> site) then TYPO3 will recode the strings every time.

About charsets: There will be one rule, rather a law, in TYPO3 5.0:  
Everything is UTF-8. The only point where you can configure charsets  
is when importing data (from files, streams, HTTP) or for the render  
output (and that is handled by PHP6 internally). It won't be possible  
to write TypoScript source or locallang or whatever in another format  
than UTF-8.

>>
>> Right. But once you have converted to XML with the xdev tools, you  
>> are on
>> the XML track, and it's a burdon to edit it by hand. TS would be much
>> faster to edit, even faster than the PHP array.
>>
>
> You mean something like a locallang.ts file? If it's in UTF8 fine  
> with me,
> but note that the XML format has some features like file  
> referencing . You
> don't need all those features for extensions, but the Core makes  
> use of it.

I'd like to suggest that we use TypoScript only as a configuration  
syntax for the content rendering. I have had many discussions during  
the last years where we had lots of ideas what else we could do with  
TS but my gut feeling says that we should not mix things up - how  
would you implement standard wrap in a locallang file? Or explain to  
someone that in that special scope standard wrap is not available?

I'm much in favour of consistency here ...

Anyway, I hope that I can demonstrate you my suggestion for TS 2.0  
soon, I'll be at least working on it the next days ...

Cheers,
robert

[1] http://5-0.dev.typo3.org/trac/TYPO3/browser/Packages/CMS/Classes/ 
TypoScript/T3P_CMS_TypoScript_Text.php
[2] http://en.wikipedia.org/wiki/Flyweight_pattern

-- 
http://typo3.org/gimmefive