Razor Engine CMS : A CMS built with .NET and Razor Engine
11.21.16
The web application I work on at work has a custom CMS for the front end where all of the HTML, CSS/LESS, and JavaScript development is done. The templating framework used for building pages in the app was created by a previous developer and is written in PostScript.
The syntax of the language is reverse Polish notation, which means things are backwards. For example, to add the numbers “one” and “two,” it would be “1 2 +,” since the language is stack oriented. As you can imagine, this is kind of a pain to work with and hard to get new people up-to-speed, so I started looking into the idea of bringing Razor into our CMS. After a quick Google search, I found the framework Razor Engine, and that got me started.
The app I work with uses MVC in parts, but is really more of a SPA (Single Page Application), so most of the pages either get data through a stored procedure call using the PostScript templating framework or using Ajax. To pass data to Razor Engine, I decided to make another page field for a custom model. In this page field / section, you can write C# with access to the RazorEngineCms.PageModelClasses Library, where there are classes for getting includes, as well as data through calling stored procedures. The result of this Page Model section is then assigned to an anonymous object variable called Model which is passed to Razor Engine. Below is a screen shot showing this process:
Inside the Page Template field, you have access to the Razor templating language for manipulating data from the model. Below is a screen shot of what this page would look like once it is compiled:
Another benefit of using Razor in the CMS is that, unless a page uses a query string
variable, the page can be pre-compiled with the compiled page stored in the database.
For pages that do use URL parameters, a Caching process is in place to cache the compiled
page for each permutation of possibilities. For example, the first time the page
/example/sproc-call/22 is loaded, it will be dynamically compiled, but after that
the page will be rendered from Cache.
Due to having to dynamically compile some of the pages, I came to the conclusion that in order for the CMS to be viable in a production environment there would have to be a background process to cleanup the temporary files created by both Razor Engine and dynamically compiling the model. For this reason, I decided that instead of trying to retro-fit Razor into our CMS, a better solution would be to work towards taking front end development out of the CMS and back into something like Visual Studio.
One of the main reasons for developing in a CMS is that we develop software for an international audience, so pages have to be loaded with different languages and cultural changes. In the current CMS, language resources and includes are database driven, but in the long run it would make more sense to bring things back into Visual Studio so resource files could be used. The downside of having database-driven language resources and includes is that for each include or phrase, a database call has to be made, which can result in some pages having around 100 separate database calls to load!
Overall, this was a fun project to work on, but I decided to put a fork in it as it was suffering from scope creep and I was tired of building a CMS.