Revamped Template Parser for SilverStripe 3

Posted by Hamish Friedlander on 12 October 2011

SilverStripe has always had a pretty elegant template language (the language used to describe how data from the application should be inserted into a document - be that of a web page or anything else). It was simple to learn and kept the designer insulated from complicated back-end code.

Unfortunately the implementation of that language in earlier versions of SilverStripe lacked the same elegance. The code was a mess of regular expressions, which made it hard to read and even harder to extend. It had arbitrary limits on what parts of the language could be used where, it was impossible to extend except by editing the core files, and it had hooks into many other parts of the framework; breaking encapsulation and distributing responsibility in non-obvious ways.

There were good reasons for most of this, but the core reason for much of it was the lack of a good parser generator for PHP.

For the non-technical, a parser is a program that takes something in a particular language (in this case, the SilverStripe template language), and understands it - breaks it down into a structure a computer program can understand based on the rules of that language.

Although you can hand-write parsers you probably shouldn’t, especially for complicated document structures. They become hard to read and maintain - the exact problems we already had. Instead you use a parser generator. You describe how the language you want to parse looks and the parser generator creates the parser for that language automatically.

If this all sounds quite complicated, it is. The way you describe how a language looks for a parser generator is extremely technical. The parser generators themselves are complicated pieces of software. And, at least at the time we were looking, there weren’t any for PHP that were maintained and had a stable release, which would mean we’d have to write one ourselves. All of which explains why when the original SilverStripe template language was written, we didn’t use a parser, bypassing the issue entirely by using another method.

This changed when we started to work on SilverStripe 3. The initial core team sat down and built a list of what things we’d like to change in SilverStripe if we could, and top of the list was the template language. 

In the mean time, I’d been experimenting with a new type of parser generator, called PEG. Unlike traditional parser generators, this new type used concepts more familiar to software developers. It was also much easier to implement - so much easier that I had already gone from proof of concept to an almost complete solution during a previous project. As a result, pretty much the first task we did during SilverStripe 3 development was to prototype a SilverStripe template language parser using this new tool. While we were at it, we improved the language - made it more orthogonal (if something works, it should work the same in every situation), consistent, extensible, readable. We added support for “Up”, which gives the parent context - a long asked for feature.

The result is a much superior template language implementation. Although for basic usage there is no apparent change, under the hood is a complete swap. Advanced users will find much to like.

The ultimate validation for me came about three weeks later. There was an additional feature we wanted to add to the language (an improved syntax for internationalised text). Another SilverStripe developer Julian Seidenberg was able to add this feature with almost no help despite having no previous experience writing parsers, and without introducing any side effects - something that would have been considered so difficult that it would not have been attempted in the old engine. 

Now that the parser generator is in the SilverStripe Framework, there are many other opportunities to replace hand written parsers in the system, and it offers many possibilities for website developers too. Just some of the potentials: a fully standard compliant email address parser; a bbcode parser; improved introspection. 

If you’d like to check out the parser generator, it’s available on my personal github at https://github.com/hafriedlander/php-peg. Or you can see it in use in SilverStripe master - the main repository is at https://github.com/silverstripe/sapphire and the template parser itself can be viewed at https://github.com/silverstripe/sapphire/blob/master/view/SSTemplateParser.php.inc

Post your comment

Note: Comments are moderated and won't show until they are approved

Comments

  • @peter, I think you're missing the point a bit. SS 3.0 is a significant release for SilverStripe because it represents the official debut of the SilverStripe Framework, which puts them in the same arena as Symfony, CodeIgnitor, and all the other major players. We're no longer talking about just another CMS. This is a standalone PHP framework. But people ask all the time, "Why do we need yet another framework?"

    That question is difficult to answer unless you have a good a mount of differentiating factors in your framework, and SilverStripe has done a great job of offering something different than the others. I've used Twig, and I've used Doctrine, Propel, Smarty, etc., and those are all great tools in their own right, but honestly, there are a lot of things I'd change about them, and I much prefer the SilverStripe ORM to Doctrine and the SilverStripe templating syntax to Twig. No contest.

    The minute your framework becomes a hodgepodge of third party players all working together, you have much harder time answering that question. Why DO we need yet another framework?

    The PHP framework space is a very noisy room, and SilverStripe is doing a good job of making its voice heard by innovating alternatives to mainstream toolsets.

    Posted by Uncle Cheese, 2 years ago @unclecheese

  • I'll second the "why not Twig?", but for another reason (each to their own on the syntax): why the "Not Invented Here" syndrome endemic in CMS's in general, and Silverstripe in this instance?

    First a new template language (when there are a gazillion open source projects you could leverage), and then a new ORM (when there's a few dozen well-tested and maintained ones to choose from).

    As a product developer I understand "NIH" (if I write it I *know* it works, and I know exactly how it functions); but as an end-user I don't want to learn a 4th ORM or 6th template language. Seeing projects leverage code maintained by 3rd parties gives me a warm fuzzy feeling that this core library is rigorously tested and maintained (and less likely to have any unspotted security vulnerabilities) - and lowers the barrier of entry to a set of programmers in the community.

    I'd be very interested to hear your views, because as a business developing both of these from scratch will have made economic sense, so there's a hurdle I have missed to libraries being widely adopted.

    Posted by Peter Bowyer, 2 years ago @peterbowyer

  • @Dag - I assume you mean you dislike the language itself, and not the implementation? Each to his own I guess, but after a quick scan of the Twig page I much prefer the SilverStripe template language to Twig.

    Although we've never really been happy with the implementation of the SilverStripe template language, I've always felt like the language itself solved the problem space pretty well. I certainly don't agree that it's a "mess".

    Even if there was a template language that everyone agreed was significantly superior to the SilverStripe template language, there's a lot of difficulty integrating another template language with the SilverStripe framework - for example, most other template languages collect their variables push style, and SilverStripe is designed around a pull style collection.


    Posted by Hamish Friedlander, 2 years ago @hafriedlander

  • Why not just using something like Twig http://twig.sensiolabs.org/
    I really like Silverstripe but the template system is a mess (in my eyes)

    Posted by Dag, 2 years ago

  • It's so good,thank you.

    Posted by ysbearing, 2 years ago

  • This sounds really nice, i have been waiting for this. Just 2 days ago i was thinking if there was some place i could write to the dev team, if there was any plans to look at the template parsing. (Actually because of the up issue).
    I'm excited to see how this will work out - i have always hoped for something more like PHP Smarty - why reinvent the wheel?

    Posted by Thomas B. Nielsen, 2 years ago @nobrainerweb

  • Seems genuinely captivating. Could like to determine certain extra highly developed template usage.

    Posted by forexcasey, 2 years ago

  • is the best

    Posted by lindi nela gida, 3 years ago

  • Wauv, this sounds great. I've always loved the simple SS template language, but missed a lot of functions. Looking forward to give this a closer look.

    Posted by Joel Grøndrup, 3 years ago

  • I like very much the idea of using that new superior template language. it seems quite a challenge for me!

    Posted by Peter, 3 years ago

RSS feed for comments on this page | RSS feed for all comments

Want to know more about the company that brought you SilverStripe? Then check out SilverStripe.com

Comments on this website? Please give feedback.