Chariot Training Classes

Training Courses

I run Chariot's training and mentoring services. We provide training in AngularJS, HTML5, Spring, Hibernate, Maven, Scala, and more.

Chariot Education Services


Chariot Emerging Tech

Learn about upcoming technologies and trends from my colleagues at Chariot Solutions.


Chariot Conferences


Entries in dojo (2)


Dojo 1.7 is quite different

I've been having a lot of fun dodging and perrying through a full Javascript UI for Quizzo. I know, it sort of subverted the original intent of getting it out there fast, but I'm thinking there is a good Roo add-on lurking in here. Specifically around controlling the actions of the Quiz - somehow I need to let all of the players know that the time is up for their current question, or that new scores appeared, or any number of other things.

I could poll, but I'm thinking that would be expensive. Sure, you can use setInterval(ms, function) and ask every four seconds, like I'm doing now (quite amatuerish, I'm sure but then that's what I am in the JS UI department at the moment):

 function (dom, registry, xhr) {

   pollScores = function pollScores() {
       url: "${quizzo_scores_url}",
       handleAs: "json",
       load: function(data) {
         var yourScore = dom.byId("scores");
         var targetStr = "";
         yourScore.innerHTML = "";
         data.score.forEach(function(scoreValue) {
         //TODO - make this nice with spans and a div for each score instead
         //TODO - put on rhs in layout
         targetStr += + " : " + scoreValue.value + "<br />";
        yourScore.innerHTML = targetStr;

       error: function(err) {
         dom.byId("yourScore").innerHTML = "error.";

... later that same evening ...

window.setInterval(pollScores, 4000);

But that would be rather inefficient. However, for those looking to manipulate some DOM elements, call some Ajax, and update parts of HTML using Dojo 1.7, at least it's some useful information, so I'll post it.

Instead of polling, communicate on channels

Our CTO Aaron Mulder talked about WebSockets at our Chariot Day last weekend. Other developers in our group including Don Coleman and Steve Smith have been using jQuery UI, jQuery Mobile, Sencha Touch, etc., and tools like Handlebars.js to provide data bindings and other features.

But since I'm investing some time in Dojo and related projects, I want to see how far I can dig and what I can offer to the Roo community from this research. So, I found a project that the Dojo foundation has been using, CometD which in the most recent versions supports WebSockets as a transport medium. It's an asychronous communication mechanism for subscribing to and publishing messages without forcing programmatic polling.

My initial goal for server-side push is to broadcast messages on a hub-and-spoke pub/sub channel, broadcasting these events:

  • Updated scores
  • General messages from the quiz master
  • Change of game state (team registration time, question available, voting open, voting closed, results, end of game)

Maybe the third one needs some refinement, especially since it could be tough to make sure the clients actually got the messages. But at least it's a way of making the control of those activities a little more coordinated.

What's in the repo now?

So far, I've migrated the code for the admin/moderator and quizzo URIs to use Dojo 1.7.2, and embedded 1.7.2 as a library in src/main/resources. The tests still fail on some machines, so -Dmaven.test.skip=true is a necessity. Also, if you're playing around you may need to change the persistence.xml to create schema elements at first, then go back and change it back.

The UI is NOT ready.

If you have a spreadsheet of questions and answers, you'll find that handy class in the test directory as well.

I'm going to focus on making the question/answer views, using polling for now (because it's easy) to check on the current project state. I'll post when I have it working (soon).

Next, I'll event-ize the moderator communications.

This will end up generating one or two add-ons, I'm sure. Of course, I'm under the gun for my ETE presentation and need some additional add-ons to show off, so synergy will be my friend.

Watch this space.


Quizzo - it's THURSDAY? Must go into the Dojo and meditate

You know how if you don't have anything nice to say, don't say it at all? Mmm hmm... Except it was a conversation with myself that started "why the heck don't you know THAT?"...

Where the heck were you?

Ok, ok, I was busy with my day job. Training at Chariot is really getting busy, which is great because I run that group! If you're looking for public or private training in Spring, Maven, Hibernate, and a number of other technologies, check us out.

Shameless plug-meister, what are you doing with the quizzo??

Ok, it's back to reality. I've been taking an alternate path with the quizzo UI. Since Chariot Day is a chance to stretch a bit, I figure I'd do the admin and perhaps main front-end as a rich Javascript UI, Roo-style. That comment about not saying anything nice? It was about a library I wish Roo would leave behind. It's called Spring Javascript.

Spring Javascript?

If you're thinking "Cool, a Spring Container in Javascript" - a) stop RIGHT there, dude, and b) it's not what you think. c) that's pretty nifty, but I understand there is a movement out there for MVC and strong binding in the Javascript community. I know nothing about it, but some of Chariot's mobile team do. Read here, here, here, here, and oh, here. Did I mention we're a consulting firm?

Spring Javascript is a Javascript library written for the WebFlow project. The idea was that if you wanted to roll out client-side validation, ajax forms, or any widgets from a Javascript toolkit, you'd use this library. It also has this wrapper around doing partial rendering of Ajax Tiles (or JSF fragments, I think). Nifty.

The Spring Javascript library is a thin wrapper around a Javascript toolkit called Dojo.

Bow to your Sensai - what is Dojo?

Roo's view layer heavily uses Dojo. Those neat little client-side validations? Dojo. The panels with the little titlebars? Dojo - that's the dijit.layout.TitlePane.

The reason for choosing Dojo makes sense for me. At the time it was a very comprehensive widget toolkit and in 2008 it was gaining in popularity. Just look at the date of the books published and you'll get the idea. Sitepen is a supporter of the library and IBM and a number of large organizations use it. It has a great open community as well, and is funded by a not-for-profit organization.

But then a lot of developers turned left at jQuery. The focus has been on a more wide-open platform, with the curation of components being primarily the user's job. Think "platform-and-plugins" and you're on to it.

Dojo hasn't changed their approach. In fact, I really like the concept of how they focus themselves on curation, incorporation of experimenta components into an extensions library, and the coherence of the whole library.

So, what about Spring Javascript

The reason I'm not a fan of Spring Javascript is that it is kind of an artifact of where the thinking was in 2007/2008, and hasn't moved on. Spring Javascript hides about 40% of the construction of Dojo widgets (known as Digits (dijit)). But it's a leaky abstraction; you need to know Dojo to program it after all, and Roo only really uses it for validation sugar.

Here is a Spring Javascript snippet to create a title pane, which you can find in WEB-INF/tags/utils/panel.tagx:

    <div id="_title_${sec_id}_id" class="panel">
      <jsp:doBody />

I've highlighted the lines where Dojo isn't hidden. You're mounting a Dojo TitlePane, and to do so, you need to know:

  • The Dojo specifics of the class
  • The various attributes of the widget
  • What widget (dijit) to import

So, not really encapsulating the framework.

How Dojo wants to be used

Dojo is a flexible framework. It has at least three ways to use it. First, you can programmatically create a component like a title pane.

In Javascript:


  var tp;
      tp = new dijit.TitlePane({title:"Quiz Administrator", content: "Show my content here"});

In HTML with a page parser (this is the pre-Dojo 1.7 version):

  <div dojoType="dijit.layout.TitlePane" title="hiya dude">
     <p>This is content for my title pane</p>

And in 1.7 and above using the new html 5 data attributes:

  <div data-dojo-type="dijit.layout.TitlePane" data-dojo-props="title: 'hiya dude'">
     <p>This is content for my title pane</p>

So, where's the pain?

Ok, so a couple of problems exist for me when trying to RIA-ize a Roo application:

Dojo != Spring Javascript

The Dojo toolkit is under constant update We're on 1.7.2 in the community, and they are moving into mobile, HTML 5, media controls, etc. Spring Javascript embeds a custom build, and the most recent version isn't currently rolled out in Roo. In fact, I don't think there are plans (as far as I know) to upgrade Spring Javascript to 1.7.x, nor to update Roo. I will check with the Roo team to see what they are planning here.

People coding in Javascript shouldn't try to hide it. I'm not yet a fan of CoffeeScript or other frameworks that hide those things from you, because I think Javascript is such as quirky animal that dealing with it directly is probably better than not dealing with it, or working behind a veil.

Dojo is in transition

Because it was old, I decided to upgrade to Dojo 1.7. I gave up after a day because Dojo is transitioning to a new, bitchin' ARM (dynamic loading module system) that looks to be the bee's knees. Keep your eye on Dojo once this gets fully documented. They have curation, they have a consistent movement forward, active IRC channel, etc., and so I think they will really have a nice product here. However, I can't understand it, know the 1.6 and below model, and the documentation is not updated completely. So I was swimming in it.

We need a super-simple ui mechanism for Roo apps

I'm sorry, but I'm a minimalist. If I don't need it, it's outta here. And the view technologies in Roo should be pluggable. I think we should be able to do commands like:

roo> web mvc riatags add --toolkit dojo|extJS|jqueryUI|jqueryMobile

Scaffolding is in the way

I also think the scaffolding in Roo should be forward-only. Let's face it, how many times do you really keep the scaffolded UI on? For an admin tool, sure. But for anything commercial, it just takes too much to unwind it.

In addition, I think the messages/properties localization should be optional, or at least 100% transparent to me. In other words, the div id is the full div id, the message id is the full message id, period. It NEEDS to be simpler.

Finally, if I decide to modify my view resolution system, move to straight JSPs and ignore any bi-directional sync, I want Roo to keep hands off. I'll have to post a JIRA on this, but I think I ran into trouble where Roo adjusted my webmvc-config.xml file settings if I removed a few things once I tried to scaffold again. No biggie as I'm sure this isn't something planned on, but I think the bi-directionalness is great in the code layer, but not in the UI.

You seem tired

It's gonna be dawn soon and I'm thinking too much. I am really keen on moving Roo forward and working with the team to help set the agenda for Roo 1.3. All of this is adjustable by writing Roo add-ons and some minor adjustments to the current ones. And Roo saved me many hours on this project so far, and it will continue to do so.

So, big mouth, what have YOU been doing?

If you look in the GitHub repository, you'll see that I'm building a (currently AWFUL LOOKING) Dojo interface at /quizinator/admin/moderator. That controller does Ajax JSON request handling, and the index view is a small tab-container Dojo application.

More on this when I've had sleep and have implemented more. I may keep the actual quiz-taker UI in Spring Web Flow, and use Dojo for some Ajax there. But I like having a moderator tool that is a true Javascript client.