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

Sebastian KurfŸürst sebastian at typo3.org
Wed Oct 22 12:31:54 CEST 2008


Hi Ernesto,

thanks for your input!

> 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". :)
Great - We need you! ;-)

> 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.

I see your point, but I had two things which caused me to do it differently:
1) How do you easily create non-XML templates? For example a LaTeX 
output template, a vCard template, ...
I really think that our template engine should support this also. That's 
why we've currently taken the route so that only the templating tags 
have to be nested correctly.
IMHO a templating engine should enable the user to create with it 
whatever he wants, with no real limitation to the HTML scope for example.

2) Tool support:
Of course, we encourage people to write valid XHTML, and we will provide 
  a DTD generator in the templating engine which parses all available 
view helpers - so you'll have autocompletion for all tags in Eclipse or 
other editors supporting DTDs.
I think that is even a major benefit over PHPTal: In phpTal, you have 
only a few tags which are validated, but nothing is validated _inside_ 
these tags - with our solution, the user will get feedback about all 
possible options for a tag.

> 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.
Yes, that is planned as well! Basically the DTD will be autogenerated 
from the tag annotations, so your DTD will point to a controller within 
the framework generating the DTD.
However I think we still need an _alternative_ way of specifying 
namespaces, that is, if you want to output a LaTeX template for example. 
I just implemented the alternative first :-)

> 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.
Yes, I know, but that is what I do not like about XSL - it is very very 
verbose - so verbose that for me, it is sometimes even unreadable.

> 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 don't like that the f3:link handler would need to understand the 
surrounding tags, because it is not really dependend on the XML syntax IMO.

What do you think of the following to archieve your goal:

<a href="{f3:link:uriTo(controller='posts', action='editPost', 
parameter:postId='{postId}')}">Some link the templater knows about</a>

I am not yet fully satisfied with the parameter:postId syntax, and I've 
been thinking about:
parameter_postId
parameter-postId
parameter.postId
parameter:postId

None of them would be validatable or part of the DTD, simply because we 
cannot know what parameter names the user wants to call.

> 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}
That's pretty close to phpTal I think :-) I like it pretty much, but I 
really thought it was a benefit to call view helpers either with tags or 
with the shorthand syntax {}.
Imagine you have a view helper which formats an unix timestamp - it 
would be helpful, if that would work with both syntaxes.

Besides, the logic behind was, that if you use {something}, it is just a 
variable reference, while if you use {f3:something}, it is a call to the 
"something" view helper.

I'm happy about this discussion :-)
Thanks for your ideas, and I hope we will come to some great conclusion 
in the end!

Greets,
Sebastian


More information about the TYPO3-project-5_0-general mailing list