Why are all my Dynamicweb templates all of a sudden renamed to “.cshtml”?

Dynamicweb CMS has almost always been using it’s very own templating system. Almost always means that in the beginning there wasn’t any templates, and instead you had to use a central Stylesheet to insert logo, change colors, and so on.

This templating system has worked quite well for a very long time, and the reason for this is that it is pretty easy for most people – including customers – to change the content of these templates. The templates are just very simple HTML-snippets mixed with different Dynamicweb tags that contain the content coming from Dynamicweb CMS. However, there are a lot of different drawbacks with the old templates – especially in terms of developers trying to do more advanced stuff. This originally lead Dynamicweb to create the XSLT-template which allows the developers to do some manipulation to the template based on different content. In Bleau we also used this approach, and we were pretty happy with it – but I don’t think it really took off with other Dynamicweb CMS partners because it is also a bit more complicated, and it really requires a developer.

Now, Dynamicweb introduces Microsoft Razor to complement the existing old templates and the XSLT – and by the way, the old Stylesheet is still there. Confused? šŸ™‚

Razor is a relatively new technology from Microsoft, and it essentially allows you to execute C# or VB.net inside a normal HTML-template. This allows the developer to create really powerful templates containing rich functionality – which can be both good and bad. Let’s try summing up some of the good stuff:

Better performance
The old Dynamicweb templates need to be parsed through a central Dynamicweb “parsing” engine which matches the template tags inside the template with the content from Dynamicweb. The new Razor-templates do not need this, and therefore the new templates provides the end-user with a better performance.

Easier for existing Microsoft-developers to learn and reuse knowledge
New developers are sometimes having a hard time grasping Dynamicweb – mostly because that there a lot of different ways to display content and there a lot of different Dynamicweb-specific tags and methods that you can use. As an example, Dynamicweb has developed its very own if/then-construct and also its very own loops. Which pretty much sucks if you’re a developer trying to learn Dynamicweb CMS, and you would rather just reuse your existing knowledge instead of learning new concepts that are only applicable to this particular CMS. In my view, this is one of the most important reasons for introducing Razor – you suddenly get access to a vast pool of developers who would rather work with Microsoft-technologies than Dynamicweb-technologies.

One of the other benefits in relation to this is that developers gain Visual Studio Intellisense support.

Easier to create custom functionality
There are a lot of ways that a developer can inject custom functionality into Dynamicweb. You can do all sorts of stuff with Dynamicweb, and the CMS is in no way a closed CMS. However, you need a backend developer to do this.
Because of the ability of executing code inside Razor-templates it all of a sudden becomes easy to create custom functionality. You just add the code right there inside the template.

Razor is part of the future Dynamicweb CMS
The new Razor-engine is only the first part of a new future Dynamicweb CMS. The upcoming generations will see a tight integration between items, ASP.net MVC, Web API and front end technologies like AngularJS. You will experience a completely different way of building websites with Dynamicweb CMS that will be much more powerful and flexible than currently.

So these are some of the positive aspects of adding Razor-templates to Dynamicweb. There must also be some drawbacks…

Easier to create custom functionality – part 2
Well, a good thing can also be a very bad thing. Unskilled developers can really create a mess for themselves. You can do EVERYTHING inside these templates – which could potentially create a lot of work for the Dynamicweb support.

More difficult for customers to quickly change a template
Customers used to work with templates will suddenly find it a bit more intimidating. Meaning that it will still be possible, but some customers might find it scary that all of a sudden there is code inside their templates. And so the risk of customers f….. up a template increases.

However, this could also be a good thing – customers quickly changing stuff inside a template can certainly also be a direct route to errors.

A mess of HTML and C#
In the ‘old’ days you would try to separate presentation from logic. And you should still do this as much as possible. Our advice is still to create backend modules for business logic, and then only use Razor for modifying the output from Dynamicweb. However, because you can do EVERYTHING inside Razor there will be developers (not Bleau-developers!) that will be tempted to do EVERYTHING. Which could create a mess of HTML and C#, and thereby making it even tougher to support, debug and administer.

A mess of different Dynamicweb-methodologies
The new Razor-templates open up a new way of doing front end development inside Dynamicweb – next to all the other existing possibilities šŸ™‚ This can also really create a mess of template-archive consisting of normal Dynamicweb-/HTML-templates, XSLT-templates, Razor-templates, and then some settings inside the Management Center, and so on. Dynamicweb still needs to cater for existing solutions, and I certainly understand this fact. However, the result can potentially become a mess – especially if the implementation partner doesn’t understand this.

So what are the consequences of all this? Well, as a customer implementing a Dynamicweb-project, you shouldn’t try to understand Razor, but you should make some requirements to your implementation partner. In Bleau we try to strive to the following:

1. Use Razor as much as possible – it will increase performance. Also if you don’t have any advanced stuff going on, but just want to present ‘normal’ content
2. Drop methods that do the same thing. You can use XSLT to accomplish the same stuff as you can in Razor. So that’s why you should only use one of these methods (Razor).
3. Only use Razor to modify output from Dynamicweb in order to present content to the user – more advanced stuff still goes into backend modules

In Bleau, we will start adapting Razor-templates as much as possible. We look forward to all of the new improvements that will happen inside these templates, and we think that it will benefit the developer community as well as the solutions created for customers.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s