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

[Ernesto Baschny [cron IT]]

Sebastian KurfŸürst wrote: on 22.10.2008 13:45:

>> It should just "do it". :) <f3:link> should know that it should
>> manipulate the parent tag.
> 
> To me, that would be too much magic happening intransparently behind the
> scenes. How do you explain that to somebody who expects that f3:link
> outputs the link itself?
> 
> What it really does is overriding the href from the surrounding tag,
> which is almost the same of what is done in my example:
> <a href="{f3:link:uriTo(controller='posts', action='editPost',
> parameter:postId='{postId}')}">Some link the templater knows about</a>
> 
> except that is clearly understandable that the href is actually filled
> in by the templating system.
> 
> So, I think we should discuss two different issues here:
> 
> 1) How do we fix the array-access problem?
> 
> 2) Do we want to have some "magic" manipulating surrounding tags as well?
> 
> What do you think? Does it make sense to split the questions up?

Splitting up is probably required. :)

About the link generation itself:

The link generator has to know the surroundings anyway, as a "link" is
not always an A-Tag (just in the XHTML context).

I think it is more "magic" to me what <f3:link> exactly generates. I
would like it to generate the link required for the current situation,
that is an "A-Tag" in the XHTML context (which is not only the href, but
also the title, class etc attributes, i.e. everything that typolink
currently generates).

Your idea of using the {f3:link:uriTo} inside the "href=" is of course
valid and will potentially be needed here and there (e.g. for
javascripting), but not so well aware of my current sites behaviours.

What should it do if the link turns out to be not generateable (e.g.
link to a page that does not exist?), or if the link consists of
javascript (encrypted mailto) which we might want to place in the
onclick attribute? And what about the site admin defining a class for
all "external links", I would love to see the templating engine just "do
it" without the template constructor having to think or even handle it.

For me, the "template" is at first XHTML (or TXT or RSS or whatever the
template is implementing) snippet. The <f3> tags and attributes should
be added to the XHTML-code, and not the other way around. Which is why I
prefer the approach of phptal.

Those kind of stuff:

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

where the inner tags implement something for its parent tag is already
well known and works very well in XSLT:

<xsl:element name="img">
	<xsl:attribute name="src"><xsl:value-of select="figure/graphic/@file"
/></xsl:attribute>
	<xsl:attribute name="width"><xsl:value-of
select="figure/graphic/@width" /></xsl:attribute>
	<xsl:attribute name="height"><xsl:value-of
select="figure/graphic/@height" /></xsl:attribute>
	<xsl:attribute name="title"><xsl:value-of select="figure/title"
/></xsl:attribute>
	<xsl:attribute name="alt"><xsl:value-of select="figure/title"
/></xsl:attribute>
</xsl:element>

That means this will generate a <img> tag with the attributes that
follow (<img src="..." width="..." ... />).

But maybe we could find a "way in between", so that the template keeps
its "XHTML-look" and we don't need the "magic" manipulation of parent
nodes. E.g:

<a f3:class="link" f3:method="urlTo">
	<f3:parameter name="controller" value="posts" />
	<f3:parameter name="action" value="editPost" />
	<f3:parameter name="request">
		<f3:item name="postId">{post.id}</f3:item>
	</f3:parameter>
	Edit post
</a>

That would be XHTML-conform, a browser will show a "link", but the
"link:urlTo" handler will be able to add the sugar needed so that it is
really the correct link (href, title, onclick, class, ...).

Another example are "titles". The template should not decide how
"titles" should be rendered. That should be a decision the site admin
makes. Which is what bothers the most of is: extensions ship with
templates that decide to mark-up headings starting with H3 or H2, while
we need H2's or even GIFBUILDER generated titles. So the template could
look like:

<h2 f3:method="header">
	<f3:parameter name="level" value="1" />
	Our header
</h2>

e.g. the extension developer ships his extension with those titles in
the default templates. TYPO3 could know about the "nesting level" of
titles and generate the header type required for the specific situation.
E.g. take the content "Our header" and make a GIF or a Flash animation
out of it.

I can imagine other kinds of "widgets" to appear and would expect TYPO3
to ship with "tons" of nice and functional widgets that template
developers could use and which site admins could adapt very quickly to
their own site implementation.

You see that I think more for the FRONTEND output, but I consider that
the same stuff is also valid for the BACKEND output. The consistent and
complete templating and widgets could be very useful for generating a
flexible backend that can be "easily" skinned.

Cheers,
Ernesto