The get-well fix was pretty straightforward.  Just don’t do that.  I found no easy way to cohabitate dojo containers with mapping controls such as Goolge Maps or Amazon Maps, so I was forced to do all of my layout using standard divs, and to only use dojo for the html control itself.  It seems to work just fine so long as the dojo control is rendered ON TOP of the other controls.  Do not embed the map within the control though.

What I’ve done instead is adopted the idea that my dojo client code will simply format input data (red=bad, etc) if it needs fixing, and let the user see it. If the user attempts to push bad data, I will catch it on the server and reject it.

That means that all I need to do for dojo is to define a function to be my formatter. This function accepts a single parameter, and returns some html indicating what to display in the grid. So far, so good. Granted, I’d really rather use a robust validation framework for the grid data, but sadly, there isn’t one there.

So when you find yourself hitting 4 hours of frustration on validating grid input, my advice is to format the input, show the user where his error is, and be really good about server side input validation when the data is submitted.


var myformatter = function(s)
{
var RegularExpression = new RegExp("^\\d+$");
if(RegularExpression.test(s))
{
return s;
}
else
{
return "<span style='background-color:red'>"+s+"</span>";
}

Then later on you can use the formatter in your markup like this…

<table dojoType="dojox.grid.DataGrid" store="myStore"
query="{statename: '*' }" style="width:650px;height:500px" >

<thead>
<tr>
<th field=”statename” width=”200px”>State Name</th>
<th field=”population” width=”200px”
editable=”true”
formatter=”myformatter”
>Population</th>
<th field=”spending” width=”200px”
editable=”true” formatter=”mydecimalformatter”
>Spending ($billions)</th>
</tr>
</thead>
</table>

Note: this is based on the dojo 1.5 aol hosted version.

Link: Click Here

Here is my basic attempt at a grid definition. Code follows below…

var detail_view = {
cells: [[
{name:"Date Time", field: "STAMP", width: "90px",editable:true,

cellType:"dojox.grid.cells._Widget",
widgetClass: "dijit.form.ValidationTextBox"
},
{name:"workout", field: "WORKOUT_NAME", width: "100px"},
{name:"Rounds", field: "ROUNDS_METRIC", width: "65px",editable:true},
{name:"Time", field: "TIME_METRIC", width: "65px", editable:true},
{name:"Reps", field: "REP_METRIC", width: "65px", editable:true},
{name:"Weight", field: "WEIGHT_METRIC", width: "65px",editable:true},
{name:"Points", field: "POINTS_METRIC", width: "60px",editable:true},
{name:"Notes", field:"NOTES", width:"110px",editable:true}
]]
};
var detail_layout = [ detail_view ];

When creating a dojo chart, there are a few invisible things going on, and not going on.  When I went through the web looking for charting examples, I found a lot of examples showing how to define a simple series, but not a lot of examples with 2 dimensional data.  Dojo charts need to be configured by adding axis objects to the chart.  It is incredible important that these axis names correspond to the value names in your data.  What do I mean by this?


dojo.addOnLoad(function(){
var chart1 = new dojox.charting.Chart2D("simplechart");
chart1.addPlot("default",
{ type: "Lines" } );
chart1.addAxis("x",{labelFunc:labelfTime});
chart1.addAxis("y", {vertical: true});
chart1.addSeries("Series 1", data.pts);


The above is a code snippet that works pretty well when you have json that looks like this:[{x:1,y:2},{x:2,y:4}]. In some cases, I have managed to get the charting system to fail when using names other than x and y. It seemed to be intuitive that I could have an axis called xd, then set up the json to look like [{xd:1,y:2},{xd:2,y:4}]. It fails under Firefox.  So the first rule of charting safety is AXIS NAMES ARE ALWAYS x OR y.  I’m sure there are caveats to this, but for 2 dimensional charting, stick with the basics.

The next issue is the date itself.  It is tempting to think of a date as something like ’3/8/2010′, but if you do, you’ve just signed up for trouble.  When dealing with linear displays, the dojo charting system has no idea how to take formatted dates and put them on a chart.  When you are using categories, it’s no problem.  But lines, well, that’s different.  The solution to this issue is to think about a date as a number, not a string.  Javascript Date objects can represent themselves using the date epoch, which is the number of milliseconds since midnight 1 Jan 1970.  If you simply use this epoch date instead of a string, then the charting system can figure out how to draw the line.

Of course, when you do that, you end up with a bunch of huge numbers on your axis for your users to read (in disbelief).  We want to display a human readable date, while plotting the computer readable epoch date.  Luckily, the dojo team have provide a method to do just that.  When an axis is defined for dojo, a function can be assigned to the labelFunc property.  This function accepts a number based on that axis, and returns a label to be displayed.

function labelfTime(o)
{
var dt = new Date();
dt.setTime(o);
var d = (dt.getMonth()+1)+"/"+dt.getDate()+"/"+dt.getFullYear();
return d;
}
chart1.addAxis("x",{labelFunc:labelfTime});


The above code accepts input from the chart based upon the numeric epoch date. It then translates that date into a human readable label, and returns it to the charting system. Now your axis simply places it on the display in the right spot.

Of course, none of this does any good if you are using IE 8 with Dojo 1.4. The label system is buggy under that combination. Labels will not appear, nor will any error messages, leaving you to spend weeks pulling your hair out. Upgrade to dojo 1.5 to fix it and save your sanity.

The source code can be downloaded from here if needed.

My post today is about the dijit.Tree and the custom Icon capability. What this does is lets you inspect your data source to determine various attributes of your data, and change the icon based on that data set. Ideally all you have to do is to put a few if-then statements inside a script tag, and return a class name. The class can be defined in the css file.

I’ve found in some cases, that just doesn’t work. In some cases, when you load a page inside another frame or layout container, things might get screwy. Recently I used a set of nested dijit.layout.BorderContainer div tags to divide up my page, and dynamically loaded urls into content panes. Users could click buttons and that content pane would navigate to the different page. Under Firefox, the css just got lost in the shuffle. It’s odd that I have reference to the css from dojo, and the javascript, but not my new application css. The work around is to define your css classes inside your page contained in the Border Container. Here is a sample…


.nihilo .itemA
{
border-top: 0px;
background: url('./icons/itemA.jpg') ;
width: 16px;
height: 16px;
background-position : top left;
background-repeat : repeat-y;
zoom: 1;
}
.nihilo .itemB
{
border-top: 0px;
background: url('./icons/itemB.jpg') ;
width: 16px;
height: 16px;
background-position : top left;
background-repeat : repeat-y;
zoom: 1;
}

Then below where we define our tags, insert the event code.

That seems to get the dynamic icon up and working just fine!

I am going to try to get a working chart demo up on the site in the next few weeks. The chart demos out there are ok for the most basic of charts (where you already have your well formed data, etc) but tend to oversimplify a bit. My goal is to put something a bit more challenging up on the screen.

I found an Adobe web site, downloaded the binaries, and got to work. About an hour later, I still had NOTHING. So it looks like there may be some learning curve after all. There is a for-pay IDE out there to work with this AIR technology, but I have enough darn IDEs on my machine, and really don’t desire any more. For now I’ve put that little hobby aside. As I learn more, I will share it with my blog. Whether or not I actually use this thing, I still need to understand it.

This layout is used in the dojo grid control to define how the grid is displayed. The first column, time, needs a special validation rule. I want to make sure that only 4 dijit numbers are accepted into the control. In order to do this, I first define the fact that I want to use a dijit editor, then I provide a string that identifies the exact dijit class that I want to use. Here is the tricky part… If I want this dijit control to have any custom behavior or initialization settings, I need to specify those using the editorProps object. This editorProps object is used as a mixin later on. Appearantly what happens is that when the grid needs an editor, a new item of the editorClass type is created, and the editorProps are “mixed-in” to form the new object. The approach is pretty slick, but can be a little non-sensical to Object Oriented purists.

One might ask, “What is the difference between editorProps and constraint objects?” The only real difference is that constraint objects get mixed into the normal set of grid editors, and the editorProps get mixed into Dijit controls.

This is a pretty bare bones example, but contains enough to build up a pretty nice first try at Dojo, without all of the learning curve needed to start out.  I reference the aol libraries to keep the size small. It is built as a simple Eclipse project, so it should be very quick to get running. Just import it into your workspace and off you go!

Click Here to download the new example code.