Archive for the ‘Javascript’ Category

Dojo Toolkit Slim Build

Hi everyone πŸ™‚

Well if you ended up here I guess you have been, like me, looking all over the dojo docs, and even the whole internet, to find how to build a small custom dojo build.
I needed that myself for my current project

First of all, my own background is from traditional IT,Β  down to the machine,Β  with compiled languages. So when I hear “build” I understand to get a bunch of files and put them in one unique, nice, compressed, easy to transfer, fast to run, almost magic file.

But that’s not what it means with dojo 😦 I guess that coming from the web, where you have files and requests online all the time, the standard is more to have all your mess on a server somewhere and not worry about it. There fore a “build” is only an optimisation, a way to reduce the mess… that ultimately still remains around. And that’s what happens when you do a standard build with dojo, all files are copied anyway, just in case something would be missing…

    However, when I am building a web-app, I am also thinking of what if :

  • my external network goes down, and I still need to access all my resources.
  • I want to port it to another platform
  • I want to be able to have everything offline on a USB disk and I need it to work even if I am not connected
  • etc.

And for all these reasons, what I want is only one “mydojobuild.js” file. But sadly very few docs on the web try to achieve that goal.

    After a few days of trying a bit everything, here is what I ended up with :

  1. a built “dojo.js”
  2. a few “nls/nls_<locale>.js”


    First a few things that are quite usefu to know, but it took me some time to understand :

  • The command line options for the build can also be included in the profile file. Pretty useful if you want to script the whole process like I do.
  • Even though your profile specifies only one layer to be built, the dojo build system will always build at least a dojo/dojo.js (and usually also a dijit/dijit.js and a dojox/dojox.js I think – even if you don’t care about it) anyway. So if you want all your dependencies in ~*one file*~, you have to put them in dojo/dojo.js.

And here is how my build profile looks like :

dependencies = {
    stripConsole: "normal",
    action: "release",
    mini: true,
    optimize: "shrinksafe",
    layerOptimize: "shrinksafe",
    releaseName: "my_dojo_build",
    // list of locales we want to expose
    localeList: "en-gb,en-us,fr-fr",
    layers: [
    //Custom build of the mandatory dojo.js layer
        name: "dojo.js",
        customBase: true,
        dependencies: [
    prefixes: [
        [ "dijit", "../dijit" ],
        ["dojox", "../dojox"]

Pretty small and maintainable πŸ™‚

I build it with :

cd dojo/util/buildscripts && \
    sh profileFile="path_to_my_profile" log=WARN version=1.6.1 

Then I only need to get the dojo/dojo.js file, as well as the dojo/nls/dojo_* for localization.
And because, believe it or not, I test my application before deploying it ;), so if I miss a dependency from dojo, I will see it and fix the build profile. I don’t need all the files that the dojo build put around (but I didn’t find any option to disable this step in the build yet). Ah and just in case you are wondering, yes localization files are separated and will remain out of the dojo.js because if I am speaking french I don’t want to load all languages at runtime…

I am now pretty happy with my solution, as I can run the build and extract what I need with a simple waf script, in the configure method, such as:

#finding dojo mandatory layer
dojobaselayer = dojobuildnode.find_node("dojo/dojo.js")
if dojorelnode is None :
    conf.fatal("dojo/dojo.js mandatory base layer was not found " + \
               "in build directory. Cannot continue.")
dojobaselayer_uc = dojobuildnode.find_node("dojo/dojo.js.uncompressed.js")
if dojobaselayer_uc is None : 
    conf.fatal("dojo/dojo.js.uncompressed.js base layer was not found " + \
               "in build directory. Cannot continue.")

# Finding the scripts folder where to put build results
scriptsnode = conf.path.find_dir('htdocs/scripts')
if scriptsnode is None : 
    conf.fatal("htdocs/scripts/ subfolder was not found. Cannot continue.")

#copying mandatory dojo layer
conf.start_msg("Extracting Dojo built layer" )
conf.end_msg( scriptsnode.find_node(
conf.start_msg("Extracting Dojo built layer - uncompressed" )
conf.end_msg( scriptsnode.find_node(

#extracting localization resources
dojonls = dojobuildnode.find_node("dojo/nls")
if dojonls is None : 
    conf.fatal("dojo/nls for mandatory base layer was not found " + \
               "in build directory. Cannot continue.")
conf.start_msg( "Extracting Localization resources ")
scriptsdnlsnode = scriptsnode.make_node("nls")

#copying localization resources from the build
#excluding default copied file by dojo build process
for fname in dojonls.ant_glob("dojo_*") :
    shutil.copy( fname.abspath(), scriptsdnlsnode.abspath())
conf.end_msg( scriptsdnlsnode.relpath() )

DISCLAIMER : I cannot guarantee that the script up there will work. It’s python, and I had to re-indent it to fit in here… So you might have some quick easy syntax fix to do if you copy it.

Well that’s it for now. Dojo is pretty slim and I am happy as it s not so heavy to move around any more.

    Two things I still need to investigate:

  1. How to embed dijit themes in a build. That should be possible, as I saw some reference one the web, but no example so far… So if you have a clue, or any question, just let me know πŸ˜‰
  2. How to rename the dojo.js file and the matching pathname in js code. That should be possible with the scopeMap option, that can map dojo.* to mycustomname.* However I ll need a lot more tests to make that work properly I believe

And now you can go explain to your dojo build how to go on diet πŸ˜‰


Some experimental geek time again…

2011/07/30 1 comment

Hey everyone,

Since I was quite busy these last month working on Toonracer at BigPoint I didnt get time to work on my personal projects much…
I am also still working on FDPoker with the fairydwarves available on the chrome store , and wondering how make a little bit of money from it, in order to get enough time to improve it.

And as I am looking for my next assignment, job, or contract,Β  I recently experimented gradle and webapp deployment in tomcat. In two days I had a basic build and deployment process running, which indicates to me that gradle is a good candidate as a build system if I ever do any java again. I had a quick look at groovy, but the fact that many things are implicit ( or is it only gradle ) is still quite disturbing to me, as it means you need to understand everything before you look at some code. I prefer when it s the other way : you look at the code first, and then from the code you can understand how things work.
And for Java, I still think that either you do something properly in C++ and it runs everywhere you test it, or if you want really scalability and lots of other nice features, you’d go for erlang for back end, or web based for front end, since it seems to me that the future is that way.

While I have been experimenting with javascript to make a poker game I came to the conclusion that OOProgramming is useful, at low level. When you do functional or higher level programming, you need to organise your code differently. Javascript being functional, I will need to spend time to rewrite the Poker code that I wrote in an imperative style ( as I was used to on C++ ).

I am also wondering if prototyping things with Node.js could be a good option for later erlang programming ? maybe the way python is a good prototyping technology candidate for C++ project, as you can migrate from one tech to the other step by step…

So as I am still interested by Distributed Game Engine Designs, I am thinking that designing a quick javascript game engine on client side first could be a good step towards that goal. It will also be used in small web games, to keep it active and maintained. Then some parts could be move to a Node.js based backend. Experimenting with this system could be a good way to get a better understanding on how to design and write a distributed game engine, at a relatively low cost ( given the size of the project). It would also be functional so we can hope to make it scalable easily by switching to erlang later on when needed ( erlang-js could also help there ).

I am at the moment working on FDPoker, understanding what makes code maintainable and yet efficient in javascript.
FDPoker - First MenuFDPoker - Table screen
As you can see all the display is there and input is also working in different browser and web engines, on different platforms.
We are primarily using the dojo toolkit and dojox.gfx so we dont worry about implementing for different browser, versions of web standards, etc.
And while we dont have time to test a lot of different platforms, we were developing the engine to run on top of the EFL libraries.
It has been working ok so far for us, but on our platform for deployment ( Freebox ) it was tricky to get things right… And It seems they had enough problems to justify dropping the support of the EFL in the last version of the Freebox… but anyway no matter where that project goes, by building a solution on top of javascript we should always be able to run on most platforms.

However this little javascript engine is not very reactive yet and supports only gui-based interaction. As soon as we can get some income, then we will turn it into a full 2D game engine, client-side, in javascript. With similar features than the one in Project0 (which is based on SDL).
The more money can be made with FDPoker, the more nice features could be developed in the next javascript engine, preparing for the next game πŸ™‚

So if you want to help fairydwarves making better games, please do not hesitate to tell us you love us πŸ™‚