[Typo3-dev] TS inconsistencies...

[Hannes Schmidt]

Typoscript is harder to learn, than it appears. Usually, I pick up things
pretty fast. But with TS I had to spend a lot of time on a very simple
problem. See my previous postings.

The syntax is ok, allthough it could be streamlined a little bit (nesting of
conditionals, proper comments, and so on). The main problem is the
semantics. A beginner level Typo3 user could never ever understand or use TS
with just the documentation and examples at hand. One always needs to look
at the PHP implementation of the various constructs, objects and properties
in TS in order to get the semantics. This boils down to "Want to learn TS?
Learn PHP first!"

Anyway, Typo3 is a great thing. And it's Open Source. So I'll just have to
accept the shortcomings of TS. But begginners should be warned about the
complexity of TS.

And by the way, Typoscript IS a language. It has a syntax, so it is a
language. It's  not a programming languange but not all computer languages
are programming languages. There are configuration languages, specification
languages ...

----- Original Message ----- 
From: "dan frost" <dan at danfrost.co.uk>
To: <typo3-dev at lists.netfielders.de>
Sent: Thursday, July 24, 2003 1:52 PM
Subject: Re: [Typo3-dev] TS inconsistencies...


First, I know TS is not a "language". But, it's use, and the objects
which have the parameters TS sets imply a hierarchy which, I believe,
would be better expressed using proper object oriented programming.

Second, the reason I am suggesting this is that _I_ am not always the
person who has the problem. Often clients and collegues need help with
TS. If the TS-interpretation was better organised I could do this faster.

What I'm trying to get across is that TS does _not_ seem to be as
organised as other ways of setting parameters, or using APIs (e.g. APIs
in Java, XSLT (and I know the differences), various config files in
Linux and so on). If the code was organised, the reasons why a parameter
doesn't has such-and-such a property would be clear. For example, the
data-types and objects in the Java (and c++) language can be understood
by their inheritance hierarchy.

In sum: this would make TS more powerful interface to the Php functions
in Typo3 and the extensions.

Am I getting anywhere?
dan

>Hi Dan
>
>I also read your other mail where you suggest a more object orientated
>approach of TS.
>
>Even if it's not false what you suggest, it's not TS anymore. TS is not a
>language, it's just a way to define parameters.
>
>fontSize (Gifbuilder) is of type 'posint'. What means, the PHP function
which
>makes the text rendering expect an positive integer for that value. There's
>no addition like you would like to see above.
>
>What you meant with
>fontSize = GPVar:my_text_size
>
>is somthing like:
>
>fontSize = GPVar("my_text_size")
>
>This can't be done in TS. You can't get a value from a function (in that
way)
>in TS.
>The benefit from all that limitations is that TS is easy to implement and
it's
>faster than a real language. But it's still a little more than just setting
>up some parameters.
>
>But that limitations are not a real problem because there IS a real
language
>available which can be used if TS won't fit: PHP
>
>For your problem it means to write a small PHP script which go into an
>extension to make it nice and clean :-)
>
>In the script will be something like that:
>
>$conf['fontSize'] = t3lib_div::GPvar('my_text_size');
>$this->cObj->IMAGE($conf);
>
>in TS:
>
>page.10 = myIMAGE
>page.10 {
>// here can be used all IMAGE properties but font size will be set by the
PHP
>function
>
>
>Ok. That's not really working, but it's the principle. You may have a look
>into the randomImage extension which is an real example for that.
>
>
>René
>
>
>


_______________________________________________
Typo3-dev mailing list
Typo3-dev at lists.netfielders.de
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev