The new pitch

After 5 years of DOMtempl'ing away, I've came to some interesting conclusions and acquired some observations.

I think I really undersold the 'data map' and the default values aspect of the system. So I came up with a new pitch, presented on a main page of this site, which reads more like this:

<ul>
    <li data-each="menu">
        <a href="index.html" data-attr-href="url" data-var="title">Click me</a>
    </li>
</ul>

I think it is as compact as possible for a meaningful DOMtempl representation, and it demonstrates many key features at once:

• You have default values for things, and even default arrays, if you want to. With little trickery, you can put those defaults into good use in your code.
• On the other hand, you don't need to actually assign any values to a template to get a working result. It will always work.
• If you do want to reset the template it's a matter of discarding those defaults (you can also be granular here).
• The template is actually a valid HTML file with no alien insertions (save from data-* DOMtempl attributes).
• The template is thus viewable/editable with regular developer tools, right in the UA if desired.
• Template authors can prepare 'data maps' for developers to fill out in their controllers.
• Those maps are actually pretty useful if only as reflection of the template. You can objectively tell what it expects to receive, without even opening it.

Personally, since I switched to this method, I've never looked back, and will only consider XSLT as a viable alternative. String-based templating for XML/HTML is dead to me. You'll be the same too.

Problems

That is not to say, DOMtempl in particular, or DOM-based templating as a whole is not without it's problems.

In my original Manifesto I outlined 3 problems with DOMtempl:

• Templates can get rather big, whole template is parsed each time
• You can't include templates into each other
• You can't alter text elements, only HTML elements are alterable

Those all turned out to be true to some extent, although in surprising ways.

First of all, I'm happy to report, that the performance was the least of my concerns. After some minor bug fixes/tweaks the algorithm proved to be very fast and not memory-hungry. Even large templates do not show up on the profiler, when things like database access are in play.

Still being paranoid, I wrote a DOMtempl-to-phpsoup compiler, which could auto-magically create .php on the fly, and even retain some of the DOMtempl's features, like default values.

I never had a real need to use it.

The other "problem" -- the ability to mix and match templates from pieces, was far more annoying. Note: that only becomes an issue when you start reusing templates across many projects, and need to conditionally include this and that. Currently, I simply cat many html file into one large html file, and make helps here tremendously. Not your cutting edge system, but pretty robust.

I've been also hit by almost every limitation I imposed on DOMtempl. For example, the lack of 'data-when-not' becomes painful in some instances, and the inability to climb the data tree "up" (construct paths like "../../name") was also weird at times. I appreciated the discipline, though.

Same thing with the VALID HTML rule. All DOMtempl templates are valid HTML, by definition. Sounds great, right? Well, I've been given templates that are beyond invalid to be then used with DOMtempl. I couldn't even start testing until I'd fix all the validator warnings. Painful? Yes. Time-wasting? Yes. End result: 100% valid HTML, at all times, without maintaining/linting it ever since.

So, I will not lie. You'll waste more time in some areas, you "normally" wouldn't. You'll also benefit from this time-wasting, and you'll also save time in other areas.

If you've never used DOM-based templating before, I guarantee, that you'll rethink some things. If you did, DOMtempl will likely feel very comfortable.