Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is there consensus on a view engine for Nancy?

Tags:

nancy

I was a little startled to learn that Nancy has its own razor implementation, that may or may not behave like razor. In practice, does this cause issues? What are "most people" using for a Nancy view engine? Why was the real razor not used?

like image 498
bbsimonbb Avatar asked Feb 24 '16 11:02

bbsimonbb


2 Answers

First the easy answer. The Razor engine is, by far, the most downloaded view engine available for Nancy https://www.nuget.org/packages?q=nancy.viewengines

Now for the more complicated questions

Why was the real razor not used?

Because the "real" (and by real I'm going to assume that you mean the one used by the ASP.NET stack) Razor engine is tied to the HTTP abstractions that are built into the ASP.NET stack (HttpContext and all its friends) so there is no straight forward way to use it with Nancy.

The slightly longer answer for this is that you have to understand that Razor is really a parser and a Razor view engine is what sits in the middle of the consumer and the parser.

Nancy uses the Razor parser but we have to have our own view engine because that's what enabled Nancy to parse and execute Razor templates.

Now, it does get even more complicated. Many of the features you see in the ASP.NET Razor view engines, such as master pages, partials, various helpers, _ViewStart and so on, are not Razor (the parser) features, but they are an additional feature set that have been built into the view engine (you can almost think of it as middleware).

This means that for our engine we've had to re-implement much of these features because that's what's come to be expected from a Razor view engine.

I would like to point out that, if it was possible, then we would love to ditch our own implementation and use the one built by Microsoft (less code for us to maintain and it would mean we'd support 100% the same feature set), but unfortunately that's not our decision to make.. we can't take a dependency on their abstractions I am afraid

Hope this clears things up

/A

like image 63
TheCodeJunkie Avatar answered Nov 18 '22 20:11

TheCodeJunkie


We have been using the Razor implementation from Nancy for a while now. We have run into a couple of issues that are making us either switch to SSVE or abandon Nancy (we do really love Nancy).

The first issue with Razor is you cannot precompile views like you can in MVC which leads to much longer startup times. We have had many complaints about this.

The second issue is there seems to be a long-standing bug in the Razor implementation with Nancy which causes a situation that is only resolved by recycling the application pool. I'm not an expert but it seems when the project is loaded there is a temporary DLL being compiled and generated at that time (this explains the slower load times) but sometimes there a problem which leaves to the instance not being able to be created. It seems to be at this location: https://github.com/NancyFx/Nancy/blob/master/src/Nancy.ViewEngines.Razor/RazorViewEngine.cs#L238. Basically "viewAssembly.GetType("RazorOutput.RazorView")" is NULL at various times which causes only an error message to be displayed on every page, for every user, at all times and the only way to fix it is to reload the application (recycle the application pool)

Just my two cents and I know this post is older but maybe others will see some of the problems we have run into. I've opened a GitHub issue but the bug is hard to reproduce for us and it hasn't gone anywhere.

like image 39
Jacob Avatar answered Nov 18 '22 20:11

Jacob