Ext.JS view implementation

Alistair wrote a great post on Friday recapping his visit to Bath. Amongst his points was a section on his concerns with implementing Ext.JS in an MVC environment, and an equally excellent reply from Nathan (at 2am when he was on holiday!)

Rather than further dilute Alis post covering a multitude of points, I thought I'd start a new post specifically for discussing our Ext.JS implementation.

I think the use of Ext.JS is possibly the biggest implementation issue we face and the decision to use it hasn't been taken lightly. Let’s recap the benefits:

• Standardises the UI design
• Provides a design framework for non UI coders
• Cross browser compatibility
• Speed of development
• Established support network
• Low cost (in comparison to hiring a UI designer)
• Provides professional results and lets me allocate resource to complicated back end stuff
• (Any more?)

I'm now going to attempt to address some of Alis points:

"The thing that niggles me is with MVC we got separation of concerns, clean coding. now the way we are creating view is putting the view logic right back into c# code, is this ignoring the MVC design pattern?"

Ali, the way to think about our view implementation is that it separates C# from JavaScript entirely, and pretty much does away with Html altogether – no bad thing IMO! The fact that you are writing a view in a .cs file rather than an .ascx is really just semantics – essentially you are calling Html helpers to build up a form, just in a structured framework. (This is basically what Nathan said!)

"It doesn't seem like we are keeping the view as clean as possible, although we are abstracted by and large from having to deal with it, Dose ext.js not over complicate the DOM creating numerous divs and tables for layouts? and if it dose really should we care?"

It's my impression that the DOM created by Ext.JS is as complicated as it needs to be to provide highly functional cross browser controls - that is to say, if we did it in house, we wouldn't necessarily do it better. Be aware though that Ext.JS does provide garbage collection methods, which we need to understand and use where necessary.

"On a personal level it get's me away form writing any Jquery, or getting used to html helper classes and Razor which for myself I feel I would like to be doing."

There will still be times when you guys need to get your hands dirty in the UI - either updating the JavaScript underpinning the JSON-Ext.js translation or writing custom views that can't be achieved in Ext (the solution doesn't prevent you from being able to do this). To me, that's more interesting work than writing a bit of JQuery to call a controller method or achieve a cool effect. The other thing we have sometimes used JQuery for is view logic, and I'm not convinced that we should be doing that. I'm not that impressed by what I've seen of Razor either – you’re still mixing server code with HTML and JavaScript (my main issue with our .ascx pages), just in a different syntax! I'd be interested in hearing whether the other guys have similar concerns about missing out on using these skills.

"I accept that we don't have designers and we want to achieve a commonality in look and feel of pages and controls, I am still unclear how easy or hard it is to change layouts, and how likely is it we are going to be asked to do this."

I would hope that once the layout is set, it won't be changed for a long time, but the point I guess is that minor tweaks will be easy to do.

"I do feel happier about working with this after seeing that we can template out views quite efficiently thanks to Nathan template utility."

Good!

how easy is it to debug. where have you guys found problem in the past?

Good question - Nathan?

"Can we easily achieve validation (like out of the box mvc validation) ?"

I believe that Nathan did validation for the CSP without much effort - I'd like more detail myself here though.

"Are we overcomplicating things, I mean should Html helpers take care of most things and a few Jquery or Ext.js plugins cover the special cases?"

Excellent question! I guess we're not going to know for a while - but I would say that what we have tried to achieve with UI for IQ in the past tends towards the complicated end of UI design and functionality, and at that point it could be argued that Ext.JS could - no, should - simplify things for us...

Feel free to add / flame the above points. I’d also like to see the following points on Ali’s post addressed in more detail by the team:

• MVC Validation
• View Debugging
• Is JSON in C# complicated?