dougmcdonald.co.uk

Intro

Last week I was fortunate enough to have a chance to attend the London based Sencha traning course focussing on Ext.js 4 development and taught by David Marsland of the Sencha team.

Coming from 6 months of Ext.js 3.3 experience with the Ext.NET wrapper and having to pick up Ext.js from effectively a third party it was a great experience to see first hand how the developers at Sencha picture their framework being used and how to structure an application in Ext.js outside of the ASP webforms model I have previously used.

The Ext.NET wrapper is very closely coupled with the webforms model in it's current incarnation (there is talk of the upcoming version 2.0 incorperating the Razor view engine and being a bit more closely matched to a server side MVC model but there is no confirmed release date for this yet) and I have been looking for a way to combine the benefits MVC in terms of structure and testability, with the rich client side experience of Ext.js.

I had two main goals from the course, firstly to assess whether both myself and our development team could easily make the transition from Ext.NET to Ext.js and secondly whether the ASP.NET MVC server side architecture would sit happily side by side with the client side Sencha MVC architecture. Both of these areas are discussed in detail below

.NET to Javascript

One of the main reasons to attend the course was to see if the gap between the familiar webforms Ext.NET implementation and the pure Ext.js framework is one that could be easily bridged.

The way that controls are constructed in Ext.NET relies on the webforms databinding methods and the business logic is attached via events which have handlers stored in the codebehind classes. These methods are a pain to detach and move to utility and class libraries, because of the events args which come from the aspx pages.

The good news is that the the differences between the two implementations is minor, this isn't all that surprising since the .NET wrapper is just that, a wrapper. Seeing the pure Javascript framework certainly helped clarify what client side code is generated and how it all fits together. Using Ext.NET, much of the client side code is effectively hidden from the developer unless you take the time to read through the minified code which is output when the page is loaded.

From a personal perspective I like to understand how things work under the hood, so writing the Javascript directly I felt aided the understanding of the structures and the properties available on each component, without any confusion between slight naming inconsistencies and the absence of certain properties/methods which are available in Ext.js and not in Ext.NET

The documentation and examples in Ext.js version 4 are a marked improvement over Ext.js 3.3.x and exploring these without needing to also ratify properties existence in a wrapper certainly felt like it would be a productivity benefit. Sencha have clearly listened to their users with regards to the documentation and these are getting better every day, the range of examples and guidance is growing and the 'learn' section on the website offers a great selection of instructional videos as well.

ASP.NET MVC & Sencha MVC together?

The second major question that needed to be answered is whether ASP.NET MVC and Sencha MVC can work side my side in the ways they were intended to. Not having any experience in Sencha MVC, the first task was to understand how the Sencha MVC implementation is designed. What I learnt is that there isn't a particularly easy way to simply attach an Ext.js front end directly into the ASP.NET MVC model and controller backend, so the Ext.js cannot simply be the view

Actually that isn't entirely true, you can plug an Ext.js front end in as your view, but you will not be able to use the Sencha model validation functionality which means that you will be able to do client side form validation (via Ext.js), but only server side model validation. This will result in a full post request in order to trigger any complex model validation. The 'model' in the sencha MVC implementation allows validation on a data model to be performed on the client side, so it can prevent the need to pass anything down the wire if the validation fails, this would have obvious performance and user experience benefits if in an environment where communication with the server is slow, or bandwidth is at a premium.

The Sencha MVC implementation is entirely client based, and the advantages are largely around code structure. Putting methods into a controller class and having direct access to view components which are registered in the controller is certainly more logical in terms of making the Javascript maintainable and predictable. The downside of this is that the model class is purely a client side representation of the model on the server side, which leaves you needing to maintain two models which doesn't really make the approach fit into the DRY way of thinking.

The way to get around this, would be to dynamically generate a client side model class based on the server side model, either at runtime or compile time. Aspects of this such as producing a list of properties should be quite straightforward, but some of the other aspects of the model will be more tricky. Particularly the 'associations' component of the model. These associations are Sencha's way of modelling relationships between model classes on the client side.

There is a really nice pairing of technologies between the Sencha store proxy and ASP.NET MVC controller actions which perform crud operations. Namely that you can define a URL on a store proxy for each CRUD operation. This would match perfectly between client and server side, and the Ext.js code would make automatic ajax requests for each operation to syncronise the client side store with the server side datasource when you call .sync() on the store.

The piece of the ASP.NET implementation you lose by using Ext.js is the ease of using stongly typed model classes in views, the easy access to model properties directly in the HTML flow and the automatic generation of client side validation code based on the model, so basically the entire 'view' component. This is a bit frustrating, ideally I was hoping there would be some way to tie up a layout defined in a view with a model, for the purposes of validation. I have begun thinking about ways to generate an entire Ext.js view from a C# model class and have done some basic experiments creating controls based on this, but the problem is that you lose the flexibility of form design by automatically generating the view, for simple forms this would be fine, but many application forms are so complex that this approach would be very hard to implement.

In all honesty I would expect to lose a lot of this functionality using Ext.js in any guise, so this may well be something that just has to be dealt with. I will however run some tests with using ID's on sencha components and seeing how jQuery validation generated by .NET interacts, it would be superb if this automatic validation could be tied to Ext components.

Apart from losing a little of the ASP.NET MVC view functionality and needing to find a way to produce a client side model automatically (or to be prepared to duel maintain models) there is no technical reason why the two technologies can't exist side by side offerring the MVC benefits on both client and server side. There are certainly not any areas which tread on each others toes so no conflicts should occur. When time allows I will be investigating this issue with an example project and will add a second post with any technical considerations highlighted in code.