Member Avatar for RonaldDuncan

We are looking at rewriting our current content management system so that it works with the most popular/easiest to use/best templating system.

Our current system is to generate XML and then use XSLT to transform the XML to html, so the current templates are XSLT. The feedback we have had from designers is that XSLT is a horrible language, and we have to agree :). Though it does have some benefits like being executed by most browsers.

Unfortunately the browsers are not supporting XSLT 2.0, along with frameworks like dotNet.

Please let me know your favourite templating systems and why they are better or worse than others.

RonaldDuncan

  • 4 Contributors
  • 7 Replies
  • 102 Views
  • 1 Week Discussion Span
  • Latest Post Latest Post by RonaldDuncan

Dani AI

Generated

This thread raises two separate choices that need to be split before picking an engine: (1) keep an XML/XSLT-based pipeline, or (2) move to a language-specific template engine that designers find easier. Comments from , and show the tradeoffs: designer comfort, team language, and runtime scale are the real drivers.

Use a short checklist to decide:

  • Team and ecosystem: pick an engine that matches the server language your engineers want to support.
  • Designer ergonomics: logic-less or minimal logic templates are easier for visual designers.
  • Safety and tooling: auto-escaping, linters, editor/IDE support, and preview tooling matter.
  • Performance: precompilation, fragment caching and CDN/edge composition are essential at large scale.
  • Data shape: if your CMS produces XML, decide whether to keep XML as the canonical payload or convert to JSON/objects.

Practical mappings (with docs):

  • Designer-focused, logic-less: Mustache/Handlebars (simple, safe) Mustache.
  • Full-featured, template inheritance and macros: Twig (PHP) or Jinja2 (Python) — both give designers reuse and clean layouts Twig Jinja2.
  • If keeping an XML pipeline, keep it server-side with a modern XSLT processor rather than forcing browser transforms; a widely used server engine is available from Saxonica Saxonica.

A short migration plan:

  1. Prototype a single page with candidate engine and a designer preview that feeds realistic sample data.
  2. Add auto-escaping and template linting rules early.
  3. Precompile and benchmark templates; introduce fragment caching for common blocks.
  4. Migrate iteratively: convert safe, static includes first; then move pages with business logic.

These steps let designers work comfortably while keeping performance and security predictable.

Recommended Answers

All 7 Replies

Member Avatar for Airshow

Ronald,

Agreed, XSLT is pretty unfriendly. I go there as little as possible.

This is a good review is php templates:
http://codeutopia.net/blog/2007/11/05/different-php-template-engines/

Smarty seems to be everybody's benchmark.

Would require a major shift to server-side of course, but maybe a move worth making.

Personally, my favourite is the phpBB template class - largely because I have used it a lot and know my round it.

Airshow

Member Avatar for RonaldDuncan

One of our team wrote a gossip site in smarty, and liked the templating system.

We have also tried Mako, and the person with smarty experience thought it was better. However, it means moving over to python, which has advantages and disadvantages.

Member Avatar for MidiMagic

The best template system is none.

Member Avatar for RonaldDuncan

The best template system is none.

We already support that, it is making it easy to people to write websites with the common navigation, adds and other bits easily included that we want to provide in a better way for designers to interact with our system.

Member Avatar for !!underlink!!

smarty for the reason that they are very popular and we are afterall sheep

Member Avatar for Airshow

Ronald,

Don't dismiss Servere Side Includes (SSI).

OK, it's not proper templating by itself but it's great for throwing common, static chunks into as many web pages as you want.

At one time, I worked on someone else's overcomplex JSP site, Enterprise Beans the full thing, when SSI would have done the job. They couldn't see it!

Something I have yet to see (I must experiment one day) is SSI in conjunction with something that updates the includes with dynamic content when available. Would be good for server-side asynchronous update (not Ajax - that's a client-side UI technique).

Airshow

Member Avatar for RonaldDuncan

Ronald,
Don't dismiss Servere Side Includes (SSI).
Airshow

The old solutions are often the best. SSI was superseded by frames, which then got junked because the search engines did not rank them and now we have moved on from table to div's. But for showing blocks of nav content SSI does this great. I have not played with them for over 10 years.

I will also have to have a think about how we could pull together a site with SSI.

One of our issues is that we have close to 1 million users to we compress all our content to reduce bandwidth when serving content, and I think with SSI we would need to do that on the fly rather than pre-compressing all the static content.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.