Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
A Second Stab
Before getting too radical with our first object, I'll take a second shot at it. If you examine the code in the attached file and compare it to the original, important but subtle distinctions are present.
First, I've introduced a new mechanism to make events more useful. Now, a variable that has been present in the constructor from the start—ctrlVar—is impersonating a reference to a callback.
In the event that you actually put the first implementation through some paces, it should have been clear fairly quickly that multiple grids on a single page don't cooperate very well. Sure, two <DIV> tags could be used to isolate the HTML, but as soon as you try to update two rows simultaneously, trouble begins to brew.
No more.
Using our knowledge that only one instance of a page-level variable can exist at a time, that variable name is now used to distinguish multiple grids. Where this becomes immediately important is in the area of the event prototypes:
function OnHTMLDataGridRowSelect(cVar, rowData, rowNumber)
{
var grid = eval(cVar);
grid.editRow(rowData, rowNumber);
}
function OnHTMLDataGridDataChange(cVar)
{
eval(cVar + ".writeObjHTML()");
}
NOTE
Click here to download a zip file containing the source files for this article.
No longer are they empty—there's a default implementation! Is it the correct one? In either case? That's for you to decide. What's important are the fundamentals. Enter the argument cVar. By wrapping the text value in a call to eval(), the built-in JavaScript converter of strings into references, we get a reference to the specific grid instance. Not only does this allow for default implementations, it means that two grids on the same page can behave in different ways by checking the value of cVar when the function is called:
function OnHTMLDataGridRowSelect(cVar, rowData, rowNumber)
{
if (cVar == "testData")
{
var grid = eval(cVar);
grid.editRow(rowData, rowNumber);
}
}
Now, if we receive a selection from titleGrid, the application does nothing. In the case of testData, the default behavior is used. We can even check whether the event is being thrown by our first version or our second version with an underused fact: The parameters passed to a JavaScript function are actually stored in an array called arguments leading to the following:
if (arguments.length == 3)
// new version behavior
else if (arguments.length == 2)
// no cVar passed here
else
// who knows?
Moving on, I promised in the previous article that I would improve the data-editing capabilities of our object. In this edition, the displayed table has been severed from the underlying data. For prettiness, the grid rows now begin at 1, but the data array is still very much zero based.
In this version, not only can data be edited on a by-row basis, but rows, columns, and individual cells can be highlighted. The added function of reportValue has been replaced by a getValue/setValue pair, each of which takes a coordinate pair. What makes this possible is the embedded table-management capabilities in Internet Explorer's version of JavaScript. I'll leave it as a homework problem to make this fully cross-browser, but for now just note that tables in IE contain a rows and a cells array for management by x and y position.
The version left active in the HTML is the one in which clicking on a single cell replaces the value with the underlying HTML. Let's see a FlexGrid display images—or hot links, for that matter.
Which reminds me: There's no specific reason to either wipe out our page, or just open a new browser because a user thoughtlessly clicks a link.