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…
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.
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.
- 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).
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