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

[Ernesto Baschny [cron IT]]

Sebastian KurfŸürst wrote: on 22.10.2008 12:31:

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

See my answer to Karsten about that. It doesn't need to output XML just
because the template is XML. See XSLT for example. If is a very strict
XML-templating (in fact transformation) markup, but it can generate not
only XML, but also TXT, CSV, even PDFs.

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

Having a DTD for invalid XML doesn't seem to be possible in my eyes. If
the template cannot even validate, how will a tool be able to apply or
enforce a DTD?

I don't see the phptal problem: The few phptal tags are valid XML, and
as long as your overall document is XHTML, all valid XHTML tags are
available. phptal is just a namespace inside the XHTML template.

> 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 :-)

Doesn't convince me as an argument not to enforce XML. There is also
some XSLT templates to transform XML to LaTeX (see
http://tbookdtd.sourceforge.net/). I expect the template engine also to
be able to generate LaTeX output.

For example a template to generate pages of blog entries in LaTeX could
look like that:

<f3:template f3:stripWhitespaces="true">
	\documentclass[a4paper, 11pt]{article}
	\begin{document}
	\tableofcontents
	\newpage

	<f3:for each="{blogPosts}" as="post">
		\section\{{post.title}}

		{post.posterName}: {post.posterEmail}
	</f3:for>
	\end{document}
</f3:template>

That is a perfectly valid "XML-snippet". See my reply to Karsten for
more examples and some considerations (like stripWhitespaces or
xmlEntitiesReplace).

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

This is what I love in Smarty and miss in phptal: "modifiers". So cool:

{$time|format_time}

But I would have no problem if we just had:

<f3:filter name="format_time">{time}</f3:filter>

So no conclusion on my side on that matter. :)


Cheers,
Ernesto