Multi-Entity Search: Paging verses Continuous Scrolling with SparkleXRM

If there is one thing that's for sure it's that user interfaces are for every changing. I fondly remember grey pages with rainbow <HR>'s:

Continuous scrolling data sets are a common mechanism seen in news feeds sites such as Twitter and Facebook. As you scroll down the page and reach the bottom more results are loaded dynamically as needed. Dynamics CRM has traditionally shown paged datasets and although this is mostly still true we are seeing some areas shifting to a more continuously such as the Tablet App and Social Feeds (although the news feed does required your to select 'More').

With this in mind I decided to implement a continuous scrolling Data View for SparkleXRM. The original Multi Entity Search sample used the standard EntityDataViewModel but I've now added VirtualPagedEntityDataViewModel to the sample project which shows how this virtual paging can be accomplished. Under the covers it is stilling paging using the fechxml paging cookie but as the user scrolls, additional pages are retrieved in order to show them. Once the pages are loaded, they are cached in the same way that the EntityDataViewModel did. I have also added support for showing the entity image next to the record so the end result is very similar to the Tablet app search results. Infact the entities that are shown are read from the same Tablet search configuration.

You can access the new search via an updated 'Advanced Find' button that shows a pull down on the dashboard home page:

Both the paged and continuous scrolling multi entity searches in in the solution but only the continuous scrolling version is added to the ribbon button. To install the solution you'll need to:

Install the latest build of SparkleXRM managed solution - Install the sample managed solution -

I'll be rolling a version of the VirtualPagedEntityDataViewModel into the code SparkleXRM soon – so let me know if you have any particular uses for it in mind. Have fun! @ScottDurow

How to fix CRM2013 Application Bar hidden by Silverlight Web Resource

If you have any Silverlight Web Resources in your site map that are hosted by an HTML Web Resource, you may find that when you upgrade to CRM2013 and use the pull down Application Bar the Silverlight page is rendered on top of the navigation buttons so that they are obscured and hidden from the user. It might look something like the following:-

To fix this you need to adjust the Windowless property in the Silverlight object: <object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%"> <param name="Windowless" value="true" /> Other than this I've not had any issues with Silverlight in CRM2013 but there is now a nice phrase in the SDK that states: "Microsoft Silverlight web resources remain supported in Microsoft Dynamics CRM 2013 and Microsoft Dynamics CRM Online for backwards compatibility. For components that will be able to be presented on all clients, we recommend using HTML web resources with HTML5 instead of Silverlight." If you need to convert your Silverlight Web Resources to HTML 5 and JavaScript, you could check out @ScottDurow

Asynchronous loading of JavaScript in CRM 2013

When CRM2011 UR 12 (POLARIS) introduced asynchronous loading of web resources, there were some unfortunate side effects caused by the load order in which the scripts were executed not being the same as defined by form customisations. If you had scripts that required a previous scripts to be loaded first before it could be executed, you would experience random script errors due to the unpredictable load order. You can read more about the issue in the MSDN forums thread and the blog post I wrote explaining the behaviour and workaround. Since then, the behaviour has been reverted back to the pre-UR12 loading technique as of Dynamics CRM2011 UR15 but this post describes what you can expect from Dynamics CRM 2013's script loading mechanism. Why Asynchronous? One of the reasons for moving to an Asynchronous loading model for JavaScripts was to make the form feel more responsive. Rather than having to load all scripts first before code can start and the form can be rendered, the scripts are loaded in parallel (as far as the browser will let them) resulting in a faster load time compared to a sequential load. Code that has all of its dependencies loaded can also start running before all of the unrequired scripts have completed being downloaded. Libraries such as RequireJs handle the complexities that can result from interdependent scripts all loading in parallel and your code needing to know when its dependencies are loaded before executing. CRM2013 scripts do not load in order With Dynamics CRM 2013, scripts are now loaded asynchronously and although the onload event will be executed after all scripts are loaded, the loading of the individual scripts will happen in the order that they are received from the server and not the order that they are specified in the form properties. Of course how you load JavaScript in Html Web Resources is still up to you! Debugging Scripts One by-product of this dynamic loading of scripts is that you won't see your web resources in the list of scripts using the F12 debugger since the browser has no <SCRIPT> tag to get the URL from. The script will still be available for debugging; however it will appear as an anonymous script block rather than in the list of script sources against its web resource URL. The technique I describe in the 'New Project' SparkleXrm tutorial of using to create a re-direct to a script on the disk will still work because the browser request the web resource by its URL, allowing fiddler to intercept and redirect. Caching behaviour is unchanged with the web resources being cached by the client until customisations are published and the cache version is changed. You can read more about this mechanism in my web resource caching blog post on the subject. Fast and Responsive The good news is that as a result of the changes – forms are noticeable faster to load. @ScottDurow

Multi-Entity Search with SparkleXRM

The new tablet client for Dynamics CRM 2013 has a fantastic looking multi-entity search but it is not yet available in the Web Client. I thought this would be a good opportunity to create another SparkleXRM sample to achieve a similar feature with Dynamics CRM 2011. You can check out the sample by installing the managed solutions:

SparkleXRM Managed Solution MultiEntitySearch Managed Solution

Once installed, it creates a sitemap entry that runs shows the Multi Entity Search HTML Web resource. By default, it'll show the Account, Contact, Lead, Activity & Opportunity entities, but can show other entities by passing parameters. Each entity grid shows the 'Quick Find' view for the given entity and displays the head and column names in the user's chosen language. The grids are fixed widths, but will wrap according to the screen width available.

The sample shows the following features:

Using the Metadata Query SDK to retrieve entity & attribute types and display names in the user's chosen language. Grids displaying the page size defined in the user's settings. Using the grid data binder and parsing fetchxml/layoutxml Rendering grids with clickable links to entity records. MVVM binding with asynchronous queries

It achieves all of this in very few lines of code. You can take a look at the sample code on GitHub:

View Model View


jQuery and jQuery UI with Dynamics CRM 2011 & 2013

Since I’ve been converting Silverlight web resources over to Html & JavaScript and working on , I’ve worked extensively with jQuery and jQuery-UI. In the early days of Dynamics CRM 2011, you could use both these libraries without a problem, but with the Activity Feeds solution an instance of jQuery appeared that interfered with your custom scripts. This is still the case in Dynamics CRM 2013 and so here are some simple steps to ensure your libraries are safe and will co-exist with other instances from other solutions. 1. Decide on a custom ‘namespace’ for your jQuery library. I am using ‘xrmjQuery’ 2. On the end of your jquery.js script add the following line: /* jQuery script goes here */ window.xrmjQuery = jQuery.noConflict(true);

  1. Inside your jquery_ui.js script (notice the ‘-‘ has been changed to an underscore since CRM doesn’t allow them in web resource names), wrap the whole file in the following lines: (function ($,jQuery) { /*! jQuery UI Goes here */ })(window.xrmjQuery,window.xrmjQuery);

  2. Inside your JavaScript web resource that use jQuery and jQuery-UI, wrap your code in the following: (function($){ // Your Javascript goes here and can reference $ as usual // e.g. var someField = $('#fieldName'); })(window.xrmjQuery);

This technique is called encapsulation and namespacing of jQuery. My friend Carsten also has a blog post on a similar theme. uses the same technique and namespace is also ‘xrmjQuery’, so if you would like to quickly get access to the jQuery libraries in Dynamics CRM, you can install the SparkelXrm managed solution and include the web resource named ‘sparkle/js/SparkleXrmUIDependancies.js’ – this is a single library that has both jQuery, jQueryUI as well as a few other goodies such as Knockout JS!   @ScottDurow

Sparkle XRM

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 @ScottDurow