[TYPO3-50-general] TypoScript 2.0 EBNF
robert at typo3.org
Tue Jun 12 10:46:28 CEST 2007
Am 12.06.2007 um 10:27 schrieb Elmar Hinz:
> Hmm, lexers also use regular expressions to tokenize. The API of
> the lexer
> is quite simple: "Give me the next token." It's the token source
> for the
> compiler. There is no need to reinvent regular expressions as an own
> finite state machine, even if you would use a fullblown lexer/compiler
Yes, I know. What I didn't emphasize enough was that my goal was to skip
tokenizing at all.
> Yes and no. It works. But it's a one step architecture. Separtion into
> different steps (preprocessor, lexer, compiler, ...) has the main
> target to
> keep each step as simple as possible. And simple steps are easy to
> improve or extend or to put additional steps in between.
Well, my motivation to make it a one-step parser was simplicity - I
it can be done for TypoScript because it didn't result in a complex
> Old TYPO3 IMHO died because of to less separation of functionality.
> improvemt or extension of the giant, complex objects and functions
> led to
> conflicts. It was to difficult to modernize it on time.
Absolutely. Honestly, if you have the impression that my current
is too complex or couldn't be changed easily, I have to rethink my
open for your suggestions.
>> Therefore most of the traditional conditions like browser agent, ip
>> address etc.
>> wouldn't work.
> At least if you don't want to parse it for each call. :-)
Yes. Of course we want to cache the TS object tree, that's also why I
speed is not that important yet.
>> Most of the other conditions (time, browser agent etc.) will have to
>> be implemented
>> with .if conditions. But at least we have simplified the syntax of
> So parse conditions could be implemented as a preprocessor.
> A chance to separate them from TS and to keep TS clean.
I guess that can be done, yes. But then the same is true for
variables - which are
one argument tokenizing.
More information about the TYPO3-project-5_0-general