As you might have heard, you have to migrate to Razor sooner than later, and the earlier you start, the more you will be creating future-compatible material today. This is part 2 of the Series The Future of DNN Speaks Razor I would like to delve into WebAPI, why It's awesome (especially for Apps) and why JSON-data is the future - especially combined with AngularJS or similar frameworks.
The Future of Web Apps is JSON, AngularJS and More
Think about the "cool" UIs you see today, like a powerful mail client (Google, Outlook), a neat game, a stylish business UI. All of them have in common, that the entire View is client rendered typically using AngularJS, knockoutJS or Kendo.
From what I can tell, this trend is unstoppable. Meaning: in a very short time, there will be loads of people that master these tools/technologies and will produce awesome web-apps and SPA-solutions - making others want to do the same. This causes a self-reinforcing loop practically eliminating all alternatives. I'm convinced that for such applications, all server-attempts to do the same will simply fail.
The Server Is Becoming What it Used To Be: A Data Backend.
But it does leave some very important jobs for the server to perform - and the better the server is at these jobs, the more successful the platform. Thank God & Gates that Microsoft figured this out just in time - and introduced ASP.net WebAPI.
I Love ASP.net WebAPI…
Probably the best thing since WebForms (or for the more progressive: since MVC) is WebAPI. And yes: it's part of MVC, but you must admit that it has nothing to do with the view generation. It's a very simple technology (embracing current web architectures) to degrade the function of the web server to simply exchange data! That's right: no focus on "we create the best HTML" or anything like that. Simply data input and output through JSON.
For web applications and SPAs (Single Page Applications) it's the way to go. When you have custom data (say a list of users) for your application to manage, the way today is to create an SPA, some interfaces and voila! The choice of server is not important for such an application - because everything happens in the client.
The Ideal solution for Admin-UIs and Data Consumption
Data consumption has a similar need: fast, quick working with data. Here's a screenshot of a help-application we created on DNN/Evoq for Ricardo using knockoutJS early 2012:
Later we choose to focus on AngularJS - here a simple responsive References-App based on Angular:
The question knockoutJS vs. AngularJS is a great discussion for another post (anybody?) but spoiler alert: AngularJS wins.
…but WebAPI is not ideal for Content Presentation…
Ok, I'm getting ahead of myself. ASP.net WebAPI is great for data input/output. It's main strength is that I can give it a typed object (anonymously typed is also ok) and it will take care of the interface to HTTP/JSON etc. in both ways (in and out)
That's perfect for applications.
It's great for searching and list-filtering.
It's not very helpful for normal content.
It's terrible for SEO.
Data input/output is mainly relevant for management-applications and for application-style consumption (searches, lists, details).
But normal web content is 1% editing, sometimes data-consumption (list, search, filter) and between 70 and 95% content presentation & consumption. Content-consumption is usually focused on visually appealing content like a page showing the team of a company. This kind of content is usually highly customized for every customer and page page - and must be HTML-based for search engines. Not exactly your data input/output scenario…
…for which we need Razor!
In general, a piece of original content which should look good, be responsive and unique is usually placed on a specific page by an editor, edited there (and only there). It must be delivered as HTML - in pre-designed templates.
…because then I'll continue with some getting-started helps posts :)
With love from Switzerland
">The Future of DNN Speaks Razor. In this post I'll explain what Razor is, why it's not MVC (even though Razor is popular there as well) and more.
A first example of some code
The following screenshot shows a simple Razor template creating a list of questions with hidden answers. It's a part of the FAQ App I created last week:
Now just so you understand it a bit better I've added some color coding showing some features of Razor:
- Orange shows a .net using statement - you can integrate any kind of .net library
- Yellow shows standard placeholders - inserting any kind of variable directly inline
- Blue shows the same thing as yellow, but inserting it as raw HTML (the default insert will escape HTML)
- Green shows a loop
So What in the Gillette is Razor?
- Razor is a text-templating system based using .net placeholders and allows you to write .net code into the template.
The classic use case is writing code like:
which would then be replaced at run time with
The Future Speaks Razor
A Razor inline placeholder can be much more complex and contain .net code like:
@((1+1==2) ? "it's true" : "it's not true")
And Razor can also contain code blocks, which can again contain HTML like this:
var x = 1;
var y = x + 2;
if(y > x)
- It's not limited to HTML and can also be used for any kind of text output. We often use Razor to template our e-mails, because it allows us to write very custom, complex output code outside our main line of code, just to create this e-mail. It also allows us to easily use different highly complex, smart e-mail templates for various purposes.
A More Complex Example
The following screenshot shows a Razor-Template
I've marked the segments with colored bars on the side. The picture shows
- Blue: A @functions block containing functions and variables needed by the entire view
- Green: two different segments, each with a loop. All very simple and easy to read
- Orange: a bit of code bridging some data to client side JS - like handing over a module-ID. This was all so much more complex with Webforms.
So What is a Razor good for?
And What is it not Good for?
Technically, you could do everything in Razor, just like you could also create lemonade using a hammer and lots of lemons. But it's not the ideal use case. Razor is not ideal for generating binary data, for developing a data- or business layer. It's also not ideal for processing user input. And even though you could retrieve data in Razor (very easy, thanks to .net) you would typically not do it because of SoC (Separation of Concerns). Instead, data access should be in a separate code area containing all business and data logic.
Razor is NOT the same thing as ASP.net MVC
No. Razor is a view/templating-engine to combine data with a text-template and return a text-string. MVC uses it by default as the "V"-layer im MVC, but you could use MVC without Razor, and you can use Razor without MVC. The standard example is ASP.net WebPages - which are basically just some Razor-pages.
Does Razor work with ASP.net Forms
Yes, it works very well inside and within ASP.net Forms. But it's very different - when you start using Razor, you are usually reminded of the good-old classic ASP days, before the it became aspX, because it's just HTML with placeholders. What's "missing" is the event-attachment, code-behind, view-state, post-back and a few other things. These are features that software developers usually like, but web designers hate.
Does Razor work with DNN?
It works perfectly well with and within DNN! In a following post I'll write how to get started. For the impatient, try the DNN-Razor Host Module and watch this video or try packaged code apps by installing 2sxc and some of the Razor Apps like the Razor Basic Tutorials, List-Tutorials or the SQL and Peta-Poco Tutorials.
With love from Switzerland