Dojo & Javascript findings

Rails 2.2 + Dojox.data + Dojox.grid

2009-03-05T16:13:00.000-08:00

I'm interested in taking the speed of rails and displaying in the very ajax way's of dojo.

Some quick pointers on getting the backend to play nicely with the front end.

1. In your rails app go to Configuration -> Initializers -> new_rails_defaults.rb
2. set the following to false: ActiveRecord::Base.include_root_in_json

Reason being that the response when encoded to json, natively will have the object name preceding every item in the returned list where as dojo.data just wants the items listed in an array.

eg.
Native: [{something:{data:1}}. {something:{data:2}}]
After change: [{data:1},{data:2}]

3. In your controller copy the format.xml line in each block to a line just below and change the .xml to .json and "render :json". This gives the controller the ability to respond to JSON requests.

eg:

format.xml { render :xml => @something }
format.json { render :json => @something }

4. use the dojox.data.RailsStore in your javascript. This will tag ".json" on to your requests and correctly set header information for JSON interaction.

At this point you should be able to create a dojo.data store and connect it into a widget to see some results.

The last thing is that the store will have functionality for querying and sorting. This isn't in the default rails controllers and is the next thing I'm working on for a good solution.

Be aware that Rails as of the 2ish version will happily work with JSON so requests to and from the server can be handled without the need for plugins.

To get a service going is as easy as:
var store = new dojox.data.RailsStore({target:"/something"});
where in this case something is the base REST path.

Note that writing back to the server with dojo.data doesn't not currently work as the message sent is the plain data object where as rails wants the object to be named. Ie

We send: {data:1}
server wants: {something:{data:1}}

as a quick hack, changes to the dojox.rpc.Rest class can be made look at the method (drr._change). This is too much of a hack at the moment though and I'm looking for a better way.

Dojo..not in 6K but comparable to JQuery

2009-02-19T17:12:00.001-08:00

Firstly, I think fundamentalism when it comes to the JS library selection is a really poor way to go. I prefer the positive competition and innovation that comes from multiple libraries in development. However JQuery is being heavily used by a vocal web community that parts of which seem very quick to throw out negative (and now incorrect) ideas about other libraries, including the Dojo toolkit.

JQuery has the many positives including that it's all about DOM work, it's exceptionally fast (which is why everyone is looking at 'sizzle') and it's relatively small. This is what John meant it to be and he's really stuck to his vision. But others have started coming in with plugins and this is where I feel things are less clear.

People say JQuery is small, and for the core it is. But if you load plug-in code along side it then the total code is not as small. Now conversely people say Dojo is big.. but in truth the core is fairly small. It's when you load the code to support features such as widgets that things get bigger. So the ideas here are a little misleading.

In an effort to investigate dojo's big-boned reputation I decided to see how small we can make things. So where are we to start with? A basic dojo build makes a core dojo.js file that includes the full _base weighing in at around 80kb. This compared to JQueries 54kb is a little heavier.

I found the article describing dojo-mini which is how to make a small build of dojo. But I'm looking to it's heart. What about those guys that pull in JQuery, make something fade out and scream "AH HA! BEST LIBRARY EVER!".

So here's what I did. I found the "Dojo in 6K" article. A promising start as we can load up the core dojo in a ridiculously fast way. I particularly like the "stubs" idea.

This however still spawns off numerous requests if I want to get in "dojo._base.fx" for some basic animation work. So next off we turn to the build system. Here I created the following profile:


dependencies = {
 layers: [
  {
   name: "dojo.js",
   customBase: true,
   dependencies: [
    "dojo._base.window",
    "dojo._base._stubs"
   ]
  },
  {
                        name: "_baseFx.js",
                        customBase: true,
                        layerDependencies: [
                                "dojo.js"
                        ],
                        dependencies: [
    "dojo._baseFx"
                        ]
                }

 ],
 prefixes: []
}

Note there is no inclusion of the dijit or dojox prefixes. We're going for tiny animation grade system here. Note also that I'm using the "stubs" file for my main dojo.js file.

Next up the dojo._baseFx file:


dojo.provide("dojo._baseFx");
dojo.require("dojo._base.fx");

Here all we're doing is including the core fx file and this file will be rebuilt so we can include it via dojo.require() later.

One last change. When you build using profiles that use "customBase" there is a new regex approach to making sure you don't produce a bad build. The build system reads your code looking for references relating to _base you may have forgotten and throws them in. This system called "injection" is not what we're after here. Hence I modified the file "jslib/buildUtil.js" in the method "buildUtil.addGuardsAndBaseRequires" added the line "needBaseRequires=0;" to the top. This means we always ignore the injection for now. Note this means builds may not always have what you need so there's a level of developer responsibility that comes with turning off this helpful code.

Finally we run the build. This will produce a dojo.js file that for me was about 17k. And a _baseFx.js file that was around 28k. It also moves over the other dojo code but for something to fadeIn / fadeOut I just want some key files. I copied over the two mentioned files along with the _base directory and we're now ready to go.

In the HTML I included dojo.js in the usual way and then added the following:


dojo.addOnLoad(function(){

dojo.require("dojo._baseFx");

dojo.fadeOut({node:"nodeName"}).play();

})

When the page is ready the addOnLoad causes the extra code to load (baseFx) and then instantly uses it to find a node called "nodeName" and hide it with a nice fade out effect.

This not only works but does something that JQuery currently does not. It lazy loads over half of the code meaning the page will appear very quickly for an end user after the 17k initial dojo.js load and while they are sitting there thinking what to do next the remainder of the code is pulled in. In reality this happens faster than you can think and if sent over the wire with gzip the code content will be even tinier.

Remember back to the stubs though? why did we do that? Well it's a safety net. Say we follow up the previous code with:


dojo.addOnLoad(function(){
dojo.query("something").innerHTML = "blah";
})

dojo.query is not currently in our environment due to the small custom _base. But the stubs package knows that any call to query should load it. The code is loaded as it is needed and we carry on.

For web applications this approach isn't really optimal. But for the designers out there that complain dojo is too bloated to be used for simple web page work, think again. 17k and Dojo is usable. A moment later we're animating.

Don't get me wrong, John Resig continues to amaze me with his work and JQuery in general. But I'm really hoping one day people will stop uttering things about Dojo that just aren't true, especially not on a podcast (Rubyology Ep73).

Final thought
- JQuery 1.3.1 minified = 54Kb
- Dojo (as above) 17Kb loader + 28Kb baseFx = 55Kb
(To add lazy loading to JQuery)
- 54kb JQuery 1.3.1 + 3kb xLazyLoader = 57Kb

To load the page initially with Dojo in the above way you need to load 17Kb
To load the page initially with JQuery + loader you need 57Kb

Polymorphism

2008-10-14T23:34:00.001-07:00

I love that word.. anyway, I stumbled on an article by John Resig that I'd read a while back talking about method overloading in JS.

Looking through the article and comments was quite interesting and inspired me to write this down just in case I feel the need to revisit the topic one day.

Edit: I extended the "Object" prototype previously.. a big no no but one that made proof of concepts quick and easy.. I've updated the code to follow the JR way of leave JS objects untouched.

var poly = {
 addMethod: function(object, name, fn){
  object._store = object._store || {};
  object._store[name] = object._store[name] || {};
  object._store[name][fn.length] = fn;
  object[name] = function(){
   if(object._store[name][arguments.length])
     return object._store[name][arguments.length].apply(this, arguments);
   else
     throw new Error("Wrong number of arguments");
  }
 }
}

I noticed if you were to borrow the function via call or apply the scoping would go badly so I used some closure hackery to preserve this. It's possibly a bit suspect but it works.

Usage and example of scope preservation:


var n = {name:"I am n"};
poly.addMethod(n, "getName", function(){ return (this.name);})
n.getName()
>>I am n
var s = {name:"I am s"};
s.do = function(){ return n.getName.apply(this, []); }
s.do()
>>I am s

Kicking the dijit toolbar up a notch

2008-08-03T21:17:00.001-07:00

I love that dijit has a menu system built in using dijit dropDownButtons and the dijit toolbar. I don't love that interacting with a mouse requires more clicking than the native windows menu system most users are familiar with.

The key is that the dropDownButtons work independently from one another. Click one and that menu shows, hover over the next menu and you can see focus but it doesn't show the menu till you click on it. Under windows once we click a menu open, everything starts responding to a hover event.

Rather than grumble, I decided to fix this behaviour:

dojo.declare(
 "widget.DropDownButton",
 dijit.form.DropDownButton,
 {
  respondToMouseOver: false,
  
  postCreate: function(){
   this.inherited(arguments);
   dojo.connect(this, "_openDropDown", this, "_updateRespondOpen");
   dojo.connect(this, "_closeDropDown", this, "_updateRespondClose");
   dojo.connect(this.domNode, "onmouseover", this, "_respondToMouseover");
   dojo.subscribe("/dropDownOpen", this, "_setRespondState");
   dojo.subscribe("/dropDownCloseAll", this, "_closeDropDown");
  },
  _setRespondState: function(state){
   this.respondToMouseOver = state;
  },
  
  _respondToMouseover: function(){
   if(this.respondToMouseOver){
    dojo.publish("/dropDownCloseAll", [true]);
    this._openDropDown(arguments);
   }
  },
  
  _updateRespondOpen: function(){
   dojo.publish("/dropDownOpen",[true]);
  },
  _updateRespondClose: function(){
   dojo.publish("/dropDownOpen",[false]);
  }
 }
)

Here the buttons work as a team. When one opens it lets the others know its time to respond to the hover. When one closes due to clicking off the focus or selecting an option it keeps the others in the loop and they stop worrying about the hover. Dojo's pub/sub is a wonderfully simple networking tool for your widgets.

JavaScript + Rhino + SQLite + Dojo + Jetty +..what's left?

2008-07-13T22:51:00.001-07:00

As a small side project I decided to see what things would look server side if JavaScript was the driving force.

I'm using Rhino (Mozillas JavaScript interpreter) to start the ball rolling, get a Jetty server instance up and load some dojo into the background for the hell of it. From there you can open up a SQLite connection to a local database and start writing things out via servlets.

My driving force was what does a server have to be these days? given that JavaScript libraries such as Dojo, YUI, EXT and JQuery UI are all creating extremely dynamic front ends, we're leveraging server-side rendering technologies less and less. In fact they are starting to conflict with wanting to do the same things. So if all I need is data from my server, then all I need is some clever servlets and a hint of JSON.

So from my simple hackery I have the basics working. It's not robust, scalable or designed to handle enterprise smarts. But as an after hours proof of concept it's an odd and cool feeling to think I can build a servlet response with JavaScript that is reading database objects from a tiny local DB and spitting it straight to JSON.

Oh and since all of it is hosted in java I've been developing this on Windows, Ubuntu and an OSX box. Amusingly Jetty and the DB are smaller than the dojo source install I'm using. Note you have to grab the source install of dojo if you want load it in Rhino. The source is intentionally stripped down on release to work only in browsers.

So the trickiest thing so far has been figuring out the Jetty API. Damn thing keeps changing leaving some of the tutes to be misleading. As I gradually become more familiar with it, it's becoming less of a hassle.

Dojo.query, dojo.Nodelist and Chaining Actions

2008-06-12T19:06:00.000-07:00

I've recently becoming more and more reliant on dojo.query for finding the nodes I want to work on. Gone are the days of trying to cleverly use name and id as the only two distinguishing features of a node. Now we can use almost any attribute on a node. To see how this can be useful I'll talk about a recent case.

To begin with we are given a HTML form that is arranged so that there are lines of input elements and at the beginning of each line is a checkbox. The checkbox is used to enable or disable a row of elements depending on its checked state.

To do this in the old days we could either assign some id's to the nodes and do some string manipulation on the id so that items like "row1_1, row1_2, row1_3" were toggled (not pretty) or we could walk the dom tree and start going through parentNode, childNodes etc checking tagNames and so on. This is pretty hard work. Lets see how it could be done with a hint of dojo.

if our row looks like the following:

<div>
  <input type="checkbox" class='checkboxTrigger'>
  <label for='asd'>Test</label>
  <input type="text" />
</div>

What do we want our code to do to it? Well when the pages loads, we need to disable the entry fields, uncheck all checkboxes and setup our events so that clicking a checkbox toggles the rows state. Right.. time for some code

var formHelper = {
    toggleRow: function(e){
        this.toggleNodes((!e.target.checked), e.target.parentNode);
    },
    init: function(){
        dojo.query(".checkboxTrigger").onclick(dojo.hitch(this,this.toggleRow)).attr("checked",false);
        this.toggleNodes(true);
    },
    toggleNodes: function(status, rootNode){
        rootNode = rootNode||dojo.body();
        dojo.query("input:not(.checkboxTrigger):not(.submits),select,radio", rootNode).attr("disabled",status);
    }
}
dojo.addOnLoad(dojo.hitch(formHelper,formHelper.init));

What do we have here? Lets walk through how the page uses this code.

We can see at the end, a dojo.addOnLoad is used to link up the formHelper.init function. We wrap that with dojo.hitch to make sure that when the function is called by the window onload event, any references inside the method correctly know that "this.{method}" means "formHelper.{method}", not "window.{method}". You'll have to trust me on this one and if you want to know more, look up "scoping"

When the init is called we use dojo.query to get all the elements on the page that use the style class "checkboxTrigger". Easy. On those elements we setup an onclick action that points to the "toggleRow" method. Again see the use of hitch to keep the scope in check. Notice what's next? straight after the onclick we can call the further ".attr" method to set the checked state on the nodes. This is because query and it's methods keep returning Nodelists, so we can keep chaining the calls.

Next we call the toggleNodes method. This methods goal is to set everything other than the trigger checkbox nodes to be either enabled or disabled. Note that in this method we are doing a query for all inputs that don't have the checkboxTrigger class and that don't have the submits class. I put the submits style class on the save and cancel buttons to make sure that they're never impacted upon. Also note that this query can grab other things like select boxes etc. On each of these nodes we simply set the disabled state via the "attr" method. Also note that if we don't give it a specific node to focus on we just apply the query to the body.

Finally the toggleRow is simply a wrapper to toggleNodes but with the additional step that we pick which row to dojo.query inside. That is we narrow the search for nodes to toggle to one row.

And that's it. The code can be dropped on to any page of a similar structure with the right class names. You can also add / remove the number of form elements in a row without worrying about changing a thing. Compact, reusable, robust.

dojo.query - not just another dojo.byId

2008-06-03T18:35:00.000-07:00

The more I find out about the magical function that is dojo.query, that more that I'm blown away by it's potential.

It feels so unfamiliar at first using javascript and knowing that I'm grabbing and working with node objects rather than using string ID's all the time but once you get used to it, it's liberating.

Finding and filtering nodes by any number of attributes and classes is only just scratching the surface though. Dojo.query not only makes getting things easy but what it returns is just as powerful.

dojo.nodeList is a fairly new entity to me but one that has a similarly great potential. It's intention is to hold a bunch of node elements and make working on them easier than you'd expect.

In one of my last posts I used dojo.forEach to loop through nodes adding a connect on each item, but as Alex Russell pointed out, we needn't worry about half of that code.

Instead we can write:


dojo.query(".checkboxTrigger").onclick(updateStatus);

I love the fact that it not only makes things shorter, but somewhat more readable. It applies the updateStatus function as the onclick for all the return nodes. Easy.

Looking into the api for the dojo.NodeList there are plenty of things we can do to our nodes. We can create animations, addContent, clear content, etc.

I highly recommend a bit of exploring in both the dojo.query and dojo.NodeList areas as I'm continuing to find more and more things of interest.

Old-School Dijit helpers

2008-05-19T00:26:00.001-07:00

Being raised on dojo 0.4.x there were a few widget things that seem to have been lost along the way for dojo 1.x. This may be due to better practice etc but old habits die hard.

var widget = {
   byId: function(/*String*/ id){
      return dijit.byId(id);
   },
   all: function(){
      var widgetArray = [];
      var widgets = dijit.registry._hash;
      for(var a in widgets){ widgetArray.push(widgets[a]); }
      return widgetArray;
   },
   allHash: function(){
      return dijit.registry._hash; 
   },
   byType: function(/*String*/ type){
      type = type.toLowerCase();
      var widgets = this.all();
      var widgetArray = dojo.filter(widgets, function(item){
         return (item.declaredClass.toLowerCase() == type);
      });
      return widgetArray;
   }
}

Main ones here are core.widget.all() that returns all present widgets and core.widget.byType() that can fetch by declared widget class.

"all" is handy for debugging some times just to make sure all your widgets are appearing on the page and sometimes to see if dynamic widgets are being created.

"byType" isn't used as much but some times can be handy to grab numerous widgets of the same type that aren't related like buttons etc.

There are likely to be newer (smarter) ways of doing this kind of stuff. But it was a quick hack to get an old approach back.

Evolved coding with Dojo - No more string trickery

2008-05-18T22:01:00.000-07:00

Nothing like a bit of code in action to get a sense of how JavaScript as a language is coming along.

So to get things rolling, I've come up against the situation where there are several rows of a form and each one starts with a checkbox. Clicking that checkbox enables or disables the form elements in that row restricting access to that row and making sure the user is aware of what they are changing when they do it.

I've often seen how my hardcore java programmer colleagues approach this. They usually hardcode an onclick with node id trickery to find what to enable and disable. Server side they increment id's and hope they match as the page changes. Just one of many possible approaches here.

function update(obj){
 var id = obj.getAttribute("id");
 var new_id = id+"_element";
 var node = document.getElementById(new_id);
 node.disable = obj.checked?'':true;
}

We can do better than this though.

For starters, anyone who's seen dojo a little bit will know about dojo.connect. This means we don't need to hard-code onclicks, can be smarter about memory leaks (crucially with IE) and connect anything to anything.

Step one, when the page loads we want all the checkboxes on the page to magically gain an onclick event. I could search for all checkboxes in general but don't want to accidentally clash with form input checkboxes. So to make this easy I'm going to give all the checkboxes I want the style class 'checkboxTrigger'.


dojo.addOnLoad(function(){
  dojo.forEach(dojo.query(".checkboxTrigger"), function(item){
    dojo.connect(item, "onclick", updateStatus);
  });
})

The function does pretty much what was said... On load, query for elements with a class 'checkboxTrigger'. For each of those, connect the updateStatus function.

Next we need the update function.

The update function should figure out what checkbox was clicked. Then find all the input fields in that row, except for checkbox triggers, then set the disabled attribute on all of the remaining form elements.

var updateStatus = function(/*Event*/ e){
  var targetNode = node = e.target;
  while(node.tagName.toLowerCase()!="tr"){ node = node.parentNode; }
  var inputs = dojo.filter(dojo.query("input", node), function(item){ 
    return (item.className!="checkboxTrigger");
  });
  var state = targetNode.checked?'':true;
  dojo.forEach(inputs, function(item){ item.disabled=state; });
}

So here we find the target of our click event which should be the checkbox. Walk up the dom tree a few steps to find the "tr" row node. You could use "div" if you wrap your nodes in a div (being politically correct). From there we use query to find inputs in that row, filter out checkboxes with our special class name and then use forEach to loop through and set a disabled status on those fields.

Presto. A function that can generically enable or disable fields in a row using trigger checkboxes. We didn't care how many rows there are or how many fields in the row and no trickery with id's. This means generic code with less chance of failing to find nodes and killing your code with exceptions.

There's plenty you could do to this final function to make it more robust, more capable of finding form elements etc, but it's a place to start.

Why Not - Code highlighting with Dojox

2008-04-14T19:28:00.000-07:00

I recently stumbled across files in dojox for code highlighting and I thought why not? why not add a bit of syntactical sugar to blogger. So making use of AOL's very generous cross domain dojo hosting, I gave it a go.

You'll find info on the AOL CDN dojo releases here: http://dev.aol.com/dojo

From there we need to include the dojo core in our template using bloggers template html editor and add a tiny bit of script that looks something like this:

<script djConfig='parseOnLoad: true' src='http://o.aolcdn.com/dojo/1.1.0/dojo/dojo.xd.js' type='text/javascript'/>
<script>
dojo.require("dojox.highlight.languages.javascript");
dojo.addOnLoad(function(){
    dojo.query("code").forEach(dojox.highlight.init);
});
</script>

which means when the page is finished loading, grab all the "code" blocks using dojo.query and then loop over them initialising them with dojox.highlight.init.

This is pretty much lifted from the highlight test case and is worth a look if you want to see more examples.

At this point, a little tweak to the css with the block

pre code {
display: block;
border:1px dashed #aaaaaa;
overflow:auto;
background-color:#ffffff;
color:#444444;
padding:3px;
whitespace:pre;
}

..and we have code blocks that are highlighted and will handle scrollable overflow.

For some reason, IE currently doesn't obey the 'pre' aspect of all of this and hence white spacing is lost. I'll look into that when I get a chance.

Templating made nicer with Jaxer, dijit and dojo.query

2008-03-18T20:30:00.000-07:00

Once upon a time dojo had markup ability using custom tags. This was pulled because as it turns out, some browsers just scrap tags they don't understand. One browser that did support tags of a non HTML nature though was Mozilla and in turn we get this freedom back via Jaxer.

So in this knowledge, I did a quick concept mock-up. And in essence the gain can be varying depending on the amount of work you want the back end to do.

In it's simplest form, we can change

<div dojoType="dijit.form.button" label="test"></div>

into

<dijit dojoType="dijit.form.button" label="test"></dijit>

and simply do a server-side rebadging of the nodes so our gain is mostly readability of tags.

But I wanted something a little more exciting. I've been working with JSF and JSTL on and off and am pretty familiar with the notion of a tag, render/component definition and tag definition in a config file. What this gives us is a splitting of code, presentation and config.

So following that blueprint I created a tag definition that looks something like this:

tags: {       
    dijit:{
        button: {
            include: "dijit.form.Button",   
            dojoType: "dijit.form.Button",   
            passthrough:['label', 'iconClass', 'showLabel'],
            passthroughContent: true   
        },
        numberspinner: {
            include: "dijit.form.NumberSpinner",
            dojoType: "dijit.form.NumberSpinner",
            passthrough:['constraints', 'value']
        }           
    }
}

Here we have a reference to what include is needed, the dojoType and any passthrough tag attributes we might need. The passthrough is really an optional concept but I kind of like making safe the information that gets taken from the tag and pushed to the widget.

Next how to call it. Simply put:

<dijit type="button" label="test2"></dijit>

And lastly...the processor. Well usually we kick things off with a dojo.addOnLoad but that's not applicable in Jaxer land (at the moment) so instead we start things using a connect and the "onserverload" event.

The processor does the following:

Loop over the the tag definition object grabbing the first level child nodes. These nodes are the actual tag names to search for so in our case we have "dijit".
Use dojo.query to find every instance of custom tags like "dijit" and add them to a queue.
Loop over the queue, first checking each node for content that has a dijit tag in it. If so add it to the back of the queue so that we process from inside content to outside parent tags.
Continuing with the node, use its type to find the definition in the tag definition set and convert the node into a div tag with a dojoType attribute.
Pull over a base set of attributes like id, name, style and then the pass through attributes.
Add the specified require to an object for later.
If necessary, pull content of the dijit tag over to the div tag.
When all nodes are processed, loop over the require object building up a series of dojo.require statements.
Add the require statements to a script block in the page and make sure it's set to runat='client'

With this process we convert all nodes to the expected divs and neatly contain all dojo.requires in one place. This means we can now create a simple reference in a custom tag to a more elaborate template configuration and backend generation. It really feels like an evolution of JSTL in some ways.

Does it work? My proof of concept code says yes and I've taken it further so that instead of replacing dijit tags with divs we replace it with programmatic instantiation. This idea is even better in some ways as it takes some of the heavy lifting away from the parser. The client-side only has to worry about code execution and not only that we can use the backend to accumulate code and keep it tidy just as we did with accumulating the dojo.requires and then outputting them in one place. Having said that I've been really impressed at recent optimizations with the parser.

It's worth noting that this as always is a "what if" experiment and should not be taken as perfect or an enterprise solution

From my quick trials one of the key advantages with Jaxer has been the ability for the server to keep track of various page level pieces of information and then arrange them neatly for the client-side. The fact that it's Mozilla-like at the back end effortlessly supporting the required features is really refreshing.

Jaxer + Dojo - Progress

2008-03-04T19:44:00.000-08:00

Some really great progress has been made by the dojo guys, particularly J. Burke.

Catch some of the discussion on the trac thread:

http://trac.dojotoolkit.org/ticket/5878

There's been some discussion about the callback state of Jaxer and this interests me mostly because I'm curious and kind of like the idea of functional dojo everywhere. I've started a ticket looking into why Dojo and callbacks are different (and not working) in comparison to the working JQuery examples.

http://trac.dojotoolkit.org/ticket/6066

Dojo + Iframes

2008-02-25T14:41:00.000-08:00

There's been a lot of talk about getting dojo to work with Iframes but I think that statement has left room for confusion. To get dojo to work with iframes, there are two possible scenarios.

The first is that we want to load dojo into the parent frame and use it to access child frames. This is presuming the child frame is simple content and only needs to be modified with things like dojo.byId.

The other scenario is the one that I am more concerned with and that is dojo is loaded both into the parent and the child iframe. This is because we want to use things like dijit widgets and other advanced rendering ideas in both the parent and the child windows.

Scenario 1 - Child frame = Simple content

For the first case where we only want to access information in the child window, tools such as dojo.setContext and dojo.withGlobal are perfect as they temporarily swap dojo's context to act as if it were within that child window. From there all the calls to finding dom nodes etc are performed locally in that child window. Be careful though as these methods swap the context of the global object so all dojo related commands are performed within the current context. If you leave the context locked to a child frame and don't swap it back in time for some parent code to run, things can behave badly.

As far as I know you can't reliably create dijit widgets in a child iframe whilst keeping all the dojo code hosted in the parent frame. I'd be really happy if someone told me I was wrong on this.

Scenario 2 - Child frame = Dojo content

For the second scenario we load dojo code twice (first in the parent and then in the child iframe window) but we do have the advantage that dojo is allowed to work independently of other documents. No worries about concurrently running code and context sharing / swapping. Other things like dijit don't have to worry about sharing manager code cross-window either.

Apart from the heavy lifting of the code there is one other downside to a dojo in each frame as pointed out by JPSykes in his entry. There is a siloing effect between the frames as they don't register with one another or communicate with one another.

Speeding up the load

Given that I want to load dojo in each frame to gain full dojo/dijit functionality I found a way of making the code loading experience a little smoother. When we initialise a page with iframes we load the parent window and then it's dojo resource, then repeat for the child window and it's dojo resource. Since we are loading dojo twice I wondered could I leverage what the parent window knows of the dojo code?

Looking at the mechanics of dojo, dojo loads code with dojo.require and that is a very elaborate (and really fantastic) wrapper to the native xml http request object. That means underneath it all, we are still just getting text and evaluating it into the page. This is what caught my attention. If you dig deep enough through the dojo.load methods you'll find a method called dojo._loadUri.

dojo._loadUri uses _getText to retrieve a string of the code and drop it into the page. My theory was, what if we don't just discard that string but rather add it to a storage object and then get a child frame when it calls dojo.require to ask the parent "have you already got this?". If it does, instead of making a remote request, we can grab it off the storage node, hopefully speeding things up.

When you step back from the technical side, this becomes an in-page caching system using dojo.require as the interface to that data cache. So is it possible? The following I store in a file called parentCache.js and load directly after loading dojo.js:

var codeRepository = {};    
if(typeof(djConfig.noParentCache)=="undefined"){
    dojo._loadUri = function(/*String (URL)*/uri, /*Function?*/cb){
        if(this._loadedUrls[uri]){ return true; }
        var topWindow = window.top;
        if((topWindow)&&(topWindow != window.self)){
            // attempt to load in the parent window
            topWindow.dojo._loadUri(uri);
            // make sure we have a storage node
            if(topWindow.codeRepository){
                // load from parent
                var contents = topWindow.codeRepository[uri];
            }
            if(!contents){
                //not present, try loading manually locally.
                var contents = this._getText(uri, true);            
            }
        } else {
            //we are the parent, load it manually.
            var contents = this._getText(uri, true);            
        }
        if(!contents){ return false; }
        codeRepository[uri] = contents;
        this._loadedUrls[uri] = true;
        this._loadedUrls.push(uri);
        if(cb){ contents = '('+contents+')'; }
        var value = dojo["eval"](contents+"\r\n//@ sourceURL="+uri);
        if(cb){ cb(value); }
        topWindow = null;
        return true;
    }
} else {
    console.log("------------------------ no parentCache ----------------------------");
}

Note. Yes, I'm sure you can make this more compact or streamlined.

By keeping this separate from dojo I don't have to worry about re-editing dojo code when we upgrade. Looking at the code, it overrides the loadUri method with the new ability as described above. It is also wrapped in a check that checks djConfig for the noParentCache flag. If that is set to true then we don't worry about this caching idea. This flag is very helpful for development as without it, if we change code and try to reload the iframe, it'll grab the cached copy off the parent again without picking up the saved file changes.

The real catch for this is that you don't create monolithic dojo build files anymore. Loading everything up with a single dojo.js means only a minor advantage for the iframe caching as we still need to load a base dojo.js file to start things. Finding a balance between how much of an initial load you do and how much you allow to cache for child frames is a bit of a guessing game. What it does mean though is that child frames no longer care how fast or reliable your internet connection is once you start getting cached info off the parent.

Again I don't claim this to be perfect, the "best way" or Dojo compliant. It's just exploring ideas.

Overcoming the Silo

How we approach cross iframe communication really depends on the requirements. If we want to broadcast a message to all frames then we can use dojos fantastic topic / publish code to push a message around. We can even create wrappers that loop over each frame and use withGlobal just as mentioned in discussions found here.

The thing I've found is that it's often easiest to use window.top to always find the root parent window and work from there. Whether it's pushing information into a common storage point or cascading a message or action back down through the frames.

Caution

From all this cross frame tinkering, there are known memory leak conditions under IE that can occur with window and variable references if not cleaned up. If you are communicating between windows, try and keep the information that is passed between them, contained and clean it up when the function is finished. Iframe memory leaking with the dojo object seems to occur under IE no matter what I do but some minor things like stray variable references can have massive impacts on how much is leaked.

D + J - Simple Tree Test

2008-02-21T18:13:00.000-08:00

Simple test case grabbing a file list of the dojo dir (one child deep) and pushing that into a dijit.tree widget.

Disclaimer: I'm in no way claiming this to be the "right" way of doing things with Dojo or Jaxer. This is just some experimenting.

<html>
  <head>
    <style type="text/css">
      @import "dijit/themes/dijit.css";    
      @import "dijit/themes/tundra/tree.css";    
      @import "dojo/resources/dojo.css";
      @import "dijit/tests/css/dijitTests.css";      
    </style>
  </head>
  <body class="tundra">      
    <script runat="client" src="dojo/dojo.js"></script>    
    <script runat="server">
      //dojo compatability block
      Jaxer.load("dojoCompat.js");      
      function oncallback(){
        Jaxer.load("dojoCompat.js");
        dojo = window.dojo;
      }
    </script>
    <script runat="server">      
      function getFolderInfo(pathStr, level){  
        var maxLevel = 1; //hard coded limiter for quick test case
        if(!pathStr){ pathStr = "dojo"; } 
        if(!level){ level = 0; }
        var dir = new Jaxer.Dir(Jaxer.Dir.resolvePath(pathStr));
        var files = dir.readDir();
        var fileNames = [];
        try{
          dojo.forEach(files,function(item, index, data){
            var name = item.getLeaf();
            var info = {
              "id":("node"+index),
              "name":name,
              "isDir":item.isDir(),
              "isFile":item.isFile()
              };
            if(item.isDir()){
              if(level == maxLevel){
                info.children = []; 
              } else {
                var newPath = (pathStr+"/"+name);
                info.children = getFolderInfo(newPath,(level+1));
              }
            }
            fileNames.push(info);
          });
        } catch(e){}
        return fileNames;
      };
      
      function getData(){
        return dojo.toJson(getFolderInfo());
      }
      getData.proxy = true;      
    </script>  
    <script runat="client">
      dojo.require("dijit.Tree");
      dojo.require("dojox.data.jsonPathStore");
      dojo.require("dojo.parser");
      
      function buildTree(){
        var dirStructure = dojo.fromJson(getData());
        var data = new dojox.data.jsonPathStore({
          data:dirStructure, 
          idAttribute:"id", 
          labelAttribute:"name"})
        var tree = new dijit.Tree({
          store:data, 
          label:"root", 
          labelAttr:"name", 
          somePropertyAttr:"name", 
          query:{query: '$[*]'}});
        dojo.byId('placeholder').appendChild(tree.domNode);
      }
      dojo.addOnLoad(buildTree);
    </script>    
    <div id="placeholder"></div>    
  </body>
</html>

dojo + jaxer - Updated compatibility block

2008-02-21T17:51:00.001-08:00

Most recent revision of the compatibility block that gives dojo on server and callbacks.

<script runat="server">
    //dojo compatibility block
    Jaxer.load("dojoCompat.js");            
    function oncallback(){
        Jaxer.load("dojoCompat.js");
        dojo = window.dojo;
    }
</script>

dojoCompat.js:

var djConfig = {baseUrl:"dojo/"};
Jaxer.load(djConfig.baseUrl+"dojo.js");
dojo._loadUri = function(/*String (URL)*/uri, /*Function?*/cb){                
    Jaxer.load(uri);        
    return true;
}
dojo.toJson = function(obj){
    return Jaxer.Serialization.toJSONString(obj);
}

At this point I can now build up dojoCompat.js to add in further overrides and compatibility tweaks.

Jaxer + Dojo - dojo.toJson

2008-02-21T17:39:00.000-08:00

For some reason calling dojo.toJson on the server with Jaxer outputs arrays as objects with indexes. No biggie.. Jaxer provides a serialization extension of it's own. Server side tweak:

dojo.toJson = function(Obj){
  return Jaxer.Serialization.toJSONString(obj);
}

Jaxer + Dojo - callbacks

2008-02-21T14:37:00.000-08:00

One quick note.. I noticed when doing callbacks that I could see dojo but the second I tried to use it for anything more than a property (like getting the dojo version) things always crashed.

Reason can be found in the discussion of making JQuery run in jaxer. There are three instances of the Dom. Pre-render server, client side and callback. Callback currently doesn't share the same environment so they use a function "oncallback" to to a quick setup before actioning server side callback commands.

To make dojo work correctly with my server-side and callbacks I just the following into my runat='server' block:

function oncallback(){
    Jaxer.load("dojo/dojo.js");
    dojo = window.dojo;
}

further info on the matter

Jaxer + Dojo

2008-02-20T22:21:00.000-08:00

I like the idea of this Jaxer stuff but being a dojo guy have the tricky position of most of the code coming into pages via dojo.require.

Feeling I still wanted dojo at the server side I did a quick hack that seems to work well enough for now. Note you MUST use a build release because the initial loader / bootstrap stuff goes badly if left to try and self load. Using a compressed build file means everything comes in with the standard script tag.

<script runat="server" src="dojo/dojo.js"></script>        
<script runat="client" src="dojo/dojo.js"></script>        
<script runat="server">
    dojo.baseUrl = "dojo/";
    dojo._loadUri = function(/*String (URL)*/uri, /*Function?*/cb){                
        Jaxer.load(uri);        
        return true;
    }
</script>

Adjust the base path to match your directory structure.

Note I have included dojo twice rather than runat="both".. this is because I don't want the server side version to be pushed to the client. The client side version reloads a clean instance of Dojo with all the browser state set correctly.

From then on, server side we can call dojo.require to pick up files and use them.

Java style Iterator in Dojo

2008-02-09T17:39:00.000-08:00

I love iterators.. no more clashing of variables in for loops etc..But I'm a java guy so here's a java style Iterator extended from the dojox.collections.Iterator


dojo.provide("core.Iterator");

dojo.declare(
 "core.Iterator",
 null,
 {
  constructor: function(/*array*/ arr){
   this.a = arr;
   this.index = 0;
   this.element = this.a[0]||null;
  },
  
  _position: 0,
  
  hasNext: true,
  element: null,
  
  atEnd: function(){
   return (this._position>=this.a.length);
  },
  
  next: function(){
   this.index = this._position;
   this.element = !this.atEnd() ? this.a[this._position++] : null;
   this.hasNext = !this.atEnd();
   return this.element;
  },
  
  reset: function(){
   this.index = this._position = 0;
   this.hasNext = !this.atEnd();
   this.element = this.a[0]||null;
  }
 }
)

Usage:


var arr = [1,2,3]
var iterator = new core.Iterator(arr);
while(iterator.hasNext){
 doSomething(iterator.next());
}

Javascript vs HTML environment

2008-01-10T19:09:00.000-08:00

At the moment we have a browser that is a html oriented environment supporting javascript.

With all the JS engine development lately, how long will it be before we see a javascript environment that supports HTML?

Already we draw pages using almost soley dom manipulation in the browser. Wouldn't it be interesting to go to a javascript page in your app and start drawing immediately rather than using html scaffolding and page loading events.

Rhino (the java / js engine) has always intregued me. Maybe we need to think more along those lines?

Dojo Presentation Shorthand

2007-12-11T18:01:00.000-08:00

I like the idea of a browser based simple Powerpoint. I'm not a fan of crazy transition effects as I feel they waste time and get annoying. Fade in some bullet points and I'm done.

Hence the dojox.presentation work is a step in the right direction for me. I didn't however like the idea of duplicating each "part" with an "action" when I wanted to consistently fade in each bullet. So I made a function to simplify things.

The addOnLoad will go through the page hunting for elements with the class ".part" inside slides and then convert them to part widgets. In the process it builds a matching action widget with the default settings. We have to manually push the items into the slide so the slide knows what to do.

I also built a variant to hunt for particular nodes so the li's get targetted without a class but I'll leave that to your imagination. Much more compact code and almost as easy as typing it up in powerpoint.


dojo.addOnLoad(function(){
 var slides = dijit.registry.byClass("dojox.presentation.Slide");
 var partCounter = 0;
 slides.forEach(function(slide){
   var parts = dojo.query(".part",slide.domNode);    
   parts.forEach(function(part){    
     var partname = 'part' + partCounter; 
     var partWidget = new dojox.presentation.Part({as:partname},part);
     slide._parts.push(partWidget);
     var tempNode = document.createElement('input');
     slide.domNode.appendChild(tempNode);
     var actionWidget = new dojox.presentation.Action({forSlide:partname},tempNode);
     slide._actions.push(actionWidget);
     partCounter++;
   })
 })
}) 

...html snip...

<div dojoType="dojox.presentation.Deck" id="testPresentation">
  <div dojoType="dojox.presentation.Slide" title="Slide 1">
    <p>Nothing special to start with</p>
  </div>
  <div dojoType="dojox.presentation.Slide" title="Slide 2">
    <p>Now for some fade in points</p>
    <li class='part'>Item 1</li>
    <li class='part'>Item 2</li>
  </div>
</div>

Dom Tree vs Code Mash

2007-12-06T14:54:00.000-08:00

One thing that I've started to feel more and more is my dislike of mashed up presentation code. What made me think of it was reading some raw PHP. PHP has frameworks to split out evaluation code from inline html but most often you just see part of the page break out into some code then transition back into html, back and forth throughout the page.

This makes me uncomfortable these days and most likely as I'm primarily a Java / JavaScript developer. My JS code has the convention of being a single block in the page or a separate file and the html is a scaffold that I work with. Code is evalutated before or after a page load so timing is no longer an issue and I rarely need to figure things out on the fly as the page is being drawn. It's not always the easiest to read either when you have JS code connecting to elements in the page but it usually only takes a little browsing and some good coding conventions to find your way.

The part I like about this dividing of code is browsing the HTML, I don't get lost in code. In a dom tree you don't tend to snap the tree in half and start spitting out some ascii before you pick up where you left off. I feel this should be true for the actual code.

In my opinion, the MVC concept isn't just for enterprise level server, browser, database constructs.. As javascript gets used more and more there's a page level variant on this idea too.

Parent Caching

2007-11-06T15:13:00.000-08:00

So caching is a tricky one. The browser should cache requests to make things faster so that when we repeatedly need resources, it doesn't have to keep running off and fetching things. Instead it just dips into a local file cache and presto a quick load.

Enter dojo using XHR to fetch the code and in my case, throw in a bit of HTTPS style complication. At this point can we be sure what is being cached and when over all browsers?

Backing up a bit, I have a fairly unique case of dojo usage where I have iframes (each using dojo) inside a consistant non-refreshing parent page. The creating of iframes and loading means I end up with a lot of code duplication and code loading.

To access the code in each page and frame, dojo.require is used fetching plain text that gets eval'ed into the page. If a browser isn't clever enough to cache XmlHttpRequest object feeds we are fetching that same code over and over.

What if we kept hold of that raw text javascript code? What if we use the fact that the parent page doesn't refresh? And what if we started making it available to child iframe pages. Then child iframes could start asking the parent for code and if it's not available, let the parent go get it and keep it for other pages to use also.

This effectively makes the parent page a local proxy for dojo.require. The concept when you think about it isn't too hard and looking into the dojo.loader code it wasn't hard to implement either.

I first load the dojo.js file always and then load a secondary javascript file that overides the dojo._loadUri method. This way feels less obtrusive and I don't loose my changes when we upgrade dojo.

This is my first hack version (and it is a proof of concept hack created in all of 10 minutes):

var codeRepository = {};
dojo._loadUri = function(/*String (URL)*/uri, /*Function?*/cb){
if(this._loadedUrls[uri]){
return true; // Boolean
}
var topWindow = window.top;
if((topWindow)&&(topWindow !=window.self)){
topWindow.dojo._loadUri(uri);
if(topWindow.codeRepository){
var contents = topWindow.codeRepository[uri];
}
if(!contents){
var contents = this._getText(uri, true);
}
} else {
var contents = this._getText(uri, true);
}
if(!contents){ return false; } // Boolean
codeRepository[uri] = contents;
this._loadedUrls[uri] = true;
this._loadedUrls.push(uri);
if(cb){ contents = '('+contents+')'; }
var value = dojo["eval"](contents+"\r\n//@ sourceURL="+uri);
if(cb){ cb(value); }
return true; // Boolean
}

The function hasn't changed significantly other than whenever we get code we always push it to the code repository object (this in theory should be optimized to only new code).

Also we use having a parent as a means of knowing when to get the code from above and when to resort loading in the standard way. You need to check that the top most window isn't actually your current window or bad looping will occur.

Finally there is a failsafe. If things go badly and with all our loading you still have no content, the current page will try loading the content the old fashioned way.

The result is as you open iframes and use the system more, code accumulates in the parent page and overall there are fewer requests. With usage, things get faster and if you have a remote user on a slow connection things will speed up dramatically.

This does break one rule though. This system takes advantage of small dojo.require requests. The dojo guys recommend you build a unified file will your most common code merged together and then load that via script tags so that future requires already have the code there. This can't optimize for that as we take hold of the code as we remotely fetch it.

Hence there is a fine line between merging and inline loading code versus leaving it in separate files for some parent caching and dojo.require fetching. Overall things seem to be working better than expected with this approach.

Widgets vs Managers

2007-10-14T18:35:00.000-07:00

This isn't a "my way is best" article. It's just something I've been thinking on recently.

With all the push for widget development lately we are getting really good at turning an inert snippet of HTML into a full blown widget with many abilities. Also where we once had a few of these on a page we are now starting to build applications with masses of functionality.

While it is very clean to package up the functionality of a widget into a unit of code I've also used the pattern that a widget is merely a place to store data and link information to a dom object while the heart of the functionality is stored in a manager or shared resource.

Which approach you use I think depends on the case. But I don't think we should forget that repeating yourself may not always be the best and most efficient answer.

A simple example of this can be seen in Dijit's tooltip. The master tooltip is drawn and then moved and repopulated as required. Both a widget and being smart about how you create many instances of the same visual components.

What does $ mean to you?

2007-09-26T18:06:00.000-07:00

This article in the section "More on Naming" says exactly what I've been thinking for months now.

People in Java land are smart enough to use full word method names so you can read your code later but when I get into javascript and libraries like Prototype I start seeing punctuation scattered everywhere and single letters. This reminds me of Perl which is the only language I'm aware of that has a competition to figure out what a single line of code actually does.

If you want to write code that is meaningful, maintainable and others can interact with that aren't pro javascript writers, make things readable. Use names like getNode, setValue etc.. if you're worried about file size, develop this way and then run your code through a compressor like the ones provided by Yahoo, Dojo and many other sources now.

As a random note, sure Javascript doesn't have Typing but I really like the convention started by Dojo to use commented types in front of variable names on method definitions.

eg setValue(/*int*/ val)

or

updatePage(/*String*/ content, /*Boolean*/ forceUpdate, /*int?*/ index)

Here we can easily see what we expect a variable value to be and the use of "?" suggests that the variable is optional. You need not adhere to the standard types. I often throw in the type /*DOM Node*/ or a custom object name. The key is you know what it should be when you go to use the function and so do other people.