Recently I posted a new Sparkle XRM sample up on the GitHub repository. To-date I've not explained why I've spent time pulling Sparkle XRM together, so this post is going to do just that…
Sparkle XRM is an open-source library for building Dynamics CRM XRM solutions using Script#, jQuery & Knockoutjs. It brings together these open source libraries specifically for the purpose of creating Dynamics CRM HTML and JavaScript Web Resources with a User Interface (UI) that has a similar feel to the native Dynamics CRM one. I found myself converting quite a few Silverlight Web Resources over to HTML and I needed a way of achieving the same productivity I had with Silverlight. I (still) have high regard the Silverlight approach but the reality is that cross-browser and tablet support is becoming increasingly more important to users - especially in the advent of Dynamics CRM 2013. With so many excellent libraries and approaches out there to choose from, I needed to pick ones that worked well with Dynamics CRM and use them as a base-line. Keeping open source was also a priority and so I didn't use libraries such as KendoUI requiring you to purchase a license for commercial projects.
Script# was my chosen JavaScript compiler because of its maturity and simplicity. I appreciate it doesn't full support Generics or LINQ constructs, but I use Script# with Sparkle XRM purely to allow error free JavaScript authoring against a strongly typed set of libraries, and Script# does this very well indeed. Dynamics CRM's JavaScript is also written using Script# and so Sparkle XRM doesn't introduce any more complex runtime library dependencies. Compiling your project will generate your JavaScript Web Resources with compile type checking which are then automatically deployed using the Developer Toolkit – working in this way is truly a joy! I've found that this approach allows you to write code to a level of complexity that I'd never had dreamed of if authoring it in 'raw' JavaScript.
Sometimes you've just got to make a decision and run with it!
There are 2 deployment scenarios I can envisage:
- Deployment of the Managed Sparkle XRM solution as a prerequisite your XRM solution. This has the advantage that it keeps your solutions size down so any updates you deploy are quicker to install/publish.
- Embedding the Sparkle XRM Web Resources in your managed solution – this would allow you to deploy as a single package – but it would mean that your solution could not co-exist with any other solution that also contains the Sparkle XRM web resources.
Design Goals
Sparkle XRM has the following design goals:
- Provide UI controls for editable grids and form fields (both with validation) so that I could achieve the same level of productivity as I did when writing Silverlight Web Resources.
- Provide an MVVM framework for HTML Web Resources.
- Make writing client extensions for Dynamics CRM similar to writing Server extensions! It is possible to share code so that it compiles to both a plugin assembly and to JavaScript, and I'll be publishing samples of how to do this in due course.
- Speed up the code/build/publish workflow and reduce syntax errors and debug time.
- Provide a strongly typed library for elements such as dynamic Ribbon menus and localisation (multi-language/date/number formats).
Other JavaScript libraries do an excellent job of providing for SOAP/SDK calls, but Sparkle XRM aims to provide an overall framework that XRM applications can be built upon. I don't see Sparkle XRM as a replacement for those libraries and when you just need to write Form JavaScript – they will be more than sufficient. Sparkle XRM's intended use is to speed up development of HTML web resources in your next XRM project. Where you are using Sparkle XRM for Html Web Resources, you'll find it is natural to use the same library for form/ribbon JavaScript as well.
MVVM
Silverlight and WPF applications are most commonly authored using the 'Model, View, View-Model' pattern. MVVM is similar to MVC except the View-Model has much more interface centric logic than a typical Controller would do. In the days of Web-Forms/Windows Forms we would create events handlers that were invoked by UI Components (Buttons etc.). Those event handlers would then in turn make calls directly to other User Interface components (Text Boxes etc.). Now with MVVM, the View Model contains all the logic of your client side application *apart* from the User Interface Components, and importantly it has *no knowledge* of what UI components you have. Rather than making direct calls to these UI Components, the View Model refers to only other View Model properties that are in turn 'wired up' to the UI (or View) through the magic of data-binding. The View now 'sits on top' of the View Model through data-binding and invokes Commands and responds to changes in the properties it is bound to.
This approach has the advantage that is makes your application simpler in the long run because the View Model is only loosely coupled to your View. In fact you can test your View Model without even having a User Interface attached!
There are other patterns linked to MVVM (such as inversion of control) – but it is this loose coupling between View and View-Model and the simplicity that this creates that keeps me using it. Sparkle XRM uses Knockout JS as the data-binding magic behind MVVM enabling the same approach to be taken in your HTML Web Resources.
The Future's bright
Dynamics CRM 2013's new UI really sets the bar high for your XRM solutions. Users will expect the same level of single page responsive design from your own web resources and extensions. I've already found that Sparkle XRM provides a good spring board for my own projects; it possibly could for yours too.
If you would like to know more, you can head over to www.sparklexrm.com
@ScottDurow