[TYPO3-50-general] Re: [TYPO3-team-core-v5] Templating Engine

Wed Oct 22 11:24:06 CEST 2008

Hi Sebastian,

continuing in the typo3-5_0.general list:

Sebastian KurfŸürst wrote: on 21.10.2008 22:13:

> at the Transition Days, we have been thinking about a templating
> framework for TYPO3 v5. We have come pretty quickly to the conclusion
> that we'd need to write our own - and since then, I have started
> implementing it and now have a working prototype.
> 
> All specification and implementation notes can be found here:
> 
> http://forge.typo3.org/wiki/package-beer3/Start
> 
> So, it would be great if you could read it, and throw questions at me
> here at this newsgroup :-)

I like the idea of a fresh new templating engine. I think having that
"from start on" in TYPO3 5.0 also to be used for backend development has
many advantages for the consistency of future TYPO3 extension developers.

I also have been working for years with Smarty, and got productive with
phptal in some projects in the past few months. So I consider myself
"templating-expert". :)

About the syntax of beer3:

In my opinion we need to be more XML-compliant if we want people to
understand the syntax without much surprises. That was what I liked most
in phptal: The template is validatable, it contains the templating stuff
but also the XHTML stuff, which is of course also XML! So the
combination of both makes it very powerful, and the auto-completion and
syntax-highlighting (and validation) feature of editors can be used,
which I miss in Smarty, where my templates are not really valid because
of the un-XML-tags in between "{}".

So that is my first point:

You say: "Your template does not have to be in XML, but the templating
tags have to be nested and closed correctly.". - But why would we allow
non-XML templates? That just brings us to the pre-validation age!
Writing correct XML is so easy! So many tools available nowadays to work
with such files. That would be a big mistake not to keep on that route.

Then: "{namespace f3=F3::Beer3::ViewHelpers}" - that is pretty strange?
Why reinvent some new namespacing concept, if XML has namespace concept
since its birth? I would use that! Something like:

<?xml version="1.0"?>
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:f3="http://flow3.org/beer3/v1">
...

Which would give us <f3:..> namespace which can be validated and even
autocompleted by editors, if we supply a schema.

The access to objects and properties through a simple "." separator is
cool, looks a bit like phptal.

The array-accessing syntax for attributes with requestParameters:postId
doesn't look very intuitive to me, as it might become very unhandy if we
have many parameters. I agree with Sebastian G. and Bastian for a more
nested way of adding parameters. This is also the way XSL handles it.
Your example:

<f3:link:to
	controller="posts"
	action="editPost"
	requestParameters:postId="{post.id}">Edit post</f3:link:to>

Maybe some shorter version of Sebastian G's suggestion, with the benefit
that we can also "preview" it in a regular browser (a browser will not
understand the <f3:link:to> as a link):

<a href="#">
	<f3:link controller="posts" action="editPost">
		<f3:parameter name="postId">{post.id}</f3:parameter>
	</f3:link>
	Edit post
</a>

The <f3:link> handler would know that he needs to generate a link for
the parent element, which is an "a-tag", so he will generate the href,
and maybe a title, or a onclick event.

I think if we need a {} as a placeholder for "something", we shouldn't
create a complex syntax for it. Just create a method for capturing
certain input and reuse of it. So your example:

{f3:link:to("Edit blog", action="blogPosts")}

could be:

<f3:define name="blogPostLink">
	<f3:link controller="posts" action="editPost">
		<f3:parameter name="postId">{post.id}</f3:parameter>
	</f3:link>
</f3:define>

{blogPostLink}

Ok, that's it for now.. :)

Cheers,
Ernesto