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 javascript (2)


Eclipse (or STS), Javascript, SPA and me... An open rant

Ok, I just sent out a tweet I'll probably regret. But let me state my case: there is only one traditional editing company that 'gets' Javascript IDEs right now in the world of Single Page WebApps - and that's JetBrains. The other option is VIM for me... Or Brackets (AWESOME tool). But I want my CTRL-SPACE code fill-in.

I've been running a training course that involves a JavaScript Single Page Web Application (SPA) in AngularJS. Like many of these platforms, it involves mounting a number of other JavaScript libraries, and they are generally mounted in a minified way unless you need to debug into them (long debate I'm side-stepping here).

My tweet about 30 minutes ago seems to have gotten legs, and I'm about to duck under an earthen barrier to avoid the flack:

Whomever has power over STS and Javascript tooling, can you play nice or integrate with JSHint and ignore my minified SPA libs?

Here is my challenge:

Given a Javascript-fronted single page Web Application, I want:

  • Ability to run my SPA in a simple HTTP server quickly
  • Instant editing of my application scripts with JSHint right there in the problems panel, without redeploying or caching issues
  • Strongly integrated maven-based tools for hinting with JSHint
  • Strong integration with GruntJS - it's the Javascript ANT tool now
  • Integration with Bower to index the source of repositories that we've downloaded
  • Integration with NodeJS's dependencies to install tools, etc...
  • Native integration of Jasmine and Karma (if I have NodeJS integration) to run the tests, or maybe a test generator plugin to generate the test runner on the fly

Is anyone in Eclipse-land working on this? The closest I've gotten to Javascript happiness is using WebStorm. But it doesn't support these tools directly (I have to execute them from a command prompt panel). I love WebStorm for its strong tooling, but even that one is missing Grunt as a plugin.

For clients who need to stay on Java-based build tools (because they're not switching their backend to Node/Express) but who are moving into SPA + RESTful Spring/Java EE apps, I think we'd see good adoption of a forward-leaning Eclipse (since it is kind of the enterprise developer's lingua franca).

Am I off the mark here? Tell me so in the comments...




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.