Silverstripe: as a platform

At Xebidy we use Silverstripe almost exclusively as a platform to build upon. Not just Bootstrap (our custom extensions) but also the Sapphire framework to build the more advanced parts of the website we build. The Sapphire framework is at the most basic level an MVC framework for PHP5 with a number of additions to service the Silverstripe CMS. I’m writing here a breakdown of what I see as strengths and weaknesses of the platform. Before you read on please take these 2 points into consideration, I really do like working with it and I have a lot of time invested into the platform and this is my opinion and not that of my employer.

I would love to hear everyone’s opinion on this so drop me an email or leave a comment.

  1. Abstraction of layers

    Over the past few releases there has been talk on the Silverstripe forums, their trac and the mailing list of trying to move the CMS code away from the core of the MVC framework so normal non-CMS based applications don’t need to rely on it. While it is a little frustrating currently over the past couple of releases this has progressively gotten better and I believe that this can be achieved in the near future. The specific example of this is ContentController which I would suggest should be refactored out into a SiteTree_Controller and ContentController.

  2. Extensions/Decorators

    This is probably what I love the most about this platform and I think the guys over at Silverstripe should be applauded for this. They have built an awesome framework wherein each Class can be extended quite simply. The beauty of this is in it’s simplicity for the developer and it really allows for extensible applications to be built. It definitely has a few bugs in it which can be quite tricky to track down but generally it behaves exactly how you expect it to. My biggest suggestion for Silverstripe is to push this as a strength of the platform because it really is very cool and extremely functional.

  3. Template Engine

    Most people that are new to the the platform are opposed to Silverstripe having it’s own templating system. It definitely has it’s pros and cons. Firstly it is not a fully blown parser, relying on a number of regexes to parse it’s syntax. I run into this problem quite regularly and end up nesting control blocks or creating methods on objects that in my opinion should be handled in the presentation layer. The second problem I have with it is it’s lack of a context stack – this means you can’t access something in the previous nested control block or even access a variable (not really variables) in the “global” context.

    Don’t get me wrong, it’s not all bad and I don’t believe that there is anything in this that can’t be fixed (I started writing a new parser for it quite some time ago). On the flip-side the way the templating engine matches the Model of the application is a really elegant solution and I don’t believe the template engine should be removed. A cool but definitely complex improvement for this would be to make it more pluggable and allow extensions to expand the language.

  4. Documentation

    Generally the documentation on the project is very good. I think it could be improved with some more articles about the lower levels of the framework and have them highlighted on the blog rather than the rather boring marketing that is currently posted on it. Similarly the PHPDoc documentation on the framework is generally awesome and really helps with the code completion within Eclipse but this can definitely be taken from good to excellent by having protected and public variables types being documented. (As an aside I would love a way to document all the magic variables that are created by Framworks such as this.)

  5. Communication

    The Silverstripe project is coming from a different position than many open source projects in that it was released as open source and that company continues to drive the majority of the development. This is great and I definitely appreciate it. Many of the decisions made about the framework and it’s directions are made behind closed doors. This prevents any buy in from external developers. A great example of this was recently a decision was clearly made by the Silverstripe guys and then presented to the dev list for ‘opinions’. This work has been going on quietly on 2 branches with nary a word on how the progress is going. Similarly the 2.2.2 release has recently been completed and in the lead-up there was very little communication regarding the plans and goals of the release.

Content and Data Management Systems

This is a bit of a brain dump about something that’s been bugging me for weeks, it doesn’t have a great deal of coherence to the idea yet.

I’ve been working for the last few months on the excellent Silverstripe CMS and the framework Xebidy has developed on top of it called Bootstrap. We are releasing the source of Bootstrap (not soon enough) and plan to support it as a plugin or alternative input system for Silverstripe. Anyway, the point is these systems are really based on pure content management systems – every piece of data entered into the system is purely for displaying on the page. Everything is written expressly for the webpage and rarely will be used for any other purpose. This is what most people expect they are getting when you tell them they are getting a CMS, I’m not sure it’s the best way to run a content heavy website.

What I’m suggesting is to move to a more data centric management system. Rather than creating pages and putting information on the page about a product, we should create a product in the system and let the webpage display that in a properly formatted page. This way, things such as product reviews, tags and comments are attached to the product itself, rather than to the page. Now, let me say I’m aware that a lot of websites are built in this manner, (I’ve worked on them before) however it isn’t a viable option on a smaller level.

There are a few reasons for this, firstly building the site around the companies products can be a very difficult process, first of all the designer/architect needs to have quite an intimate knowledge of how each product relates to each other and the company which can take a great deal of effort, time and money. Secondly, this approach can be limited in flexibility, obviously adding new products shouldn’t be a problem, but what happens if there is a new class of product or the company moves into selling services. The website will not necessarily have been designed with these things in mind and then the database will need to be adapted to the new structure.

I think to solve these problems, a new type of CMS needs to be designed (or an existing one adapted) which lets the web manager develop and adapt the database for themselves. I’m not quite sure how that would work, but it could leverage some of the existing web apis (GData & Pipes for example) to pull together the data.