[Typo3-dev] Make configuration simple

Sven Wilhelm wilhelm at icecrash.com
Thu Oct 13 14:31:07 CEST 2005


Hi,

> Lets get practical. 
no problem :)

> 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)
and it make it usable by other systems too, one thing that community 
often forgets! When I need TYPO3 to configure all parts of the system 
that is bad. If I have a standard way to let development environment or 
any other specialized system configure the system, I'm much more open 
and more professional companies will join.

XML knowledge is available by all professional companies. The motivation 
to learn special systems, most times not. The company will use another 
system, java based or something else.


> 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.
Ok, I think you will know much more better if things could be solved 
with this systems, but some ideas from mine as I see this concepts as 
very powerful (please without any prejudice :)
Only XML one.

Very new on the floor: ZCML (Zope Configuration Markup Language)
Used inside ZOPE to configure many parts like the products (zope 
extensions) - Registering Interfaces, Classes that implement them, 
Rights Management,...

Much more longer on the floor: Eclipse (and very heavy with it's concepts)
Has a very basic and powerful concept "LAZY LOADING" which needs many 
declarative informations inside XML and only loads the implementation 
parts when requested (a way fully usable by the web).
Eclipse uses xml schema so each plugin can specify it's own necessary 
semantic.

Each TYPO3 extension could have it's own extension directory directly 
under typo3conf for it's customized configuration.


> Our current (solved) needs are:
> - TypoScript Templates
how much Typoscript do you need if the template system is powerfull 
enough? see TAL (ZOPE) or the PHP Implementation PHPTAL
> - Page/User TSconfig, 
Could be full powered by XML
> - Extensions configuration
I think also full transferable to XML
> - TYPO3_CONF_VARS
> - Must be possible to apply globally (like TYPO3_CONF_VARS) and embed in page 
> hierarchy (like TypoScript Templates, Page/User TSconfig)
Should nothing speak against the possibility to update xml values in 
deeper page sections.

The contra is the question how much flexibility is enough, where do you 
want to harden the configuration.

Also another point i18n:
There is no really need for xml, just a files like the gettext ones with 
format for sprintf.

> 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?
Full ack, I agree with that above. I only wanted to tell not use the 
100% own way but take up the concepts of other systems.


> .... 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).
Possible with XML. Also by external systems :)



Sven




More information about the TYPO3-dev mailing list