Template Engines Really DO Suck

[Buddha443556]

Now my girlfriend is extremely good in imagining herself in someone else's shoes, she also has the ability to remain quite objective and sober. You know what she started thinking when I told her about php as language in a html template? Arrogant
I think she is absolutely right. You see, she imagined herself as a webdesigner and immediately felt that something was being "forced" upon her that really shouldn't be.

I think it's just as arrogant to force some pseudo language like Smarty on web designers too. At least that's what my cat said when I asked him.

[Captain Proton]

At least that's what my cat said when I asked him.

lol

and..indeed:

..."not another "not another "not another template discussion" discussion" discussion"...

[been]

Captain Proton, these threads will keep on raising their ugly heads I'm afraid.

Maybe sitepoint should develop a bot:

-----%<--------------------

Hi there!

Just wanted to warn you you're gonna be in for a lengthy discussion, the infamous "Not another template discussion part ${useless_template_discussion_part_number}"

The reason you are gonna have this discussion is because everybody has a different idea of what a template is.
As such the discussion will be pointless.

Please clarify what you mean by template.

Have a nice day!
SP-NATD

-----%<--------------------


Seems like 2 files are mixed and called "template":
A source file of a designer's software tool. Let's call this Template1 for simplicity.
A file that's read and processed by a webapp, it contains place holders that will be replaced at runtime with dynamic content. Let's call this Template2.

Numerous times, I have referred to Template1 as "a template". Definitely incorrect, but I couldn't come up with anything better and "designer's tool source file" becomes tedious to write and read.

I was trying to get across that Template1 and Template2 are different things, and that it doesn't seem like a good thing to me to replace one with the other for the deceiving easyness of then having to only process one file.

Well, I'm glad mwmitchell got it, and it seems that at least the cat of mr. Buddha had some notion about what I was rambling on about.

Yes, I was being very naïve, even arrogant, thinking I would get my thoughts across in a non-native-spoken language that would be equally pleasant for me to write as it would be for someone to read.
I've failed miserably

Apologies for having taken up that much forum space.

[Buddha443556]

That darn cat of mine is too smart.

Usually when dealing with designers I only expect template1, I always figure it's my job to come up with template2. I kind of wonder if I'm the only one who works this way?

I don't think you failed BEEN. You english is better than mine, @#$% THOSE AMERICAN PUBLIC SCHOOLS!!

[dagfinn]

I was thinking about this a while ago and mentioned it to a friend, giving this example

<h1>{$word}<h1>
<ul>
  <loop>
  <li>{$element}</li>
  </loop>
</ul>

and he said something like "it's all the same, just diff sytax for the same thing"

and I though "he's right". I mean is that really different to:

<h1><?=$word><h1>
<ul>
  <foreach($list as $element):>
  <li><?=$element?></li>
  <? endforeach ?>
</ul>

I'd like to mention that some template languages really are different. An attribute language like PHPTAL is one example.

<h1 tal:content="$word">Fruit (this is dummy content that doesn't appear in the result)<h1>
<ul tal:repeat="element list">
  <li tal:content="element">Orange (=more dummy content)</li>
  <li tal:replace="">Banana</li>
  <li tal:replace="">Mango</li>
</ul>

[/QUOTE]

[dagfinn]

I was thinking about this a while ago and mentioned it to a friend, giving this example

<h1>{$word}<h1>
<ul>
  <loop>
  <li>{$element}</li>
  </loop>
</ul>

and he said something like "it's all the same, just diff sytax for the same thing"

and I though "he's right". I mean is that really different to:

<h1><?=$word><h1>
<ul>
  <foreach($list as $element):>
  <li><?=$element?></li>
  <? endforeach ?>
</ul>

I'd like to mention that some template languages really are different. An attribute language like PHPTAL is one example.

<h1 tal:content="word">Fruit (this is dummy content that doesn't appear in the result)<h1/>
<ul tal:repeat="element list">
  <li tal:content="element">Orange (=more dummy content)</li>
  <li tal:replace="">Banana</li>
  <li tal:replace="">Mango</li>
</ul>

Open it in a WYSIWYG editor, and you will see the list with dummy content. So it looks a lot like the page that will be generated by the application.

[been]

I can't believe I went through all the trouble...
Seriously, what was that all about? A sad try at my 15 minutes of fame?

Anyway, I just realized a better message for the not-another-template-debate-bot would be:

---%<----------

Hello there,

You could be heading for a long and maybe pointless discussion, we would like to point your attention to
http://wact.sourceforge.net/index.php/TemplateView

If, after reading that, you happen to have any questions/enlightening opinions/grutches/etc... about "templating", feel free to post them.
If not, and this is especially for member been, you may very well consider to refrain from posting.

Thank you and have a nice day!
SP-NATD

---%<----------

[prefab]

I'd like to mention that some template languages really are different. An attribute language like PHPTAL is one example.

<h1 tal:content="word">Fruit (this is dummy content that doesn't appear in the result)<h1/>
<ul tal:repeat="element list">
  <li tal:content="element">Orange (=more dummy content)</li>
  <li tal:replace="">Banana</li>
  <li tal:replace="">Mango</li>
</ul>

Open it in a WYSIWYG editor, and you will see the list with dummy content. So it looks a lot like the page that will be generated by the application.

I'm interested to PHPTAL as well, mainly because of the attribute language aspect. Would you mind sharing your experience (if any) with PHPTAL?
How does it compare feature/speedwise to other, more popular engines?
I can imagine that designers are quite happy with TAL too...being a designer+coder myself...
I use PEAR::HTML_Flexy atm, but I try to keep my eyes open

Thanks!

[mwmitchell]

I can't believe I went through all the trouble...
Seriously, what was that all about? A sad try at my 15 minutes of fame?

Anyway, I just realized a better message for the not-another-template-debate-bot would be:

---%<----------

Hello there,

You could be heading for a long and maybe pointless discussion, we would like to point your attention to
http://wact.sourceforge.net/index.php/TemplateView

If, after reading that, you happen to have any questions/enlightening opinions/grutches/etc... about "templating", feel free to post them.
If not, and this is especially for member been, you may very well consider to refrain from posting.

Thank you and have a nice day!
SP-NATD

---%<----------

Ha! That's funny! It's OK, that's what these forums are for right? If people are talking, there is a need to talk.

Matt

[dagfinn]

I'm interested to PHPTAL as well, mainly because of the attribute language aspect. Would you mind sharing your experience (if any) with PHPTAL?
How does it compare feature/speedwise to other, more popular engines?

I did a benchmark comparing a simple template using a few different template engines including Smarty. Their performance was pretty similar.

I haven't tried to compare features. The manual is at http://phptal.sourceforge.net/bagpac...te_PHPTAL/doc/.

[Selkirk]

You could be heading for a long and maybe pointless discussion, we would like to point your attention to
http://wact.sourceforge.net/index.php/TemplateView

If, after reading that, you happen to have any questions/enlightening opinions/grutches/etc... about "templating", feel free to post them.

Actually, I started the TemplateView page with the intent that it be used like a template FAQ. A lot of sitepoint grinding has gone into making that sausage.

I have some updates to make to that page. Some recent work on the Model View Controller and study of the paper Enforcing Model-View Seperation in Template Engines [PDF] have given me new perspectives.

I'd like to update the whole Presentation Logic and Templates section, add a section on how TemplateView fits inside the MVC pattern and expand on the Push versus Pull Data Population.

[Widow Maker]

Thanks for the link to the PDF Selkirk - going to read it later

...intent that it be used like a template FAQ.

Keep up the good work, the more information available, the better. No one can knock WACT, and what it's trying to do

[tele]

Thanks for the link to the PDF Selkirk - going to read it later

Keep up the good work, the more information available, the better. No one can knock WACT, and what it's trying to do

I don't think anyone was knocking WACT in anyway. In fact... just the opposite. Thanks for the interesting read Selkirk! I've gotten about halfway through this morning.

Matt

[Widow Maker]

Knock, Knock?

Wasn't really suggesting there was anyone knocking WACT, but just stateing the obvious I suppose

[lieut_data]

<h1>{$word}<h1>
<ul>
  <loop>
  <li>{$element}</li>
  </loop>
</ul>

<h1><?=$word><h1>
<ul>
  <foreach($list as $element):>
  <li><?=$element?></li>
  <? endforeach ?>
</ul>

<ul>
   <xsl:for-each select="list">
      <li><xsl:value-of select="element"/></li>
   </xsl:for-each>
</ul>

I'm really surprised how little focus is given to XSL-T. Considering it is a W3C Web Standard, has incredible templating functionality, and is a core component of PHP5, the debate should not be about 'pure' PHP vs. Templating Engines, but rather XSL-T vs. other Templating Engines.

[It is my humble opinion that HTML, as an specific subset of XML, should never be embedded in PHP.]

XSL-T boasts a declarative syntax, which has been shown to be easier to comprehend by non-programmers (don't ask me to quote this...). It supports all the common conditional operators and loop constructs, and, best-of-all, has a syntax defined by another web-standard, namely XML!

Every WYSIWYG editor I know of supports reading and parsing XML, some even with specific colour-coding for XSL-T.

I couldn't imagine having to switch from XSL-T to other templating engines -- believe me, I've tried. What was easy in XSL-T turned into a nightmare in Smarty (granted, smarty.php.net was down during that little project, but....) -- working with a deeply nested hierarchy of elements, some with optional attributes or child elements, and all with conveniently-named tags (i.e. <user>, <permission>, ...) proved to be a waste of time in Smarty.

Combined with MVC, XML & XSL-T give me the luxury of easily stitching together parts of other controller's outputs. I can't imagine a better solution.

Granted, PHP-4 w/ Sablotron can be a bit hairy... but it *does* work, and it will work even better w/ PHP. Also, while I don't exactly like it (since it locks one into PHP [which isn't a bad place to be]), PHP-5 has some interesting new additions that promise to make XSL-T w/ PHP even better.

[Widow Maker]

I'm really surprised how little focus is given to XSL-T.

[It is my humble opinion that HTML, as an specific subset of XML, should never be embedded in PHP.]

Though if I'm in a hurry to get something out ASAP I've seen me embed PHP iterator's within HTML, just to get something finished and out of the way.

Usually small projects and web sites - things that are not going to come back and haunt me later in regards to code re-use and/or expansion

Used Sablotron in the past, now I advocate the absolute use of PHPs DOM extension, which is stable from 4.3 but wouldn't go back to using Sablotron since it is slow

[lieut_data]

Though if I'm in a hurry to get something out ASAP I've seen me embed PHP iterator's within HTML, just to get something finished and out of the way.

Usually small projects and web sites - things that are not going to come back and haunt me later in regards to code re-use and/or expansion

Exactly! -- that's what makes PHP so versatile... to each his own, whenever he thinks it suits best. (Even though XSL-T is the *best* )

Used Sablotron in the past, now I advocate the absolute use of PHPs DOM extension, which is stable from 4.3 but wouldn't go back to using Sablotron since it is slow

Everything I've ever read indicated that DOM parsing of XSL-T was unstable in pre-PHP5... I presume you have had good success?

Sablotron was a must in one scenario where PHP could not be recompiled, but access to the sabcmd executables was permitted. Saved my butt it did!

[Widow Maker]

I presume you have had good success?

Yep, with PHP4.3.4. Really had some bother a while back with PHP4.2.3 though.

Glad the newer version I use is now stable enough so I can relax and just script, without having to hack a problem

Cannot wait to get my teeth into PHP5 myself, though I can see it being early next year before I settle into using it

[turboweb]

All i have to say is "Typo3"

The absolute best CMS, template and integration system around

[Betcour]

I couldn't imagine having to switch from XSL-T to other templating engines -- believe me, I've tried. What was easy in XSL-T turned into a nightmare in Smarty (granted, smarty.php.net was down during that little project, but....) -- working with a deeply nested hierarchy of elements, some with optional attributes or child elements, and all with conveniently-named tags (i.e. <user>, <permission>, ...) proved to be a waste of time in Smarty.

I'm usually a "anti-template" guy, but I also use XSLT stylesheets in a few places where it makes sense to me (usually having to render a set of data in HTML, without any processing done, such as producing HTML formatted emails or PDF documents)

However I wouldn't say it's easy. XSLT is a very clean and clever design, and it's rather simple most of the time. However for some situations, where a procedural structure is necessary, it's incredibly difficult to use. Some of my templates got so convoluted I can't understand them anymore

The beauty of XSLT is that it's totally standard - every scripting or compiled language out there knows how to handle it. And even on the client side modern browsers are also capable of doing the transformation themselves, without any server-side processing. Widespread standardisation is very good

[lieut_data]

However I wouldn't say it's easy. XSLT is a very clean and clever design, and it's rather simple most of the time. However for some situations, where a procedural structure is necessary, it's incredibly difficult to use. Some of my templates got so convoluted I can't understand them anymore

XSLT shines in places where other template engines wallow -- but it too has its drawbacks, especially, as you mentioned, proceduarally. Again, though it draws away from XSL-T's standardization, PHP5's ability to integrate functions into the XSL-T stylesheet may help to resolve these complexity issues.

Example: Date Formatting. I found a *great* XSL-T date formatter, but it was ~1000 lines, and in order to get the result I wanted, ended up having four nested <xsl:call-template/> tags. A handy call to date or even [fphp]sprintf[/php] could have simplified the stylesheet considerably. (something that is already made trivial by Smarty)

Of course, I could have passed a formatted date value to the sheet, but I wanted the template to have the formatting power, leaving the model to pass only the raw data.

[Theiggsta]

To be honest I am pretty proud of the WACT system. It is basically a system I had written myself using some hardcore regex, but it was definately not as feature rich as WACT is today. If you ever want to be friendly to designers, WACT is the way to go due to its conformance with standards.

Web template systems make more sense when you combine a controller and model together because your output eventually becomes something like XHTML which is decorated by CSS (if you have'nt moved to XHTML standards, you need to sometime this week... I reccomend it).

Just my advice before you fly off the handle with this whole templating system smacktalk.

[Widow Maker]

Would ask everyone reads the PDF that Selkirk posted the other day there

It's suggested that XSL-T isn't in fact, a template engine/language, which is true. But by it's own nature, it can render templates I suppose.

The reasoning why you shouldn't put for example date formatting into a template is also given in the document, alas there is 2 definitions of a template though

A good read none the less though

[lieut_data]

Would ask everyone reads the PDF that Selkirk posted the other day there

It's suggested that XSL-T isn't in fact, a template engine/language, which is true. But by it's own nature, it can render templates I suppose.

The reasoning why you shouldn't put for example date formatting into a template is also given in the document, alas there is 2 definitions of a template though

A good read none the less though

A quick search on SP revealed numerous articles posted by Selkirk in the past few days -- care to post a link?

Thanks!

[dagfinn]

It's suggested that XSL-T isn't in fact, a template engine/language, which is true. But by it's own nature, it can render templates I suppose.

In any case it's an open question how much practical importance you can attach to his formal definition of a template. But my experience with XSLT is it tends not to be inuitive Web designers. I had to work hard separating logic from presentation and putting each of them in separate stylesheets.

I agree that the paper is extremely interesting. It really helps clarify some issues. But I'm not sure I agree with him that the boundary between program code and template should be the same as the Model-View boundary in MVC. I'm more inclined to keep some view logic (but no HTML code) outside the template, but in separate classes so it's still separate from the Model and the Controller.