Skip to main content

The Good, Bad, and Ugly about AMD in Dojo

We were testing iPhora Touch 2 with the attendees of MWLUG 2014 in the MWLUG portal and as usual, the interface had issues even after having outside users provide feedback before we rolled it out.  When you are so focused on the creation process it hard to see issues until it is seen by fresh pair of eyes.  So we are working on a new faster and improved interface for iPhora Touch. This is the evolution of any product.

Since we are using a JavaScript/JSON Restful API approach most of the changes will be on the front end and only minor changes to the back end which is great.  In theory we can swap out different interfaces with little impact on the back end.  This is where the newer AMD approach for Dojo comes into play. The use of AMD in Dojo allows us to modularize the UI components even more than what we had.  Therefore, we have been upgrading all the iPhora widgets from Dojo 1.53 to Dojo 1.10.0 and at the same time upgrading from Bootstrap 2.32 to 3.2 and the latest version of Fontawesome.  The View/Controller of the MVC framework becomes no more than a Dojo widget.  This will be the subject of upcoming blogs.

The AMD approach with Dojo has many advantages, but it also has a number of things that I do not like about it.  For example below is a simple set of code for reading a cookie and adding it to a DOM node and adding a class to a div tag using Dojo.

HTML
<div class="data-display"></div>

Dojo without AMD
dojo.require('dojo.cookie')
var c = dojo.cookie('info');
var node=dojo.query('.data-display')[0];
node.innerHTML=c;
dojo.addClass(node,'show');


Dojo with AMD it becomes
require([
 "dojo/cookie",
 "dojo/query",
 "dojo/dom-class"
],function(cookie,query,domClass){
 var c=cookie('info');
 var node=query('.data-display')[0];
 node.innerHTML=c;
 domClass.add(node,'show');
});
As you notice the amount of code for Dojo with AMD can quickly add up and if you miss a module path/declaration you get an error that won't make sense.  So you need to be careful in defining the path/declaration pair.

But like all good developers, I decided to create a new feature with my development tool to use a template to create my code.   This is where my mustache function comes in handy.  Below is an example of my code template that I have created.



As a result, all I have to do is have my compiler create the Dojo/Bootstrap widgets from the declaration tags, for example <ux:ipField id="hello"/> and assign the appropriate required modules to the assigned mustache tags and do a simple LotusScript find and replace.

However, one critical advantage of AMD is that you can create your own module and include or replace an existing module relatively easily. For example, we needed to replace the Dojo MVC JsonRest module "dojo/store/JsonRest" with our own "iphora/JsonRest" since it does not meet our requirement in how we are doing REST services. We copied the JsonRest.js code modified it and then placed into our iphora directory and now it is loading our module.

require([
 "dojo/cookie",
 "dojo/query",
 "dojo/dom-class",
 "dojo/store/JsonRest"
],function(cookie,query,domClass,jsonRest){
 var c=cookie.get('info');
 var node=query('.data-display')[0];
 node.innerHTML=c;
 domClass.add(node,'show');
});

require([
 "dojo/cookie",
 "dojo/query",
 "dojo/dom-class",
 "iphora/JsonRest"
],function(cookie,query,domClass,jsonRest){
 var c=cookie.get('info');
 var node=query('.data-display')[0];
 node.innerHTML=c;
 domClass.add(node,'show');
});

So we just point the path to our module.  No other changes in the code are required. 

Another disadvantage with the AMD module approach is that you need to be extremely careful if you are trying to create a compressed build of your own modules to reduce the number of http request during the loading process.

With Dojo without AMD, you can easily just concatenate all the modules into one single script file and load that script as part of the page instantiation process. However, Dojo with AMD requires you to create a build using an elaborate process that utilizes a package.json.  This is similar to how npm in nodejs does their builds.  More information can be found in this article.

http://dojotoolkit.org/documentation/tutorials/1.8/build/

Dojo with AMD is more powerful then ever but it just takes a little more work and can be fun!

Comments

Unknown said…
Excellent way to show off the uses of what Dojo's AMD can do for you.

Popular posts from this blog

Creating Twitter Bootstrap Widgets - Part II - Let's Assemble

Creating Twitter Bootstrap Widgets - Part I - Anatomy of a Widget Creating Twitter Bootstrap Widgets - Part II - Let's Assemble Creating Twitter Bootstrap Widgets - Part IIIA - Using Dojo To Bring It Together This is two part of my five part series "Creating Twitter Bootstrap Widgets".   As I mentioned in part one of this series, Twitter Bootstrap widgets are built from a collection standard HTML elements, styled, and programmed to function as a single unit. The goal of this series is to teach you how to create a Bootstrap widget that utilizes the Bootstrap CSS and Dojo. The use of Dojo with Bootstrap is very limited with the exception of Kevin Armstrong who did an incredible job with his Dojo Bootstrap, http://dojobootstrap.com. Our example is a combo box that we are building to replace the standard Bootstrap combo box. In part one, we built a widget that looks like a combo box but did not have a drop down menu associated with it to allow the user to make a select

The iPhora Journey - Part 8 - Flow-based Programming

After my last post in this series -- way back in September 2022, several things happened that prevented any further installments. First came CollabSphere 2022 and then CollabSphere 2023, and organizing international conferences can easily consume all of one's spare time. Throughout this same time period, our product development efforts continued at full speed and are just now coming to fruition, which means it is finally time to continue our blog series. So let's get started... As developers, most of us create applications through the conscious act of programming, either procedural, as many of us old-timers grew up with, or object-oriented, which we grudgingly had to admit was better. This is true whether we are using Java, LotusScript, C++ or Rust on Domino. (By the way, does anyone remember Pascal? When I was in school, I remember being told it was the language of the future, but for some reason it didn't seem to survive past the MTV era).  But in the last decade, there a

The iPhora Journey - Part 4 - JSON is King - The How

  The iPhora Journey - Part 1 - Reimagining Domino The iPhora Journey - Part 2 - Domino, the Little Engine that Could The iPhora Journey - Part 3 - Creating an Integrated UI Framework The iPhora Journey - Part 4 - JSON is King - The Why The iPhora Journey - Part 4 - JSON is King - The How As we mentioned yesterday, in reimagining Domino, we wanted Domino to be a modern web application server, one that utilized a JSON-based NoSQL database and be more secure compared to other JSON-based NoSQL platforms. A Domino document existing within a Domino database is the foundational data record used in iPhora, just as it is with traditional Domino applications. But instead of just storing data into individual fields, we wanted to store and process the JSON in a Domino document.  However, text fields (AKA summary fields) in Domino documents are limited to only 64 KBytes, and that is a serious limitation. 64 KBytes of JSON data does not even touch what the real world typically transfers back and fo