My jsFiddle Bag of Tricks

I'm just going to say it, I love jsFiddle.net. Like others pastebins such as Gist or CodePen.io, jsFiddle allows you to rapidly prototype HTML/JavaScript/CSS and test the result in real time. There is extensive library support, and you can do tricky things like embed your results as an iframe on a GitHub page, or use GitHub to back up a demo. But the basics of jsFiddle are that you can create a small to medium application, share it easily so others can fork it, and tweak it to your heart's content, with easy to use restful routing and version control. What's not to love?

In order to make the most of jsFiddle, however, I had to sort out a few things. Please feel free to share your own bag of tricks, and here are some of mine.

1. Use the Ionic bundle as an External Resource. You can select AngularJS 1.2 from Frameworks and Extensions, but if you add the following links to External Resource, you will get a bundle containing both AngularJS and the Ionic Framework, which allows you to do some clean mobile UI.
   
   http://code.ionicframework.com/1.0.0-beta.6/js/ionic.bundle.js
   http://code.ionicframework.com/1.0.0-beta.6/css/ionic.css
   
   You may strip out the Ionic stuff before you release your work, but I have found it to be a great framework for rapid prototyping with a Mobile First mindset. Cards are great. Also, ngCordova is an extension for Ionic which allows you to embed your work into iOS or Android using PhoneGap.
   

   Ionic may not be perfect (it's still in beta), but it is very Mobile First, useful for rapid development, and has a lot of similarities with Bootstrap. Try it out.

2. Embedded results pages are great, but they often fail to load until you change "https" to "http". Same goes for the External Resources. Get used to quietly deleting the "s" during demos, and hoping that nobody notices.
   

   GitHub and jsFiddle can work very well together. I suspect you could get similar results with Gist or Codepen, but I personally prefer jsFiddle. Learn to use social repositories to create individual code samples and project pages.

3. JSONP can work, this is very handy. I often set up JSONP files, JSON wrapped in a function call, on a GH Page on GitHub, so that I can access them later as though they were an actual API. In order to do so, rather than echoing the call from the jsFiddle itself, I have a useful Angular directive I use:
   
   

   rhizomeBase.factory('jsonpService', function ($http) {
       var svc = {}, jsonp_data   
       jsonp = function(data) {
           jsonp_data = data
       }
   
       svc.getData = function(callback, url) {
           $http({
               method: "JSONP",
               params: {
                   input: "GM",
                   callback: "jsonp"
               },
               url: url,
               isArray: true
           }).success(function(data, status) {
               callback(jsonp_data)
           }).error(function(data, status) {
               callback(jsonp_data)
           });
       };
       
       return svc
   });

   
   All this service does is set up an http: request as a promise, and then apply a callback whether the request succeeds or fails. It turns out that when the request succeeds, jsFiddle treats this as a failure, but all of this gets hidden in the service. In practice, once you have an Angular application set up in jsFiddle, you can call inject the service into your controller or directive and invoke it with a very direct call like this:
   

   jsonpService.getData(function(data) {
       alert(JSON.stringify(data))
   }, url)

   One of the things a pastebin allows you to do is prototype a client application without having to worry about building a server-side API first. Hosting a handful of sample messages on GitHub is a good way to accomplish this.

4. Use appropriate standards. This is really the flip side of  building a client-side application first. If you have access to a JSON-based standard like NIEM, or you can use a snippet gleaned from Schema.org, this will save you some design time and get you moving in a forward trajectory. In my case, the JSON flavour of HL7 FHIR, the component-based nature of Angular, and the ease of use and built in UX touches of Ionic are a perfect storm for the kind of work I like to do, and jsFiddle is the glue that holds these together.
   

   If you can, learn and use appropriate standards.

Using AngularJS with HL7 FHIR Questionnaire

This  is a very simple example using Angular templating (no directives) with an HL7 FHIR Questionnaire resource, which I am using directly from one of the public FHIR servers (Grahame's to be precise). In addition to the machine-readable content for question groups and answers, I am creating a rudimentary service to manage coded concepts (ie value sets), and I am displaying the human-readable portion of the resource (the HTML text div) as well. This is really just a beginning, and one thing I would like to build into this demonstration is the ability to use embedded SVG for the human-readable portion, as it seems to me that existing PDF questionnaires could be converted to SVG and thus embedded. Makes for a large resource file, but this would be a great way to retain the look and feel of existing documents, once an easing library is used to zoom in on the appropriate area of the SVG. I'm calling this demonstration "QuestionCare" because I think it would also be useful to be able to use Careplan within this context.

We begin with a root HTML that sets up my Single Page Application, and a reference to my Rhizome library, which contains a number of useful client-side services:

<body id="content" style="display: none;" ng-app="questioncare">
      <h3 ng-controller="ErrorController" ng-bind="errorText" ng-show="showError"></h3>
      <div id="request" ng-controller="RequestController">
        <button id="view-questionnaire" ng-click= "viewQuestionnaire()">View Questionnaire</button>
      </div>
      <ng-include src="res/templates/Questionnaire.html"> </ng-include>

This corresponds to a single line in the javascript initialization:

var questioncare = angular.module('questioncare', ['rhizome', 'ngSanitize']);

 We'll see how the ngSanitize module is required in order to handle rendering the human-readable HTML div from the Questionnaire resource as HTML, instead of text, using ng-bind-html. In any case, we are setting up a controller to handle a request, and then we are including a template to handle the response. The rest, as we shall see is handled through controller code and client-side services, but let's take a quick look at the included template for Questionnaire:

<div id="questionnaireResponse" ng-controller="QuestionnaireController" ng-show="showQuestionnaire">
  <div ng-bind-html="humanReadable"></div>     <hr/>
  <div ng-bind="questionnaire.name.text"></div>
  <div ng-bind="group.header"></div>
  <hr/>
  <ol id="questions">
    <li ng-repeat="question in group.question">
      <div ng-bind="question.text"></div>
      <ol id="options">
        <li ng-repeat="option in getOptions(question.options.reference)">                    [<span ng-bind="option.code"></span>]:
      <span ng-bind="option.display"></span>
        </li>
      </ol>
    </li>
  </ol>
</div>

 That takes care of the HTML. The request controller invokes an adapter (this is running on IBM Worklight), and then sends the response to the questionnaire controller using $rootScope.broadcast, but first it calls a client-side service which I have made responsible for managing codes; in this case, the value sets for the different options you can pick when you answer the questionnaire.

questioncare.controller( 'RequestController',
  function($scope, $http, $rootScope, errorService, codeService) {

    $scope.viewQuestionnaire = function() {
           
      var invocationData = {
        adapter: 'FHIR',
        procedure: 'getQuestionnaire',
        parameters: []
      };
           
      WL.Client.invokeProcedure(invocationData, {
        onSuccess : function(result) {
          if (200 == result.status) {
            var ir = result.invocationResult;
            if (true == ir.isSuccessful) {
              $scope.$apply(function () {
                var questRes = ir.content;
      codeService.loadCodedConcepts(questRes.contained);          $rootScope.$broadcast('qr', questRes);
              });
            } else {
      errorService.worklightError('Bad Request');
            };
          } else {
      errorService.worklightError('Http Failure ' + result.status);
        };
      },
      onFailure : errorService.worklightError
    });
  }
});

The codeService itself is quite simple, although, since value sets could potentially come from a variety of places, this service could become a lot more complicated. In this case, I am just scraping contained value sets from the Questionnaire resource itself:

rhizome.factory('codeService', function($rootScope, errorService) {
  var codeService = {};
  codeService.codedConcept = Object;
   
  codeService.loadCodedConcepts = function(contained) {
    for (c in contained) {
      codeService.codedConcept[contained[c].id] = contained[c].define.concept;
    }
  };
   
  codeService.getCodedConcept = function(opt, remHash) {
    if (remHash) {
      opt = opt.substr(1);
    }
    return(codeService.codedConcept[opt]);          
  };
   
  return codeService;
});    

Angular services can be difficult to grasp at first, but they are one of the more important features of the framework, since they allow you to make your client-side more portable and standardized; however, this particular service is little more than a stub at this point. It deals with a hash sign which is probably included with the value set id, which is useful. Once the coded concepts have been scraped out of the Questionnaire, the document is displayed using the included template and a response controller.

questioncare.controller( 'QuestionnaireController',
  function($scope, errorService, codeService) {
   
    $scope.showQuestionnaire = false;
   
    $scope.$on('qr', function (event, arg) {
      $scope.questionnaire = arg;
      $scope.group = $scope.questionnaire.group;
      $scope.humanReadable = $scope.questionnaire.text.div;
      $scope.showQuestionnaire = true;
    });
          
    $scope.getOptions = function(opt) {
      return codeService.getCodedConcept(opt, true);
    };

});

Again, there is nothing too complicated here. Notice how the humanReadable questionnaire text div gets bound into an element that allows HTML to be rendered. Also, a second function is used to get and then display the options because these need to be repeated, as you can see in the Questionnaire.html. In addition, the entire questionnaire template is hidden until it is populated.

Next steps here will be to work with nested questionnaires, where selected options will traverse through a hierarchy of question groups. At this point, it may be useful to use Angular custom directives, although I am also trying to be careful about anything that will be subject to change with Angular 2.0, such as controllers.

More and more as I work with Angular, Worklight and HL7 FHIR, it strikes me that what is important here is building a library of standard services and templates on the client side, and then simply binding into it. Once DSTU2 is complete for FHIR it will become less of a moving target, but resources like Questionnaire, which has been the subject of several connect-a-thons now, seem especially stable.

Atomized Integration, IBM Worklight and AngularJS

Over the past year, I have worked fairly extensively with IBM Worklight, Big Blue's enterprise mobility package. In the coming year, I plan to find more things to do with Bluemix, IBM's cloud mashup line; for now, some thoughts.


In general, my guidance has been to use open source mobility frameworks, PhoneGap for cross-platform, Bootstrap for Responsive Web Design, Angular for templating, and some form of OAuth2 for security, at least until the vendor solutions from IBM, Oracle, et al reach a higher level of maturity, since these are stepping stones.

If you look at the latest Gartner quadrants for enterprise mobility and cloud for the previous year, you will see IBM maturing in the MADP space and Oracle maturing in the cloud space... but maturity in both areas is necessary for enterprise mobility to fire on all pistons.

Worklight does three things really well:

1. Simple adaptation on the server-side, using Rhino-based Javascript adapters.
2. Integrating with existing Websphere and SAM infrastructure.
3. Increasing productivity through modularization and emulation.

Probably the biggest win here is 3. I started out 2014 working with Firefox OS, Saxon-CE and AngularJS, so I was already committed to using Javascript and XSL as much as possible, and Worklight Adapters played into this approach nicely; however, after *hating* the slowness of native Android development using the Android toolkit, what I appreciated most about Worklight was being able to use an emulator that ran as smoothly as the Firefox OS simulator (which is really just a browser plugin). On the server-side, we are becoming more accustomed to devOps tools like JRebel; on the client-side, we should have similar expectations - is, don't use the Android emulator if you can avoid it. It sucks.

I have mentioned previously how much I like Worklight's lightweight Rhino-based adapters. They are intentionally lightweight, eschewing any sort of SOA reusability. A Worklight adapter does one thing, and it does it well. This can be initially quite pleasant, then very frustrating, and then liberating, as you sort out how much integration you need to do in your client applications. My experience has been that a well designed piece of XSL can convert an XML data source into some standards-compliant JSON, and then a client-side library service can take it from there.

For instance, consider that I have an XML data source containing a number of patient records. Let's say it is NIEM compliant XML. I could build a client application that can consume NIEM compliant JSON, and then all I would need to do in Worklight is create a very simple boilerplate adapter that transforms the XML into JSON. This is assuming that my server-side data source doesn't already support JSON-flavoured NIEM, which would be even simpler. In other words, if my intent is to take a NIEM compliant data source and build a NIEM compliant mobile application, this is quite straightforward. Server-side Worklight adaptation transforms XML into JSON; client-side Angular data-binding injects JSON into the HTML-based presentation layer, and presto, you have an application.

Granted, the development process is not that easy, and let's consider now that we have a number of data sources, some of which are NIEM compliant, some of which are HL7 compliant, some of which are based on direct SQL access, and some of which are ad hoc.

When you look at the various Worklight adaptation examples, you might get the idea that RSS is treated preferentially, which is untrue; however, thinking of these adapters as syndication is still a useful approach.

Throughout the past year, I have been working with HL7 FHIR, a draft standard from HL7 that among other things introduces a JSON-based pattern for aggregation and composition that is essentially Atom syndication in JSON instead of XML. It turns out that if all of my Worklight adapters create Atom-compliant JSON on the server-side, then I can use a Javascript Atom library in the client, and it really doesn't matter what format my data sources are using. By the time they reach my client application, they are all Atom-based.

The client-side service that I have written - using Angular for modularization - is responsible for merging multiple Atom streams. Once I have a single Atom stream, data-binding takes place, so that information can be presented. In practice, this can be frustrating because Atom is intended for serialization of information, but an Atom bundle can also contain relative links between entries. This is fundamental to the way HL7 FHIR works, but not NIEM, so I have ended up creating synthetic and essentially schemaless resources as necessary. Ideally, all information could be mapped into Atom-syndicated FHIR resources. Maybe that's a good project for this year.

Adaptation frameworks always run into a problem based around the decision to go lightweight or go modular. I like that Worklight has gone lightweight, but I am frustrated that I can't reuse just a little bit more code between adapters. In particular, I would really like to use a single set of XSL transforms to support multiple adapters. Perhaps there is a way to do this, but for now, I am still forcing myself to prune my adaptation code as much as possible to keep it easy to maintain. If I find myself using the full set of DocBook or DITA transforms in an adapter, it's probably time to rethink my approach.

On the whole, I have enjoyed working with Worklight adapters immensely; I don't think this would be the case if I was not also using Angular or some other Javascript framework to support development of client-side services. I haven't particularly used the built-in Worklight support for Dojo or JQuery, but I'd go so far as to say that without some sort of hybrid framework support, you will lose much of the productivity that Worklight gives you. After a year, I have reached an understanding that I would not enjoy using a framework like Angular without a platform like Worklight, and I would not enjoy using a platform like Worklight without a framework like Angular.

Unless, of course, the platform was also a framework, which is what approaches like Meteor promise. 

  

AngularJS and Durandal

When I read on the Angular blog that Rob Eisenberg is working with Angular in addition to continuing revisions on the Durandal templating library, I was understandably excited. I have really enjoyed working with Angular, not just as an SPA framework, but as a prescriptive, modular, and mature JavaScript framework, but like many people, I have found custom directives frustrating; jsFiddle and similar tools provide a good way to develop and test a new directive in isolation, but still. I've experienced this on other projects, using Adobe Flex, for instance. On a project team, you have a number of developers, one of whom supports custom web components, and that works okay, but the other developers don't really understand how the components work under the hood.

I am hoping that the next evolution of AngularJS (3.0) will align much more closely with Durandal, Web Components API, and Polymer. There is really no reason why custom Web Components cannot become just a standard practice for the web. And that's nothing like Angular custom directives, which are confusing, I think, because whereas in most cases Angular balances flexibility and prescription nicely, custom directives are incredibly flexible - transclude? allow directive through attribution or class, or just elements? and so forth. Custom directives are just way too flexible, and they need to be a simple API for doing one thing well, not a combinatorics problem.

On the other hand, what Angular provides that Durandal does not is exactly that balance of prescription and flexibility. Angular tells you how to do things like module structure and model-view-star, and as a development project lead, I appreciate that, because this makes establishing best practices and code reviews manageable. That is why I am expecting great things from Angular, especially if the next version also results in an update to the angular-ui.bootstrap project, providing a ready to use library of web components.

Single Page Applications and AngularJS

For many years, the phrase Single Page Application (SPA) was synonymous with TiddlyWiki, a JavaScript-based wiki that was most useful for running independently without an application server and for some very well written code. Aside from TiddlyWiki, SPA was an approach, not a thing.

Mature JavaScript frameworks like Backbone, Angular and Ember have changed this, embodying the notion that you don't find a sweet spot between pure server push and pure client: you either load an application page by page, or you load a single page and construct the application from client-side templates, routing and model-binding. JQuery can support an SPA approach, but doesn't enforce it, and Adobe Flex enforces an SPA approach, but requires Flash to do so.

Of course, Angular is more than just an SPA framework. Amongst the features Angular provides:

Dependency Injection - a core value of the Angular framework, DI clearly defines the interface for what a class consumes through its constructor, rather than hiding class requirements within the class, which makes Angular JavaScript more readable, easier to maintain, and easier to test, since it is clear how internal connections between services are made within your application code base.  This results in fewer lines of more maintainable code, and ease of testing.
 
Templating - Angular templating consists of partial HTML views that contains Angular-specific elements and attributes (known as directives). Angular combines the template with information from the model and controller to create the dynamic view that a user sees in the browser.  The result is more natural templates, based on attribution well-formed HTML.

Two-way data-binding - allows you to work with JSON easily, particularly when this JSON is generated from standardized schematics. An example of this would be if an application receives a JSON payload that is constrained by an XML Schema in the server-side API (the API supports both XML and JSON, and the XML complies to an industry standard). In this case, the Angular view could also be generated from the underlying XML Schema.

Modular JavaScript - nothing special here, Angular allows you to separate the concerns of
controllers, services, filters, and directives into separate modules. Encapsulation makes these components easier to maintain and easier to test, for instance by a team with multiple members.

Controllers and URL Routing - aside from Dependency Injection, Angular's MVVM pattern is the big win here, and routing is just something you need to get used to. Originally, JavaScript was the glue-code for the web, and once you have your application sufficiently modularized, you will find that your Angular controllers retain this stickiness, but, as you build reusable services, your controllers remain lightweight. If you have any business or maintenance logic in your controllers, it is time to refactor and create services. Controllers and routing may not be reusable; services and views will be.
 
Multi-level data scoping - scope is confusing in JavaScript because of the way global scope and declaration hoisting work. Angular simplifies passing scope into a controller or service, and offers a rootScope object that replaces the global namespace. Further, events can be associated with scope at various levels. Data binding, the event model, and service invocation all use the same scope mechanism.

Responsive Design - Bootstrap is a Responsive Web Design library built in CSS and JavaScript. The JavaScript portion of Bootstrap has been ported to Angular directives as part of the AngularUI extension, which fits nicely within the Angular directive paradigm. Directives are fundamental to how Angular works. Using the Bootstrap directives removes some of the need to develop custom directives (custom behaviors and HTML tags). [http://angular-ui.github.io/bootstrap/]

Web Components - with the upcoming partial merging of the Angular framework with the Durandal presentation framework, Angular should move one step closer to supporting the Web Component API, which aligns with the intent behind Angular custom directives, and will bring these more in line with projects like Polymer. By using a common API, these UI libraries become more transportable. 

Back to Basics: Rhizome

I started the Rhizome reference implementation a year ago as a way of demonstrating how a combination of client-side services, constructed using Angular and Cordova, and server-side adaptation and integration, constructed using Worklight, could be used to build a mobile health app for the enterprise. The pieces are there, and I have come to their conclusion that the server-side integration, while important, should really just be built into the application server, which hosts the server-side API. If the server-side API is built to an industry standard like NIEM or HL7, then the burden of integration is lightened, and maybe it could take place within a resource-based suite of client-side services.

The greatest illumination for me came when I stopped trying to build the server back end and with a client app extending it, and instead focused on a client app with an HL7 FHIR standardized interface. Do I have to do a lot of adaptation on the server? Depends on the data source, but... In an ideal world, thee data source has low impedance, and it is already FHIR JSON. In that case, an Angular app built around the core FHIR resources just works.

So I'm taking my references implementation in a slightly different direction, less coupled to an enterprise mobility platform, more reliant on a strong client-side architecture which is resource-based and standardized for the health industry, leveraging profiles from organizations like IHE and HL7 where possible, and probably with a more specific focus on care plans and questionnaires, without losing focus of prescription medications.

I'm also going to try posting more frequently, for a variety of reasons, so please feel free to comment. I have really enjoyed working with AngularJS over the last year, and I know I'm not alone in this.

Object-oriented JavaScript as a language for learning

I have been reading Nicholas Zakas' Principles of Object-oriented JavaScript, from No Starch Press. I have been using JavaScript for many years, and to this point, the books I have found most useful are the essential "rhino" guide and Doug Crockford's "Good Parts," both from O'Reilly, because they were the books that first turned me onto the awesome potential of JavaScript as a declarative language that also supports inheritance, and then steered me away from the dangers of some of the patterns and habits into which I had fallen.

Zakas writes well - this is not his first book - and I love the way this book is organized around well thought out descriptions of core ideas; for instance, what is an Own Property, and why would you need one, or how does the Prototype Chain actually work. This is a quick read that really provides you with everything you need to then move onto a framework specific book on Backbone or Angular, whatever you need for your particular project; and really this is where this book shines, when it digs down into some of the more esoteric features of the JavaScript language, but never leaves stops answering the question, when is this going to be important when I am writing actual code. This is the book I would recommend, for instance, to any of my colleagues who is making the transition from server-side Java to client-side JavaScript. Quite simply, Zakas answers the questions you are going to ask with well though out answers.

Beyond this, all the books I have seen from No Starch Press are beautiful to look at. My own background is in Literary Theory in addition to Information Technology, and I loved my graphic novel guides to Derrida, Foucault and Freud, so much so that I gave them all away to people who wanted to know more about what I was studying. Like those graphic novels, I imagine the books from No Starch Press are a delight to give away; they look great. In addition to the aforementioned Java programmer colleagues, I also think Zakas' book would be very apt for a 15 or 16 year old who is interested in programming, as would any number of No Starch's "manga guides".

In short, good code examples, short chapters, great discussion in depth of core ideas with well
thought out descriptions of the things that make object-oriented JavaScript idiosycratic, and a book I find myself going back to and recommending for others, particularly people I know will be going on to use JavaScript with framework support like Angular.

Sozi for Inkscape: SVG as Presentation Web

I started out using PowerPoint, and it was good. I perfected the six slide presentation. I discovered Prezi, and it was... interesting. I like the idea of a non-linear presentation which focuses in and out and slides around to make its point. And I like being able to quickly make a presentation that tells a compelling story without having to move from left to right.

And then, to quote Upworthy, I found the Sozi plugin for Inkscape, and it blew my mind.

So okay, you need to be handy with vector graphics (SVG) if you want to make a professional looking poster using Inkscape. And you have to be careful, I discovered, about using free-flowing text, which just plain doesn't show up in Sozi. But, it's easy to find nice examples of people who have already made professional looking posters using Inkscape, and it's easy to "Convert to Text" to fix free-flowing text, and it is so easy to use the Sozi plugin to sequence frames and create an amazing looking presentation that will impress your boss.

But more than this, I have recently discovered that you can use Inkscape to embed links - internal and external - within an SVG document, so really, as far as I can tell, there are two kinds of websites you should be thinking about: One built on the idea of application, as in single page application, or server-side templated application or whatever, but definitely HTML5; and one built on the idea of presentation. And for a presentation website, why not just use SVG, using Inkscape and Sozi as a development tool? Really. Why not?

I'm reading Nicholas Zakas book on Principles of Object-Oriented JavaScript (No Starch Press), and I'm really enjoying it. When you I first encountered JavaScript, I found it very functional, in the sense that I could make it do things I wanted it to quickly and easily, a trait which I had never found in Java. Then I read more on the web, and then I found Crockford and Resig and the important JavaScript books they wrote, and it started to make more sense. Where books like The Good Parts are prescriptive, because they have to be, and JavaScript is a language with clearly too much rope, that is not the mode of Zakas book. Instead, the approach here is to make clear statements about what makes JavaScript work - what makes it special - and the explanation here is an ideal mix of theory and practice, equally useful for the web developer seeking a better academic understanding of the language and for the classically trained C# or Java developer making sense of JavaScript's idiosyncrasies. Highly recommended as a companion to The Good Parts.

For instance, this kind of description is very concise:

Reference types represent objects in JavaScript and are the closest things to classes that you will find in the language. Reference values are instances of reference types and are synonymous with objects (the rest of this chapter refers to reference values simply as objects). An object is an unordered list of properties consisting of a name (always a string) and a value. When the value of a property is a function, it is called a method. Functions themselves are actually reference values in JavaScript, so there’s little difference between a property that contains an array and one that contains a function except that a function can be executed.

And of course, it is this concision that I appreciate here.

Liquid XML 2014 Beta

For the last couple months I have been using a beta version of Liquid XML, for a number of reasons. I have a laptop, and I find Liquid a little easier to use on a smaller screen than XML Spy or Oxygen, and I have found the support for XML Schemas 1.1 very useful. This is new to 2014, but has been available in XML Spy and Oxygen for a while.

Hopefully XSD 1.1 becomes mainstream. It's just such a complete improvement over XSD 1.0.

With Liquid XML, I can also flatten composite schemas. I have been doing this using CAM Processor, and it's not something I need to do very often; and more often than not, I just roll my own transform for this. Still, it's useful. In the coming year, we are going to see a continuing shift from XML to JSON technologies on both the client and server, but I think this is misleading. At the same time, server-side XML is reaching a renaissance, because server-side validation and transformation are a critical part of client-side delivery of conformant JSON. It's as simple as that.

XPath is the power behind XQuery, XSLT, OASIS CAM and ISO Schematron. Now, it's an important part of XML Schemas; and XPath is developing very quickly, considering most people who are using XPath are still using version 1.0, and yet there are very mature features coming in version 3.0 - so it's still a good time to be working with XML; and it's a great time to be working with JSON as well.

Angular Saxon Summer Update

My side project over the summer started with a premise: using Saxon-CE, the client-side port of the popular Saxon library, on a Firefox OS device. It didn't work on the Simulator, and I worked on some different Mobile Health work on PhoneGap and Android, and then one day, Saxon-CE just started working under both PhoneGap and Firefox OS. A new Simulator had come out, and the stars had aligned.

Firefox OS provides native support for Cross-Origin Resource Sharing (CORS) using XMLHttpResponse (XHR), as well as native support for JSON. I knew that I wanted to use XML, but I was finding JSON useful as well. About this time, I became involved with the Prescription Medication Information Exchange (PMIX) demo, which is part of David Webber's Open-XDX project, which is an extension of OASIS CAM. And it supports both JSON and XML endpoints. I had also been working with HL7 FHIR, which also supports REST, JSON and XML.

So at that point, I had a rudimentary XSLT view which ran as an application on Firefox OS, backed by Open-XDX. Not very useful, considering that Firefox OS devices had not at this point begun shipping commercially (they still haven't). So I turned my focus back to PhoneGap for Android. Without native support for CORS XHR, I needed JQuery and Backbone, and I started down that path; however, this didn't allow me to share code between PhoneGap and Firefox OS, since JQuery and Backbone were over-powered for what I wanted to accomplish.

Then I watched the AngularJS demo video. I had worked with Thymeleaf on the server-side, and the idea of attribute driven directives in the HTML seemed very natural. It is. I have no doubt that these directives will soon find their way into native support in browsers. Try it. It's practical magic, and it works. Better than JQuery, I feel, once you get used to it.

As I worked with these technologies, I started to have a feeling, and I am starting to see that it is more or less accurate: with planning, a common code base can be used with PhoneGap and Native Browser Mobile like ChromeOS and Firefox OS, using a Dependency Injection framework like AngularJS with a templating framework like Saxon-CE. More than this, Angular and JSON shine on PhoneGap, where you are contending with an existing VM, and Saxon-CE runs really slow; on Firefox OS, with native JavaScript, AngularJS is harder to work with and less necessary, and Saxon-CE performs well.

#AngularSaxon #AngularSummer

New Glue: Using Angular and CSS pseudo elements

My overall plan for Rhizome is to auto-schema-generate Views - partial HTML5 ng-includes - which I have bundled up as ordered lists, combined with CSS3 pseudo elements to inject in application labels, positioning of elements and so forth. The idea is that a change to the underlying schemas should require regeneration of the Views, but not of the application.

<ol id="prescriptions">
    <li ng-repeat="prescription in pmix.response.prescriptions">
        <div class="pmpPrescription">
            <span class="pmpPrescriptionNumberText" ng-bind="prescription['pmp:PrescriptionNumberText']"></span>
            <span class="pmpDrugRefillNumberCount" ng-bind="prescription['pmp:DrugRefillNumberCount']"></span>
            <span class="pmpPrescriptionFilledDate" ng-bind="prescription['pmp:PrescriptionFilledDate']['nc:Date']"></span>
        </div>
        <div ng-repeat="prescriptionDrug in prescription['pmp:PrescriptionDrug']">
            <div class="pmpPrescriptionDrug">
                <span ng-bind="prescriptionDrug['pmp:DrugProductNameText']"></span>
                <span ng-bind="prescriptionDrug['pmp:DrugStrengthText']"></span>
                <span ng-bind="prescriptionDrug['pmp:DrugUnitOfMeasureText']"></span>
            </div> 
        </div>
    </li>
</ol>

And then the corresponding stylesheet looks like:

/* Prescription resource labels: */
.pmpPrescription::before {
   content: "Prescription #: ";        
   font-weight: bold;
}
 
.pmpPrescriptionDrug::before { 
   content: "Prescription Drug: ";
   font-weight: bold; 
}

.pmpDrugRefillNumberCount::before { 
   content: "("; 
}
 
.pmpDrugRefillNumberCount::after { 
   content: " refills)"; 
} 

And the resulting screen looks like:

Prescription #:  RX-12453 (3 refills)
Prescription Drug: Hydrocet LOW 5MG

Resource-based Mobile Links:

http://www.dfki.de/~sonntag/ubicomm10.pdf
http://www.goodreads.com/book/show/16674717-the-agile-architecture-revolution
http://sharedservices.lnwprogram.org/sites/default/files/XJC_-_Art_of_the_Possible.pdf 

Rhizome Business Value

Rhizome is a resource-based mobile demo I am building. It was originally intended for an HL7 FHIR connectathon to build out a security layer, and since developed into a companion to the PMIX Open-XDX API demo on VerifyXML.org, demonstrating using mobile JSON and XML.

Rhizome stands for "Resource-based Health Information Zone for the Mobile Enterprise"... the name is intended to be tongue in cheek, and the "R" could stand for REST, "E" for Exchange... but there is a buried meaning here as well: a rhizome like ginger or bamboo is diageotropic, meaning that it grows laterally; and the Rhizome application by design supports concepts like cross-jurisdictional exchange because it is resource- and scheme-based. It goes lateral.

In order to succeed in the enterprise, mobile exchange needs to be built on resource-based open web standards, which support making cross-jurisdictional data exchange work. This doesn't mean that the comprehensive approach taken by HL7 v3 is wrong, but we also need to support less complicated protocols like JSON and REST, using an agile approach towards content creation, consumption, collaboration and curation. Examples of this are projects like GreenCDA, HL7 FHIR and Open-XDX. Rhizome is an example of this also.

French literary theorists Gilles Deleuze and Felix Guattari introduce their A Thousand Plateaus by outlining the concept of the rhizome (quoted from A Thousand Plateaus):

• 1 and 2: Principles of connection and heterogeneity: any point of a rhizome can be connected to any other, and must be
• 3. Principle of multiplicity: only when the multiple is effectively treated as a substantive, "multiplicity" that it ceases to have any relation to the One
• 4. Principle of asignifying rupture: a rhizome may be broken, but it will start up again on one of its old lines, or on new lines
• 5 and 6: Principle of cartography and decalcomania: a rhizome is not amenable to any structural or generative model; it is a "map and not a tracing"

Structure within Angular

I am finding more useful resources for AngularJS, including Christopher Hiller's Developing an AngularJS Edge (Bleeding Edge). What I am going to do here is describe the structure I have come to after a lot of refactoring in my Rhizome application, using AngularJS and Saxon-CE. It's not perfect,  but I do want to document it at this point. I'm using PhoneGap, so this all resides in assets/www:

lib/shared - contains the JavaScript files for AngularJS and Saxon-CE
lib/rhizome/css - contains rhizome.css, references to Gaia css
lib/rhizome/js - contains Controllers.js, PresentationServices.js
res/views/html - contains pmixRequest.html, pmixResponse.html
res/views/xslt - contains PMPPrescriptionReport-application.xslt, other stylesheets

The stylesheets still need some work - I started out building a pure Gaia application for Firefox OS, before porting into PhoneGap for Android, but I have retained some of the Gaia look and feel. I am also considering leveraging AngularUI/Bootstrap for this purpose.

All of my controllers are in a single file, and align nicely with my views. The Presentation Services contains my rendering service and Business Services is currently empty. I am sure I will require some business logic eventually. My main AngularJS module is declared in a script tag near the bottom of my index.html page, and called at the top in the html element.

As far as my views are concerned, I have a pair of partial HTML forms which align with the PMIX Request and Response interactions, and a separate include file for the header, to reduce clutter. I may actually rename the controllers PMIXRequestCtrl and PMIXResponseCtrl, to make it obvious that is what they are. I'm used to HL7, where interactions have well-defined interactions. I like the alignment between controller and partial HTML view.

For the Saxon-CE piece, I have a  separate set of template views. I'm not as happy with these, but they serve a purpose. In the long run, both the HTML and XSLT views should be largely generated from the PMIX CAM schema. I have put these in the res directory because they are resources.

My approach is resource-based, whereas the PMIX data is really not. Three resources are represented in the PMIX payload: Patient, Prescription Report and Prescription. These are clipped out of the response message and then bound to the model scope in pmixResponse.html. This would be cleaner and more RESTful if the PMIX schema was broken into more granular interactions, but that's okay.

JSON vs. XML: Holy Wars and Container Elements

I've been working on a demo based on David Webber's CAM/Open-XDX demo for Prescription Medication Checking (PMIX). Open-XDX offers an easy way to set up a schema-based REST API for XML and JSON. I am building a mobile app with PhoneGap, AngularJS and Saxon-CE.

Originally, my demo mobile application used Saxon-CE with a bit of JQuery to coordinate Ajax calls. I soon replaced JQuery with AngularJS because I wanted a chance to use this framework, and because I liked the name "AngularSaxon". Meanwhile, I was also figuring out a way to embed a Firefox OS build within an Android PhoneGap build.

It soon became apparent that Angular, at 80K, could perform many tasks faster than Saxon-CE, at 800K, and since I had both JSON and XML available, I started shifting my focus, to allow a time trial between the two wire formats. One thing I discovered is that, whereas XSLT can handle something like:

   <Prescription id="1">...</Prescription> 
   <Prescription id="2">...</Prescription> 

...in the specific case where there is only one element, in JSON, this surfaces as the difference between an Array and an Object, which results in problems using Angular's ng-repeat directive. I was able to create a workaround in my JavaScript objects, as detailed below.

I had already created an Angular Service to handle rendering in both XSLT, using Saxon-CE, and in JSON. This Rendering Service already contained an exposed copy of the data returned from an API call, triggering an Angular Controller when the data is ready. I added the following method to the Rendering Service to insert an absent Array for a container element:

   renderingService.fixJSONContainer = 
      function(parentNode, childName) {
         if (parentNode !== undefined) {
            var childNode = parentNode[childName]
            if (!Array.isArray(childNode)) {
                parentNode[childName] = new Array(childNode)       
            }
            return parentNode[childName]
        }
        return []
    }

This helper method is available to the Response Controller, since it has already been Dependency Injected. In the Response Controller, I made the following changes to the render method for JSON:

   $scope.$on('renderJSON', function() {
    $scope.fixJSONContainers(renderingService.data)            
    $scope.pmix.resp.prescReport = renderingService.data[...]
    $scope.pmix.response.prescriptions =
       $scope.pmix.resp.prescReport['pmp:Prescription']
  });
         
  $scope.fixJSONContainers = function(data) {
     var prescriptionArray = 
        renderingService.fixJSONContainer(data[...], 
        'pmp:Prescription')
     for (prescriptionNode in prescriptionArray) {
        prescriptionDrugArray = renderingService.fixJSONContainer(
           prescriptionArray[prescriptionNode], 
           'pmp:PrescriptionDrug')
     }
  }

The local method fixJSONContainers is specific to my schema, and requires intimate knowledge of the schema; where for instance, the CAM elements have makeRepeatable. Other than that, this solution is generic. In my HTML View, Angular handles the data-binding using ng-repeat directives:
 
   <ol id="prescriptions">
      <li ng-repeat="prescription in pmix.response.prescriptions">
      <h3> Prescription #:
         {{prescription['pmp:PrescriptionNumberText']}}
         ({{prescription['pmp:DrugRefillNumberCount']}})</h3>
      <div ng-repeat="prescriptionDrug in 
          prescription['pmp:PrescriptionDrug']">
          <div> Prescription: 
              {{prescriptionDrug['pmp:DrugProductNameText']}}
              - {{prescriptionDrug['pmp:DrugStrengthText']}}
              - {{prescriptionDrug['pmp:DrugUnitOfMeasureText']}}
          </div>
       </div>
    </li>
 </ol> 
 
Once the changes have been made to the underlying Services and Controllers, the HTML View is very tight and concise, which is part of the magic of Angular. Autowired data-binding takes care of the rest.

Open Mobile Web

It turns out AngularJS and it's companion UI framework bundles JavaScript support for Bootstrap, which is fantastic. All you need to do is include AngularJS, AngularUI, and the Bootstrap CSS, and you can say goodbye to JQuery for good, and start building Adaptive Design for the Mobile Web.

I really feel this piece has been lacking; I am very pleased with being able to nestle a Firefox OS app within a PhoneGap app, boosted by Angular. With the addition of Bootstrap, you really can have it all.

What is important here, though, is that all of these approaches intend to make themselves obsolete, leaving behind the promise of Firefox OS... Rich Internet Applications built on Open Web standards (HTML5, CSS), rather than Mono or Flash. In time, the best features of these frameworks will be built into the mobile browser.

Much as I love JavaScript and XSLT, there has to be a better way. I'm really starting to believe that a thin layer of Controller glue and maintainable AngularJS Services is this better way. This is a great time to be a mobile developer.

On the server-side, a resource-based Open Data REST API, Secured Mobile approach should allow us to build mobile applications that mash up resources across jurisdictions, securely and meaningfully.

Mobile Web and Mobile Exchange. This will be exciting.

JavaScript: The Cake and Eating it Too

In my previous post, I started to talk about some of the things I appreciate about Angular, and many of these things, I also like about technologies like Thymeleaf as a JSP replacement, Scala as a Java/Spring replacement, PhoneGap as a native mobile replacement... the list goes on, but what all of these have in common is that (with the exception of Scala, and I will get to that eventually) they leverage and enable the potential of HTML5 by using HTML5 as template and view, a purpose for which it is well suited. In short, these technologies are all  replacements for approaches that are harder to work with, and all come with a self awareness that their purpose is to make themselves obsolete as more standardized functionality comes built in the browser and server alike.

This makes me very happy, of course, because I am excited about the lightweight native mobile web approach promised by Firefox OS and other browser based platforms for the web and mobile. Why is this exciting? Because the developer community for native apps built in HTML5, CSS and JavaScript with a decent framework is huge. I would hazard a guess that Angular JavaScript could be taught in schools very easily, and deployed onto mobile devices, shared with other students using github... it's a good time to be exploring new technologies.

My own personal preference is a sort of best of breed client layer formed by layering Angular JS and then Saxon CE over Cordova (PhoneGap), which I have been referring to as "SaxonCord", although the more I use the functionality built into Angular, the less I rely on Saxon CE as a client layer. For some things, like SVG manipulation or working with XML messaging standards like HL7 CDA or NIEM, Saxon CE is a rockstar; however, these standards are becoming more open, and in doing so, have started to embrace JSON, at which point the autowired data binding Angular provides is really all you need to inject data into a page. I have used client-side Inversion of Control frameworks in Adobe Flex; Angular is just plain easier.

JavaScript: The New Glue

I don't work for Google: but let's talk about AngularJS.


Specifically, I have been working with the JavaScript framework AngularJS recently. When the web was very young, it served static pages, for which HTML was appropriate because browsers facilitated looking at a page and then looking at the underlying markup; learning by view source was viral. Then the web started getting more dynamic, and technologies like JavaScript were introduced to allow for greater interactivity, but they never lost their reputation as "glue code".

Static webpages are a thing of the past. A mature JavaScript framework like AngularJS enables the browser to behave dynamically without hiding a lot of functionality in controllers; this means that the HTML code should still be easily understood at the level of view source. This is what I mean when I refer to the New Glue. JavaScript has evolved beyond "glue code": the real magic is in the autowired data binding provided by the underlying framework

This is nothing new, of course, but I do think it's important to note that use of a framework should allow you to do simple dynamic web pages without a lot of code; CSS can provide some of this as well. If you find yourself writing a lot of controller code for a dynamic webpage or mobile application, ask yourself if you really need this level complexity, or are you coding around the automagic?

The level of investment in a JavaScript framework is very low. Using a best of breed combination of Backbone, Marionette, JQuery, Underscore and so forth can be used to create great results, but requires a reference implementation, and some extra glue to coordinate between different libraries. With a framework, all you need to do to get started is to reference the minimized script from a remote server, and build from there. This really leaves no excuse not to get started exploring frameworks like AngularJS now, and share your work.

#AngularSummer

JavaScript: the Good, the Bad and the Ugly

I recently read Michael Fogus's Functional JavaScript (O'Reilly). I've always enjoyed JavaScript as a language for it's balance of simplicity and complexity. It's a very flexible language, a bit of a hot mess, lipstick on a pig in places; and I still appreciate Crockford's book, The Good Parts, but really, in much the same way I am expecting a move away from libraries like JQuery and approaches that masquerade object-oriented principles in JS, I think that there is a lot to be said for gaining an appreciation for pure declarative JavaScript, which Underscore really facilitates.

I do think that in the future, picking an enabling framework like Ember or Angular will pay dividends, as a lot of functionality like Http/REST/JSON support becomes native and standardized in the browser. On mobile devices, look and feel may be prescribed by an open but proprietary set of styles and widgets. A good framework should enable the user experience, while supporting it transparently with good MV* pattern support for data binding. I really like Learning JavaScript Design Patterns by Addy Osmani, which explores the standard Java design patterns like Singleton, Modules and Observers, and then goes into the different Model View patterns in depth.

Once you take away a lot of the fiddly bits, JavaScript starts to look more like it's original intent - sophisticated and somewhat magical glue that holds together your required controllers. I like Angular because it takes a fundamental design approach that your HTML becomes your View, and contains the hooks that become your Model. With the Model View View-Model pattern, if you are building a lot of complicated controllers, it's possible that what you really need is more auto-wiring and dependency injection - the glue makes it magical.

For a small application, building functional JavaScript with a minimum of additional library support is liberating. For a larger application, picking a mature framework is a good way to go. In the middle, a consolidated platform built out of best of breed libraries may be a good solution, but I would still go with a mature framework. As a development manager, I am always looking for good resources both to help developers make the move from Java development or client-side development using JQuery or ActionScript, to using an appropriate framework or collection of libraries.

All of these books provide a lot of good code samples, but it is also worth noting that the current generation of libraries and frameworks, like Underscore, Backbone, Ember and Angular are terse enough that  you can refer to the underlying source, and also provide excellent references and quick starts for new developers. There is a lot of competition in this space, and good documentation and sample code often separates the Good from the Bad and the Ugly.  

Time to talk about Single Page Applications again?

The phrase Single Page Application is possibly link-bait. It has certainly drawn more comments than any other post I have made, although many of them are in languages with which I am not familiar, discussing products and services about which the less said the better.

Back in 2009, if I referred to a Single Page Application, I was most likely talking about TiddlyWiki, and that has changed now due to the ever-expanding field of mobile development and popularity of HTML5; so that now, if I refer to a Single Page Application, I am more likely referring to a mobile application shell which uses client-side business logic and asynchronous REST to provide a rich user experience. A modern SPA will use a combination of MVW libraries and frameworks like Backbone, Marionette, AngularJS or Ember; wheras TiddlyWiki used a lot of well written sophisticated JavaScript.

My own experiments with Saxon-CE and JQuery in PhoneGap have been very enjoyable, in which case all of your business and presentation logic are bundled into XSLT2 stylesheets, with a very thin layer of Ajax, which really constitutes another framework. In this case, when you take PhoneGap away and replace it with a native web OS (Firefox OS), you are left with a very thin framework for SPA.

To return to the subject of my previous post, if I was to create a "book" as a single page application (and not just use EPub3), this is the sort of framework I would target, for exactly my previous reasons. So from that point of view, I'm very pleased with the way technology is currently evolving.