[Typo3-dev] Make configuration simple

[Kasper Skårhøj]

Hi Sven,

> The TYPO3 community has the mind to find an own way to do something when
> a problem must be resolved.

Yes, we tend to :-)

> There are configuration systems out there.
> Partly there are usable systems as example in java, there are xml
> examples also.

Lets get practical. 

If there is a standard outside TYPO3 that fits all our requirements I want to 
use that unless it is actually bad (XML is nice for many things but as JoH 
also hints at, representing TypoScript with XML will make it twice as long 
and not easier)

If there is no standard outside TypoScript that can give us a uniform 
framework for all configuration needs we must invent one ourselves that fits 
us perfectly.

Our current (solved) needs are:
- TypoScript Templates
- Page/User TSconfig, 
- Extensions configuration
- TYPO3_CONF_VARS
- Must be possible to apply globally (like TYPO3_CONF_VARS) and embed in page 
hierarchy (like TypoScript Templates, Page/User TSconfig)

Our future needs are:
- extendable other imaginable scenarios
- must be possible to validate semantically (not only syntax as now)
- must be easily human editable
- must be possible to write a nice GUI frontend for (editing)
- must have self-contained documentation of the features, plus definition of 
data types and other conditions


Actually, I doubt that other configuration frameworks can offer much more than 
another syntax because the semantics are always defined by the application 
using the configuration, right?

... and when it comes to syntax we could easily develop an abstraction layer 
that allows TypoScript syntax or some XML schema to be used in the future.

The main challenge is to validate the configuration syntax semantically and I 
will claim that what confuses people about TypoScript is not the syntax but 
the fact that they never know when they misspell something or place a 
property in a context where it doesn't make sense. THIS is the problem and 
THAT we can only solve on our own (I think, considering our needs).

- kasper

-- 
- kasper

-----------------
Think future, not feature