Software Development > SilverStripe: MVC and Template Engine

SilverStripe: MVC and Template Engine

Published: May 8, 2010

Having been handed a number of legacy systems built in SilverStripe, I've had an interesting introduction into this framework. I worked with several other frameworks in my time and I understand the desire of the frameworks to force developers down the DRY path. If you compare web development to golf, you could say frameworks make driving so easy... but you'll 5-put every time if you move away from the driving range. This is to say, frameworks (and SilverStripe in particular) offer a lot up front and the ability to make some big changes easily but sorting out the finer points can be near impossible.

SilverStripe has received a lot of good reviews over the web and has also won the odd award. Almost every review I've seen has given no insight into the code that lies beneath and only what things you can do out of the box. When you start looking deep down the rabbit hole you begin to see how shaky and shoddy the the SilverStripe foundations actually are.

SilverStripe's Templating EngineMVC is a fantastic concept but sometimes it can be over done or simply... badly done. When it comes to the 'V' in MVC for SilverStripe, you find yourself in the hands of SilverStripe's own templating engine: SSViewer. The idea behind SSViewer is that it gives you simple controls to handle your data... but no more than you need because that would kill the MVC design. The only problem is... they don't give you enough tools to even do some very basic things like use index variable as an argument in a control function. Or set a variable (temporary in nature). Or call a native php function. Or use the mod operator (%). Or even use greater-than or less-than in an if-comparison statement.

So, they seem to be control Nazi's to hold up this ideal. That's fine. The thing that get's my back up is that there nothing stopping people from putting plenty of view code (HTML and the like) straight in the model or controller. Which I am coming across constantly in the legacy code I've been handed.

So, SilverStripe is strict on one end but not on the other. Whatever. It's their design, right?

Speaking of which; it's extremely interesting to see the core developers ponder the development of this area of the framework.

Here is an excerpt from the CTO Sam Minnee requesting feedback from the core team (here's the full thread):

A number of people in the community have requested that we make the
templating language more powerful. My initial response to this has
been that we've deliberately kept the template language simple. We
want people to be able to download modules and be able to customise
the templates without knowing PHP.

However, perhaps it's time for a change. Restricting the template
language's syntax isn't the best way to ensure simple templates;
rigourous [sic] review would be of more benefit.

To move forward with this, I think we need to examine the kinds of
improvements that people thing would be warranted. We don't want to
build everything and the kitchen sink, but the template language would
probably benefit from the judicious inclusion of a few syntax

So - what do people think we should add?Some of team say it's fine and should stay the same. Others call to have it purely in php and let the dev's and designers sort it out. Others call to not reinvent the wheel and go with another fully featured templating engine like Smarty.

Sam Minnee fires this shot

Although we're open to the idea of letting people use another
templating language for work not hosted on our servers, we're not
going to move to Smarty, or another template language, for main
SilverStripe development in the foreseeable future.
But eventually concedes that perhaps a couple of templating engines should be researched and evaluated for inclusion into the framework.

This was 2007. It's now 2010, v2.4.0 has been released and SSViewer is still as restricted and useless as ever. There are no signs of another templating engine integrated into SilverStripe. We can only guess as to what came of it all but it looks like the gimped version is here to stay.

As a little side note; one has to wonder about the ideas of the CTO when he puts forward ideas like this for handling self closing tags in HTML and XHTML (like <br />) template pages (here's the full thread):

The "<br$SelfClose>" is my favourite, because
it's concise. It would only need to be written by template developers
that are wanting to build dual-format templates, which I would expect
is a group of people that are getting deep into SS, so the fact that
it's an odd syntax that people would need to learn is acceptable IMO.
In direct reply to Sam's suggestion Ingo Schommer, a senior developer for SilverStripe writes:
Hm, I don't like <br$SelfClose> - its a lot of overhead in quite common
elements (<img>, <br>). This addition means that every developer has to
know about it, and change the way they write HTML. It will clash with
IDE autocompletion, you won't be able to preview/copypaste even the
simplest markup snippets without running it through SSViewer first, etc.
I can pretty much guarantee that only the most hardout SS devs
will use this notation, which leaves us with invalid markup in certain
and people having to subclass fields just to change templates for
their context (HTML4 vs XHTML).
For me the first two letters of the reply say it all. "Hm". It's like.... Hm... how do I sugar coat this? Hm... how do I tell my boss he's got no clue what so ever? Hm... how do I tell my boss that no developer in their right mind would think <br$SelfClose> is acceptable syntax for a template.

It really makes you wonder.

Fortunately the idea was not pursed further.


1. Jildaz Beddiaf on May 9, 2010

Like your golf analogy at the beginning.

Didn't know you knew anything about golf.

Jildaz XXX

2. Ben on June 9, 2010

Thank you every informative. I have to admit the reason I dont use SilverStripe is because its templating has absolutely no control. I coudn't even use the

in a basic IF statement. Smarty all the way I say.

Any Comments?


SVN and Dreamweaver CS4 Integration

Published: June 30, 2009

Adobe Dreamweaver CS4 now comes with SVN integration. It's their one big feature for developers in this version. Too bad it's completely useless.

Solving TortoiseSVN, SVN+SSH, Putty and Plink Chaos

Published: December 8, 2008

Trouble shooting guide for setting up TortoiseSVN with the SVN+SSH scheme. Understanding Plink can help the diagnosis.