Tuesday, July 30, 2013

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.

Monday, July 29, 2013

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.

Sunday, July 28, 2013

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.

Monday, July 15, 2013

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.

Sunday, July 14, 2013

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

Saturday, July 13, 2013

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.