I have also been looking at the ExtJS ViewEngine we have in our solution. Currently, a view is defined as a method that is exists on a class with the same name as the controller it is to be called from. This means that many views are contained within a single .cs file. I had been looking at a way to make this more like WebFormViewEngine, whereby a view would be contained in a single .cs file defined something like class ViewName<TModel> : System.Web.Mvc.ViewPage. Since looking at Razor, I wanted to see how well this approach matched up with how Razor does things, as well as how well Razor would play with WebFormViewEngine and our ExtJS view engine when intermingling master pages and layouts from the various technologies.
The short answer is it doesn't, WebFormViewEngine cannot be used by Razor pages, and vice versa. It really makes sense for our site to use only one of the two technologies (to my mind, Razor makes the most sense).
While looking at all of that, I got the feeling that we may be over complicating things by having an ExtJS view engine. I've created a couple of views to illustrate this:
- ExtJSRazorView.cshtml - a razor-based view that outputs ExtJS
- ExtJSView.aspx - a WebForm view that outputs ExtJS
If you look these views in the solution, you can see that it's possible to include ExtJS JSON directly into our views. While this makes the views a bit more cluttered, it considerably reduces our code complexity and makes unit testing much easier. The only downside that I can see is that it becomes necessary for a developer to know when (and when not) to include the ExtJS viewport JavaScript. That said, Razor makes it much easier to include such things in a layout page or a Declarative HTML helper.
Nathan - there may be something I've missed which means this can't work - so shout if there is!
Comments please!
No comments:
Post a Comment