[TYPO3-50-general] TypoScript 2.0 syntax

[Robert Lemke]

Hi everybody,

as promised, I now write the mail again that I lost due to some  
unknown reason ...

> Question 1) The operator > is used to unset an option or its values  
> and
> properties. In several programming languages you can use constructs  
> like
> "= null".
> e.g.: something = null
>
> Please notice that "null" is named different according the coding
> language. What about integrating something like this into TYPO3?

Why not - we can create a predefined constant "NULL" which has the value
null. Then we don't even have to change the parsing rules, NULL is just
a constant.

I suggest that we also define TRUE and FALSE as constants.

> Question 2) In PHP and several other languages you can use double  
> quotes
> or single quotes to tell the interpreter that you want a string. In  
> TPO3
> you can only use double quotationmarks, right?.

No, TypoScript 2.0 allows you to use both, double- an single quotes.  
Some
valid examples:

   "And he said: \"Hello world\"."
   "And he said: 'Hello world'."
   'And he said: "Hello world".'
   'And he said: \'Hello world\'.'
   "Here's one backslash: \\ - quite easy."

> Question 3)
> If you look at
> myObject.value = $hello . "<br />Nice that you\'re here again.<br / 
> >" .
> $goodbye
> Why does the ' has to be (What was the right word again? hmmmm) So why
> do you have to write a \ in front of it? TYPO3 should know that  
> there is
> no ' in the string to do something, so " ' " should do the thing..
> shouldn't it?

yes, that was a mistake - if you wrap it in double quotes, you can use
single quotes within the string without escaping.

> The name
> - Just wondering: Why did you chose to stick to the name TypoScript
> after all?

We had some other names in mind, like for example  
"TypoConfig" (because it
configures something). But in the end it is a kind of object definition
language which allows for calling scripts (ie. the processor methods,
earlier called "stdWrap").

During discussions we tried to use the new name of TypoScript but it  
felt
really awkward and therefore we agreed that keeping the name will  
probably
lead to a higher acceptance by those who already work with TYPO3.

> Chapter 2.2
> - Why are both single- and double quotes allowed?

To save you from escaping quotes if you use only single- or double  
quotes
in your string respectively. See the above examples.

> - The concept of a "variable" is only introduced later on, so this was
> confusing to me when I read this passage. Maybe a reference to chapter
> 2.10 would be helpful.

Okay, I added a reference.

> - The example states an HTML-object. Maybe this example is a bit
> unfortunate, because just few sentences above, all uppercase is  
> declared
> for constants, now HTML is used as an object. According to the coding
> guidlines, this naming might be ok, but to avoid confusion, another
> object like Text might be a better choice.

I guess we can improve the examples as soon as we have more  
TypoScript objects
defined. I'd say I keep it for now but we should come back to this  
later.

> BTW: the guidelines only state that abbreviations _embedded_ in  
> names should be kept uppercase.
> What about this case, where the whole name is an abbreviation? HTML  
> or Html?

HTML. I added a few examples to the coding guidelines.

> Chapter 2.8
> - What is the motivation of allowing just one slash to be a comment? I
> think that's quite unusual.

Holy cow of backward compatibility. But you're right, that doesn't  
make sense.
I removed that.

> Chapter 2.10
> - Small typo: "which combines the these" ("the" is obsolete)

fixed.

> - I think the concept of variables is useful, but it was a bit  
> confusing
> at first sight. E.g. the fact that only TypoScript Contenct Objects  
> can
> be concatenated as a string added to this confusion. How about if each
> TypoScript Class was required to implement a certain interface, and  
> this
> interface has a toString() function (like in Java)? This way, any
> TypoScript object could be turned into a string and could therefore  
> also
> be concatenated.

That is already the case! We currently have this class hierarchy:

   - T3P_TypoScript_AbstractObject
           -> a generic TS object, eg. for config
     - T3P_TypoScript_AbstractContentObject
           -> a TS content object which implements the __toString and
              "getRenderedContent" methods
       - T3P_TypoScript_AbstractContentArrayObject
           -> a TS content object which allows for sub-objects  
identified
              by a numeric index. Eg. page.10 = Text

Therefore the TS content objects are concetenated just by combining the
related PHP objects and casting the whole thing into a string (which
calls the __toString method).

> Chapter 2.12
> - Small type (near the end): "variables as arguements"

fixed.

> - I like the concept of "processors". I think this is a big step ahead
> and much simpler than stdWrap...!

I'm glad to hear that!

> Chapter 2.13
> - I also like the concept of namespaces. Do I understand this right:
> Every TypoScrip object of a component other than the CMS component can
> only be used with namespaces? So the example in chapter 2.3 would
> actually read like this?
>
> namespace: party = T3P_Party_TypoScript
> somePerson = party:Person
> somePerson.firstName = "John"
> somePerson.lastName = "Doe"
> somePerson.address.street = "Rigensgade"
> somePerson.address.city = "København"

yes. But this is also allowed:

someObject = Text
someObject.value = "Hooray!"

namespace: default = T3P_Party_TypoScript
somePerson = Person
somPerson.firstName = "John"

namespace: default = T3P_CMS_TypoScript

someOtherObject = Text

> Generally
> I think one of the weak points of the current TypoScript is the fact
> that it cannot be validated. By validation I do not only mean syntax
> checking but also making sure that the code is meaningful, e.g. only
> known objects can be used, the arguments of processors are checked,  
> the
> attributes of objects are checked, etc. Are there already ideas about
> how to do this in 5.0? Might it make sense to somehow have a
> "declaration" of TypoScript objects against which can be checked?

I don't think it makes sense to have a declaration or schema as the  
basis
for validation within TYPO3 at least. It's much easier! The only  
thing we
have (and probably will) do is reflecting the classes involved:

   - does the class T3P_CMS_TypoScript_Text have a setter method for the
     property "shoeSize"? No - throw a TypoScript exception.
   - what are the are the accessible properties of  
T3P_Party_TypoScript_Person?
     Display that list of properties in the TS editor.
   - What arguments requires the processor method wrap? Read the  
PHPDoc documentation
     and display it as tooltips in the TS editor.

So generally the idea is to use reflection and document the TypoScript
functionality directly in the PHP code (with JavaDoc style comments  
for the
methods and properties) and display that documentation in a cool TS  
editor
as well as including it into the DocBook documentation.

> - Names
> I like the idea but maybe you should think about some kind of  
> aliases. I
> fear that I have to write things like "HierarchicalMenu",
> "ActiveWithSubpagesRollover" or "CurrentWithSubpagesRollover" all the
> time. You also write "Html" (please make it all uppercase) instead of
> "HyperTextMarkupLanguage" ;-)

I'm against aliases but maybe we can find clever names which don't  
require
a lot of typing. Although I agree that typing something like "ActiveWith
SubpagesRollover" can become annoying, I generally defend consistency  
here ...

> - Namesspaces
> Great idea. In current TS we can copy things from the same level  
> into an
> other object. Something like ACT < .NO
> Wouldn't it a good idea to enhance this and make it possible to have
> paths like in every OS?
>
> Example:
>
> myObjectLibrary {
> 	hello = Text
> 	hello.value = "Hello "
> 	hello.processors.1.wrap("<strong>"|"</strong>")
>
> 	world = Text
> 	world.value = "World"
> 	world.processors =< ..hello.processors
> }
>
> Well, this example doesn't make too much sense and "..bla.bla" doesn't
> look very intuitive but maybe someone has another approach!?

Hmm, in my opinion: better not. I think a single dot for referring to  
the
same level is okay but referring to levels which are more far away can
create quite some confusion, especially if the code defining that object
is located in a different TS template.

> (about comments:) We should use one or more of these:
> /* Bla */
> // Bla
> # Bla
> { BLA }
> (* BLA *)
>
> The last two are coming from Turbo Pascal ;)

Uhm, let's please leave it at Turbo Pascal then ;-)

> Well. Please notice, that TYPO3 should be able to identify the  
> ending of
> a comment if it's in the same line as the start..

Just for you I already implemented that (is already committed to SVN).

> For what advantage? I mean in TS, every line is exactly one "command".
> Why should I want to paste somewhere inside such a command? I never  
> saw,
> such things in code. ^^
>
> Would you write things like that in PHP:
>
> 	$myString /* great variablename, isn't it? */ = 'Hello World';
>
> I can't imagine. So why should we do that in TS?

I suggest this compromise (which is currently the implementation as  
well):

   - A block comment starts with /* and it must be the first characters
     in the line!
   - A block comment ends with */ and after that TS code may follow.

During some coding night with Karsten a few days ago, I worked much  
more on the
TS parser implemenatation. If you look at the current SVN version,  
you will find
a little commented line in the index.php - if you enable it (and  
disable the
$TYPO3->run() call) the MVC framework will be used and a whole page,  
configured
by real TypoScript will be rendered.

Have a look at the "test/fixtures" directory in the CMS package if  
you'd like to
play around with TS and check out the TS parser in the TypoScript  
package.

The parser still lacks some functionality (like confinements,  
processor invocations
and variables support) but hey, it's already something ;-)

I'll let you know as soon as there are any news about the TS parser  
or syntax and
will hopefully find the time to create a little podcast about it, too.

Thank you for your valuable input!

robert
-- 
http://typo3.org/gimmefive