In ASP.NET Core MVC (formerly MVC 6) there is a new area of functionality called View Components which appear to be a better alternative to Partial Views. I've seen the following View Component Example. But there doesn't seem much more information currently as to their usage.
I'm trying to evaluate if its worth using this pattern and if this can/(or is intended) to be used as a more baked in method to help with donut caching.
View components are definitively great and it's certainly an improvement. The one big improvement is that you can run asynchronous operations on view components where it wasn't possible with child actions.
More information available here:
Exciting Things About ASP.NET vNext Series: MVC View Components
For donut caching, there are two separate issues filed that you can comment/track: #1232 and #536
Currently there is available a brand new documentation from Microsoft:
View Components documentation.
In my opinion ViewComponents are very useful and flexible features. I like them, and I can recommend them.
However not always View Component is "a better alternative to Partial Views" - this will depend on your particular case.
I am still a beginner to MVC and I was trying to understand why developers seem to prefer Razor engine over WebForms engine in ASP.Net.
My question: Is it because Webforms engine is slower than Razor engine?
Personally, Webforms engine comes more easily to me because I have been coding in Webforms for the last 12 years.
Performance wise there should be no difference. The razor engine was developed to give a more concise syntax as explained in the question Does Razor syntax provide a compelling advantage in UI markup?. What will give you a performance boost is removing the unused view engines. For example if you use only razor, then in the Global.asax.cs file
// Remove view engines except razor
ViewEngines.Engines.Clear();
ViewEngines.Engines.Add(new RazorViewEngine());
I have an app with Knockout binded views. It loads all HTML upfront, to minimize requests to the server.
I want to introduce Durandal to the app. Is this scenario supported? If so how?
Can you give us some more information?
This scenario is possible, as there nothing which would prevent you from loading your own HTML and binding it with knockout.
You will, however, NOT be able to do this in a way that meets the standards and conventions of this framework.
If you have many html views, my suggestion would be to create a small program which converts these existing views and view-models into their Durandal analogues. It will save you loads of headaches later.
Creating a View
I do not understand why a developer would use Phalcon's Volt template engine.
In the end, after the compilation, the same PHP files are produced, that I would have to write manually in the first place. To me, it looks only to be detrimental to the performance.
Is the answer "so you could pass .volt files to a front-end guy"?
The answer lies in the development of your application. Why do you use a framework instead of pure PHP? Why bother with object oriented programming when procedural/straight PHP is faster?
There are many reasons of course and it is a long discussion. The summary is ease of use and maintainability.
The same goes with Volt. You can use the volt templates to do what it will take you a lot longer if creating plain phtml files (HTML with PHP tags in there). Examples I can give you are template inheritance, partials, calculations within the template (for/each loops) etc.
As far as performance is concerned, there is always a performance hit when using a template engine. Volt luckily is part of Phalcon so the performance hit is minimal since Phalcon does all the hard work in memory instead of using included files here and there to offer its functionality.
The decision is up to you. Volt, Smarty, Twig and others are there to help with development of your application. Your decision is what makes you use the template engine or not.
This is an old question, but I want add some insights.
You asked why you should use Volt, the Phalcon template engine, but in your explanation you want know, more generically, why you should use a template engine. The short answer to your question is: you must use a template engine to avoid mixing PHP with HTML.
But I want answer to the main question also. Why Volt? Volt overload is minimum compared to every other template engines out there and it's not because is written in C, but because it generates a unique PHP file for your view.
Twig is probably the most complete template engine out there. Twig has many more features compared to Volt, it's more stable and older. Twig, anyway, doesn't generate a unique PHP file, but a bunch of PHP classes with methods that call each others. Doesn't matter if you are using the Twig C Extension, Twig is gonna be slow anyway.
Twig is really really slow when compared to Volt and even to the good old Smarty. So, if you are using Phalcon is probably because you want achieve the best performances, serving a lot of page requests; in this case Volt is your friend.
When history of PHP starts, it was standard, that HTML was generated directly inside PHP scripts. But it happen to generate some problems when it grown to one of most popular ever web programming languages.
To keep people working in huge projects comfortable with their tasks ie. when developing web services, where was an MVC architectural pattern invented. M for Model is used to store data and handle them in a maintainable and repeatable manner. V for View as an part, that is responsible to generate proper output. C for Controller that are responsible for sending commands to models etc., being a core logic of application.
When user send a command to service, Controller is handling it and understanding. Triggering changes on proper Models and maybe forwarding actions to other Controllers as long as View Controller is reached. View controller takes a proper view, injects into it generated data and executes it to create output that is send back to user. If template for view is not yet generates, it triggers template engine to do it.
Proper implementation of full MVC greatly helps both programmers, system architects, front-end devs etc. But when on one side it happen difficult to maintain databases (so ORM were developed), on other side of system it was difficult to maintain views.
One of principles of MVC is that Logic (with huge "L") is only in controllers. So there is no logic in views. Using template engine enforces easiness of achieving that because of poor support of logic by them self. It is not a secret, that programmers are "lazy" - so if they have an occasion to put some more advanced logic into view, they would do it.
I guess that all frontend devs have programming skills. Problem is to make them stay with you. Working on huge project with lots of views (and so hudge templates) with PHP mixed into them will drive them crazy. It is much easier to read code written for template engine.
Idea of template engines is to add one more part to system, that offers possibly simple language allowing to use basic logic like loops and if statements. On one side template engine receives kind of a textual file to transform it into PHP file with mixed into it hyper dose of all important HTML.
If you are alone developer, it is important to nobody that you are using files that mixes PHP with HTML. It looks probably close to this:
<html>
<head>
<title><?=$title?></title>
<? foreach($metas as $meta) { ?>
<meta name="<?=$meta['name']?>" content="<?=$meta['content']?>"/>
<? } ?>
But any frontend developer would rather like to work on file looking this way:
<html>
<head>
<title>{{ title }}</title>
{% for meta in metas %}
<meta name="{{ meta.name }}" content="{{ meta.content }}" />
{% endfor %}
for it higher readability. It happens extremely handy when template includes some kind of javascript inlined. After all, you end up with same file you can create by hand, but this file is generated for you and stored, so it is no more generated as long, as core file is not changed. We are generating our templates during deploy what has 0 hit on performance, especially now, when Volt engine is written in C.
Another handy thing about template engines is that (with some your effort) it is possible to generate templates minified on the fly. You wont ever minify your hand-crafted template, except when planning to commit suicide.
So globally, it is a case of:
so you could pass .volt files to a front-end guy
but it is an effect of working in MVC pattern. And Phalcon is made to fulfill MVC principles. I'm not even trying to guess, how you managed to work with this piece of software for ~2.5 years not using template engine. Maybe you are working alone.
Every person has different taste, but i tell you my vision.
I think volt is useful because:
As all phalcon framework, Volt has excelent performance.
Benefits from template engines (i dont wanna repeat that already other answers says)
Hierarchical rendering: More info -> https://docs.phalconphp.com/en/3.0.2/reference/views.html#hierarchical-rendering
I love the phalcon hierarchical rendering, because is clean, easy, and any person can understand where can find the view of something, ideal for a designer, or other non technical person
And to add value, i modify some phalcon parts to apply that hierarchical rendering using app modules, thats all i need.
As an exercise, I intend to replace all front-facing aspects of my Rails application with Backbone.js. Part of the plan includes redesigning everything right down to the CSS.
The issue I'm struggling with is in delegating responsibility for templates and views.
Is there any benefit to implementing the new front-end entirely in Backbone, hence only using Rails as an API?
How do I strike the right balance between Rails and Backbone when it comes to handling the HTML elements of the application?
Since it seems that nobody is going to post an answer to this I'll offer my two cents as just one point of view (I've written elsewhere about the issue of how to get rails and backbone.js to work well together: rails and backbone working together).
Most people in this situation will tend to drop the rails views altogether and migrate everything to backbone.js.
This is what I've done in a project that I'm working on right now.
This is the natural course of events, and particularly once you start getting used to all the complex interesting things you can do with backbone.js and structured javascript, it becomes difficult to turn back and implement standard stateless HTML pages.
As I mentioned in my other answer linked to above; however, there are costs to completely abandoning HTML views and the stateless layer. In my case, I intend to add back pure HTML pages for non-js-enabled browsers for GET requests only once the app has reached a certain level of functionality. We won't support POST or PUT requests unless the user has javascript enabled (or unless they want to go through the JSON API).
That's the balance I've struck: stateless HTML (no-JS) for accessing data, but JS required for posting/changing data. Your choice will vary depending on your use case and target user.
The other thing that I would mention is that if you have been working with rails HTML views on a project for some time, you might be unprepared for the initial overhead required to switch to backbone.js. This is not simply swapping HAML for ERB: you are migrating from a stateless front-end to a stateful one, and that is a potentially huge change (depending on the complexity of the app). I myself was a bit unprepared for the depth of that change, and had to do a lot of catching up before getting our app back on track after making the switch. And we made the switch very early, with minimal functionality already in-place.
Anyway just a few thoughts, hope they help.