Is it possible to use multiple view engines? I have a large(ish) site that is already using the webforms view engine, but we would like to move to spark for new features.
Is this supported? any documentation online that details how to do this?
I use Spark and default view engine. There is not much to do. You have to register SparkViewFactory by calling ViewEngines.Engines.Add() and Spark will handle *.spark files and default view engine (WebFormViewEngine) will handle old views. Just don't remove webforms engine from ViewEngines.Engines list.
That's what I did; I installed Spark and did couple of views. Eventually I ended up with all views being .spark; no WebForms in the project. I think you can even use partials of one engine from different engine using RenderPartial (though I'm not sure); and of course RenderAction will work with any combination.
The process is very simple as described by LukLed; I just second his answer here so that you have more "success story" cases.
The only problem that you may find is that master pages are not compatible; you'll have to keep them in sync. You can find a question about this here.
Related
I didn't see anyone talking about this. What I have is login logic that's common to three projects. I have my model in one project (shared).
Can I have the controller and views in another shared project? I just don't want to have to duplicate things in each.
Also interested in any other ideas people may have to solve this problem.
Robert
Take a look at Precompiled Razor Views
Well, when it comes down to loading views, you can implement your own ViewEngine and instruct it to load your view from wherever you want (database, dll, ...). I just saw a nice video from TechEd NA yesterday, where the creator of the spark view engine shows how to implement it. In your case, you can just fetch the view and feed it into the razor view engine. You should have no problems, since razor was designed to be flexible, and you can easily spawn your own instance of the engine to have it render your loaded view.
I am trying to learn ASP.NET MVC by porting my current app written in ASP.NET Webforms to MVC. For starters, I am planning to use the Default View Engine (WebFormsViewEngine) as most tutorials/examples and the book I have use that as the default.
However, I know for sure that I do not want to use WebformViewEngine in the future and once I have a grasp of MVC, I would like to switch to a different ViewEngine (Spark seems to be interesting)
Would this be a simple change or would it take a lot of effort in terms of coding new views? What I basically want to know is which would involve more effort? Learning an alternate ViewEngine now or switching later?
OK - firstly you've got a decent sized investment in WebForms I'm assuming, and by virtue of that, you'll have a fair amount of user controls on existing forms etc. I'm sure you already know that this in itself is going to be the most work in the process, and has nothing to do with which view engine you choose because even the WebForms MVC view engine doesn't support user controls directly. This part of the work will still need to be done regardless...
Secondly, you probably are looking for a view engine that can take most of your other view built in logic and code (i.e not user controls), and by that I mean the stuff between the bee-stings ( <%= blah %> ).
Obviously the WebForms view engine does support this same syntax, but you also say that you specifically don't want to use the default WebForms view engine. Well you'll be happy to know that Spark also supports the <%= blah %> syntax, and this has been done specifically to support migrations like this.
Your best bet before deciding would be to watch this recent video here, and see how Louis goes through the simple WebForms-based MVC solution and it keeps running correctly even though the code still contains <%= blah %> syntax.
This support makes it much easier to transition and when you're ready you can then start moving your code to the more recommended way of using ${blah} syntax instead. But this can be done at your own pace whilst the overall functionality still works.
Hope that helps,
All the best,
Rob G
Looks like you can have a mixed bag of view engines in your application... link
Also check out this post from Phil Haack that shows using partials using different view engines to render on the same page.
This would allow you to simply switch over to the new syntax and not need to rewrite all of your existing views.
It should be as simple as calling
SparkEngineStarter.RegisterViewEngine(ViewEngines.Engines);
SparkEngineStarter should be a class in the Mvc part of Spark.
The documentation of spark is actually pretty good. Check out the section on getting it to run in ASP.NET MVC
I am really missing heavily the ability to test Views independently of controllers. The way RSpec does it.
What I want to do is to perform assertions on the rendered view (where no controller is involved!). In order to do so I should provide required Model, ViewData and maybe some details from HttpContextBase (when will we get rid of HttpContext!).
So far I have not found anything that allows doing it. Also it might heavily depend on the ViewEngine being used.
List of things that views might contain are:
Partial views (may be nested deeply).
Master pages (or similar in other view engines).
Html helpers generating links and other elements.
Generally almost anything in a range of common sense :) .
Also please note that I am not talking about client-side testing and thus Selenium is just not related to it at all. It is just plain .NET testing.
So are there any options to actually do the testing of views?
Thanks,
Dmitriy.
The main issue with testing full views is that the asp.net view engine calls Response.Write in the supplied context / and not on the supplied writer.
The above is not the case for testing partial views, so for those you can use this solution:
http://www.brightmix.com/blog/renderpartial-to-string-in-asp-net-mvc/
There are other view engines that do allow you to test the view i.e. Spark.
ps. the concept in asp.net mvc is that you should be able to test the view by using the ViewEngine, but as I understand the asp.net mvc team didn't work around the existing asp.net engine restrictions to be able to do so for their view engine.
You may want to check out the UI Test Helpers that Eric Hexter and the guys with MVCContrib are working on. I haven't had a chance to look at it in depth, but it may help you. I found this link that shows some of the syntax: http://codepaste.net/cw8ie4
I would be interested to know what you find out as I will be doing this pretty soon also.
Interested to know if you find anything for .Net that does this. Our current app is WPF, but we are stuck with trusting Cucumber to touch our Views in all our Features... so yeah, that sucks. Hope you find something and update us.
What I'm trying to do is generate email content using different templates.
I think ASP.NET MVC could be a good fit for this. My controller would get the necessary data for the email and decide which view (template) to render. (It's more that just a simple mail-merge, there would need to be conditional blocks, foreach's, etc.)
I want to be able to store these templates in a database rather than as files in the web application, so new templates can be easily added from the web application itself.
Is this possible? I would prefer to be able to use the WebForms view engine, but would consider other view engines if that's not possible. I would ideally like to use typed views.
Unfortunately, the WebForms ViewEngine uses some internal classes to compile the aspx and ascx files, so this is not possible. That ViewEngine requires that the Views are available as files in a folder inside the site's root (virtual folder will also work IIRC).
There are other ViewEngines that may fit your purpose better, including some that use XSLT.
AFAIR it is possible to mix several ViewEngines in the same application, so you could use the WebForms engine for your normal web pages, and a different one for your emails.
You can indeed use multiple view engines in the same application. The framework will ask each of the engines whether it is capable of rendering the requested view. Check MvcContrib for other available view engines ...
As stated in the previous answer, the WebForms ViewEngine makes the assumption that the views (aspx, ascx) are stored physically on the file system, just like ASP.NET does (although in ASP.NET you have something like the VirtualPathProvider) that was - I believe - originally added to the framework to support e.g. SharePoint).
If you want to create your own view engine, you should implement IViewEngine, and add the view engine to the ViewEngines collection e.g. in Application_Start.
Phil Haack has a great article on something similar here.
I think it could be adapted to your needs.
Kindness,
Dan
You have to create your viewengine and so your buildmanager. Your viewengine can simply retreive the aspx part from a db and invoke the webform engine. Not easy but doable, it mostly depends on how bad you need this and how will it rewards you with a nice ROI.
There are quite a lot of questions on SO regarding View Engines in ASP.Net MVC, and about using "custom" ones instead of the "default" one. For me as a hobby programmer, the term "View Engine" is new, and I have not been able to understand what it means. So, my questions are:
What is a View Engine?
What does the View Engine do, and which role in the MVC pattern does it play? (Closely related to 1...)
What are the main characteristics/properties of the default View Engine that programmers want to change/avoid by switching to a different View Engine?
What are the main benefits of common other View Engines out there that developers are after when they choose to use a different one than standard? (I've seen the name "Spark View Engine" a bunch of times, and I bet there are others too).
When (in what scenarios) would I want to develop my own View Engine?
There, I think that is all I want to ask (for now). Give me View Engines 101! =)
The "view engine" handles the rendering of the view to html, xml or whatever content type it is created to emit. Within "MVC", it would be an aspect of the View (V).
Different view engines have different syntaxes, etc. to manage rendering. The decision to use another view engine is most likely very project/programmer specific. In some cases they may see an actual or perceived limitation of the default view engine; in other cases it may simply be a different design goal or focus.
As far as Spark goes, their focus is to be much more terse than the default view engine and to remain in HTML-like syntax as much as possible instead of dropping into ASP.NET script blocks.
As an end user, the only time you would want to create your own view engine is probably never. ;) It's not a task to be taken lightly, and you'll probably end up re-implementing functionality that already exists in an existing view engine.
Edit
OK. So are the View.aspx files part of
the View Engine, or is the View Engine
a set of classes that help choose
which View.aspx (or other type of
response) that should be rendered? How
does it work?
The MVC pattern tells you that your model, view and controller will be separate "things". In ASP.NET MVC, the default view engine uses the existing ASP.NET framework, which includes master pages, ASPX files, etc. Spark does something similar, but it's a different engine so it doesn't work exactly the same. So in a general sense the view files are not engine-specific, but the specific files, their layout on disk and their contents are view-engine specific.
In addition to wanting to completely replace the view engine (e.g. Spark), you also might make your own view engine just to make a small change to the behavior of the default view engine. You could do this by creating a new view engine that inherits from the default engine and overrides some behavior.
One common example is tweaking where the view engine looks on the hard drive for the .aspx files. For example, you might want to create a view engine that automatically switches which view.aspx file is used based on whether the user is on a mobile device.
See Mobile Web Sites with ASP.NET MVC and the Mobile Browser Definition File for a really good example implementation of this.
Update:
Scott just posted an updated ViewEngine implementation that has important improvements vs the initial implementation linked above.