Canvas Table Component Options

[CSM]

In order not to derail the thread this idea came from (I was ignored entirely by the OP), I've decided to post it here. Basically what I've written is an easily customizable Table class. You can change how it looks by overriding the default renderers, which paint the various parts of the table.

Here are some screenshots:


The table is actually split up into 3 parts, the column header area, the row header area and the cells. Because of this, the table can easily be put into various frames to allow scrolling of tables which are too wide or too long. The screenshot on the right shows scrolling an extra long table.

Also shown in the screenshot, the example row and column headers I implemented (to draw text on the Canvas)* do not directly handle the row and column header data, it is given to them. So that is why it appears to only draw 3 row headers in the screenshot, as I only specified 3 row headers. I did set at least 6 coulmn headers, though. It isn't very hard though to make a row/column renderer which does extrapolate and draw 1 through xx numbers for each row, as well as A though xx for each column.

* It should be noted here that it is the example renderers I implemented in the Widget are drawing the text, not the default table renderers. The requirements of being able to draw text (by any means) required too many things to be enabled or present to have the table handle it by default (this also means that if you need a table which uses renderers drawing stuff other than text, you don't have to include/require anything you don't need).

Some features:

• Customizable Row header, Column header, and cell renderers.
• Customizable cell editor.
• Easy ability to add scrolling for large tables in both directions.
• Various selection modes for selecting data in the table.
• Ability to enable/disable painting.
• Nice JsDoc documentation (though that's not really a a feature of the table ... maybe a bonus for using my Table class?)

In the download below, I disabled selection (for now) as it caused a bit of lag in starting cell editors, and selection just needs a bit of rework. Since I reorganized how the table is painted, it should be a lot faster now in initial painting. The paint time for letting the table handle itself versus disabling painting and calling repaint is the same (for initial setup) at this point. This is assuming you add all possible data (row/column headers and cell data). Unless you call repaint, it shouldn't paint things you haven't set.

Bugs I'd like help on:

• For reasons beyond me, the cell editor only appears every other time.
  • If you double click the first time it works, but if you double click somewhere else, the old one closes but the new one doesn't open.
  • I can't figure out why, as the text-area is attached to a frame and visible. Help appreciated.

If you could try it out (give suggestions, I guess), I'm really looking for some help making the table faster, as well as fix the above bug. I'm working on a new selection stuff which should be faster for larger amounts of data, I may remove some currently available table selection modes which are inherently slow.

Download Demo Table Widget
Download Table JsDoc

P.S.:
I should note the text-to-canvas implementation I bashed to work within Y!WE I got from http://typefacejs.neocracy.org/index.html, which also provides a way to make new canvas-fonts (as well as two more already made ones you can drop in if you like).

[g6auc]

Two bad links!

[CSM]

Two bad links!

D'oh! I forgot to put /projects/ in the URL path. Links should be valid now.

[g6auc]

New version starts a lot faster - one or two seconds.

Worked OK with my first test data (2418 bytes, 40 lines with 5 values per line) , apart from the issue of the columns being too narrow and not adjusting to the data in the file. Showed 5 columns.

Tried it with a second file of 2767 bytes. This has about 15 lines, each with 22 columns. It has quoted values, some containing newlines.

The Widget displayed with one column (the first). The rest was not shown.

Both files work OK in the List Engine Widget and in the Image CSV Display Widget.

Selection of cells is working OK on the Macintosh, but the size of the text in the selected cells means that only a couple of characters can be seen.

[CSM]

New version starts a lot faster - one or two seconds.

That's good to know.

Worked OK with my first test data (2418 bytes, 40 lines with 5 values per line) , apart from the issue of the columns being too narrow and not adjusting to the data in the file. Showed 5 columns.

Okay. In the future, they probably wouldn't auto-adjust either, but it is very easy for me to eventually support differing row/column heights/widths without breaking any code (assuming you wrote your renderer the good way) as I send the cell width and height to the renderers already. The issue becomes what do I do if someone changes the default cell width/height ... all previously unset cells would update next repaint, but should I call a repaint (in the Table code)? Also, when changing a cell's width/height all the cells have to be updated (and column or row headers appropriately) but this is why I have the ignore repaint property. You can disable paints, update any number of columns/rows, then paint it when adjusting is all done.

Tried it with a second file of 2767 bytes. This has about 15 lines, each with 22 columns. It has quoted values, some containing newlines. The Widget displayed with one column (the first). The rest was not shown. Both files work OK in the List Engine Widget and in the Image CSV Display Widget.

My CSV functions probably handled it okay. The problem arises when I read in the file, as I read it in via readFile(..., true), which would result in Y!WE dealing with those newlines for me.

Selection of cells is working OK on the Macintosh, but the size of the text in the selected cells means that only a couple of characters can be seen.

Before, or after I disabled it? Or did you re-enable it? I don't see how selection should affect the number of characters seen (unless I misunderstand you and it's not). I'll eventually offer a way to set row/column size individually.

[g6auc]

Before, or after I disabled it? Or did you re-enable it? I don't see how selection should affect the number of characters seen (unless I misunderstand you and it's not). I'll eventually offer a way to set row/column size individually.

I took the Widget after you fixed the link. I did not re-enable it.
The editing of cells worked OK, by doubling clicking. This is what I see:

[CSM]

The editing of cells worked OK, by doubling clicking. This is what I see:

Uhhhh, that is why I hate text-areas. They serve as both a TextField and a TextArea and generally fail at being a TextField. What you see there is probably the tray for a slider, except there is none. On Windows, this works fine. TextAreas are just full of bugs. If you have any ideas as to how to keep the TextArea from doing that, I'd like to know, as I know I set the size myself (which should prevent it from trying to expand like that).

[Cicerone Pavaloi]

[*]For reasons beyond me, the cell editor only appears every other time.[list]
[*]If you double click the first time it works, but if you double click somewhere else, the old one closes but the new one doesn't open.

I'm not sure this will help, but maybe you can figure out what's wrong if you try the following steps which leads to a strange bug (probably related to the one you talk about)

Open the widget;
double click a cell, the editor appear;
type some chars;
Double click another cell... ups!
double click another cell;
and another;
and another;
and another... etc

[Cicerone Pavaloi]

A quick "print" test shows that the editor function is called 3 times on the second doubleclick...

I added 4 print instructions:

CODE

    body.onMultiClick = function() {
        print('----------multiclick---------');   //<------------- here
        var event = system.event;
        [...]

CODE

        function editor(table, width, height, value, x, y, opening) {
            // Close the previously open field. This editor only does one cell at a time.
            if(opening && prevField) {
                print('Close the previously open field');   //<------------- here
                table.cellEditor(table, prevField.width + 1, prevField.height, table.data[prevField.y][prevField.x], prevField.x, prevField.y, false);
            }
            if(!opening) {
                print('!opening');   //<------------- here                prevField = null;
                if(prevParent !== null)  prevParent.removeChild(textField);
                prevParent = null;
                table.data[y][x] = textField._data || textField.data;
                if(table.onCellValueChanged instanceof Function && table.data[y][x] !== textField.data) table.onCellValueChanged(x, y, table.data[y][x], textField.data);
                table.repaintCell(x, y);
            } else {
                print('opening');   //<-------------  and here
                prevField = new Point(x, y);
                [...]

This what I get in the debug window:

CODE

----------multiclick---------
opening
----------multiclick---------
Close the previously open field
!opening
opening
!opening
----------multiclick---------
opening
----------multiclick---------
Close the previously open field
!opening
opening
!opening

Edit:
If I remove (or comment out) the textField.onLoseFocus

CODE

                textField.onLoseFocus = function() {
                    //table.cellEditor(table, width, height, value, x, y, false);
                };

the editor function gets called only 2 times, which resolves the second doubleclick bug:

CODE

----------multiclick---------
opening
----------multiclick---------
Close the previously open field
!opening
opening
----------multiclick---------
Close the previously open field
!opening
opening
----------multiclick---------
Close the previously open field
!opening
opening

...but not the bug I described in my previous post.

[CSM]

A quick "print" test shows that the editor function is called 3 times on the second doubleclick...

That is so odd. During my testing, it seemed to me that the text-area's onLoseFocus wasn't called when I clicked anywhere else on the Canvas. However, LiteStep has also been giving me no end of focus trouble, so it wouldn't surprise me if it is the real culprit.

What my intent was that when the the next editor was called, I would close the previous editor.* Under normal circumstances, if the onLoseFocusFired, it should have cleaned it up and then when the cell editor was activated (the next one) it would be good to go. Maybe I should reconsider under what cases the previous cell editor is cleaned up (and find out of losing focus does cause a proper cleanup).

* This is only default functionality, it is possible someone could envision an editor which allowed multiple open editors at one time. However, since Table doesn't keep track of all cells open for edit (as I didn't want to commit myself to anything specific) there would be no easy way to close them all unless the cell_editor itself kept track of them.

...but not the bug I described in my previous post.

That is strange and shouldn't happen. It means it is painting the wrong cell, and for the wrong reasons. To save time, when each editor is closed, it only paints the cell it was in charge of editing (rather than a general repaint). Somehow it is painting the previous cell's location on to the new one, which under normal circumstances shouldn't happen as that only happens on close (and on close it should have the correct x,y from the current cell). So I really need to rethink the logic I have in there.


Also, while I have your "attention" Since I sometimes like to get feedback other than for debugging, what do you think of the component? Does it have some merit?** Also, any thoughts on the design (cell renderers, etc). I'm not entirely sure I picked the right way to handle cell editor closing (I wanted it to be similar to cell renderers, but couldn't think of an easy way to handling closing, so I tacked it onto the end of the parameters).

** All I envisioned was a simple Table component to serve most needs easily (while still offering some advanced stuff for those who like that kinda stuff) and look good while doing it. The other person's table script, while quick and possibly easy to get going, spills all the code into the whole Widget (making it harder to have multiple tables easily) and isn't all that flexible. Also, no offense, but presentation does count for something. I consider his tables a bit ugly.

[Cicerone Pavaloi]

During my testing, it seemed to me that the text-area's onLoseFocus wasn't called when I clicked anywhere else on the Canvas.

Of course clicking on a canvas will not remove focus from a textarea because canvas can't be focused, but hiding a focused textarea will remove focus from it, thus the onLoseFocus is called.

It means it is painting the wrong cell, and for the wrong reasons.

It's not just painting, it sets the value of those cells to the last value that was changed.

what do you think of the component?

Looks pretty standard.
Personally I would not use canvas for text, so one could easily change the font to its need (I hate serif fonts in interfaces ).
Other than that, I did not dig in the code to see if it's easy to use or customize.

[g6auc]

The other person's table script, ... , spills all the code into the whole Widget (making it harder to have multiple tables easily)...

That I don't understand. In the version of "the other person's" script that I am currently using, you give a function the data and column widths and it returns a populated Frame, which you can place wherever you like - basically:

CODE

function tableGen(data, rowHeight, colWidths, evenColor, oddColor) {
    ...
    var table    = new Frame();
    ...
    return table;
}

The processing of .csv and .tsv files is quite separate from the table generator.

[CSM]

Of course clicking on a canvas will not remove focus from a textarea because canvas can't be focused, but hiding a focused textarea will remove focus from it, thus the onLoseFocus is called.

Then maybe I should add a parent check so it doesn't do what it is supposed to if it has no parent (meaning it has been removed from the frame for the moment).

It's not just painting, it sets the value of those cells to the last value that was changed.

It shouldn't set the value ... but I'm going to look into that code anyways, it needs a bit of a redo.

Looks pretty standard. Personally I would not use canvas for text, so one could easily change the font to its need (I hate serif fonts in interfaces ).

Nobody has to use serif fonts. There was (I believe) a non-serif font on the website. The font is easily changeable, it's just another JS file. That's why the table doesn't draw text by default (because of all the issues involved). My custom renderers draw the text via the the hacked renderer file. If you want to eschew Canvas text altogether, remember that you have to then manually create a large number of Text objects, make them line up with the Table property, and look nice. That's hard(er) to do. Plus with the Canvas renderer, you can make the table's display look the same on both platforms (as the text is rendered).

Other than that, I did not dig in the code to see if it's easy to use or customize.

But yet you dug into my cell editor code, which is buried amongst the JsDoc and code! On a serious note, the main JS file demonstrates many of the features, such as how to split things up into multiple frames and how to use custom renderers.

That I don't understand. In the version of "the other person's" script that I am currently using, you give a function the data and column widths and it returns a populated Frame, which you can place wherever you like.

Well, I guess from what I saw I interpreted it to involve more outside functions than it looked like. Plus, I also mentioned flexibility, which you seemed to ignore to harp me on these points instead. In terms of flexibility, his may offer immediate ability to manipulate the frame, but you can't get at the values unless you keep around the original array, and manipulating other table properties involves the DOM.

The processing of .csv and .tsv files is quite separate from the table generator.

I don't think I even mentioned that. I only include CSV parsing as a convenience, considering I expected this to be of some use (along with the table itself) to the original poster (for which it apparently was not, despite the initial interest). I was slow at getting mine done, and the other table script was already handy and therefore easy to immediately implement.

argh ... how did I get sucked into an argument defending my position?

[g6auc]

argh ... how did I get sucked into an argument defending my position?

You asked for feedback!

Clearly, your component provides much more functionality than was required to satisfy the problem posed by the OP in the other thread.
The OP wanted to display a table - no mention was made of editing it. That extra functionality and flexibility may come at a cost, and it would be good to know what that is.

So that you can make comparisons (should you wish), here is some very rough timing data (made on my 2GHz Core Duo iMac).

I have been using four test files to assess the performance of my latest version of tableGen (which has about 50 lines of code).

CODE

1.  sheet1.csv        406 bytes,  21 rows,  5 cols - your test data, as used in your Table Widget
2.  download.csv     2418 bytes,  40 rows,  5 cols - a bank statement
3.  test.csv         2767 bytes,  15 rows, 22 cols - an Outlook event file
4.  addresses.csv   33674 bytes, 163 rows, 52 cols - a Palm Desktop address file

I have simplified tableGen so that it returns a single frame.
Appended to that frame are:
frames - one frame per row containing
a canvas - one canvas background per row frame
texts - cols texts per row frame
Note that I no longer have each cell in a separate frame.

The (elasped) timings for these (in seconds) are interesting and a little puzzling:

CODE

Processing the file    Generating the Table     Rendering by the Widget Engine
1.  0.023               0.043                   instantaneous
2.  0.052               0.063                   instantaneous
3.  0.079               0.079                   < 0.5
4.  0.069               2.271                   circa 10 seconds

Case 4, if repeated, sometimes takes a lot longer, and a lot of paging seems to be going on. It appears that the Widget Engine is making very heavy work of big tables - in case 4 there are 8476 text objects.

[Cicerone Pavaloi]

there are 8476 text objects.

That is the problem.

I'm not into tables (and other stuffs with lot of numbers ), but I had in my upcomming version 2 of One Photo a similar problem with the slideshow playlist. What I did, and is working pretty quick, it something like this:
I did not create text objects for the entire (potentially huge) playlist, but only for the number of rows that are visible in the (height of the) playlist frame. When the frame is resized I create and append more text objects or remove the unnecessary ones. I have a scrollbar that is not linked to the frame (it doesn't scroll it automatically), it just scrolls through the range of playlist (0 to playlist count - number_of_visible_rows) and updates the data in the text rows starting from the "scrolled" position in the playlist array.
So, if a I have a playlist with 50020 items, and the playlist frame contains 20 rows in height, when the scrollbar is at 50% I update the text objects with data for the items from 25000 to 25020...

Edit:
The idea is not new, when working with graphics this is called cliping: just don't draw outside the visible area.

[CSM]

That is the problem.

That's one of the contributing factors why my Table implementation avoids using them ...

I did not create text objects for the entire (potentially huge) playlist, but only for the number of rows that are visible in the (height of the) playlist frame. When the frame is resized I create and append more text objects or remove the unnecessary ones. I have a scrollbar that is not linked to the frame (it doesn't scroll it automatically), it just scrolls through the range of playlist (0 to playlist count - number_of_visible_rows) and updates the data in the text rows starting from the "scrolled" position in the playlist array.

Even if it's not new, that's still a neat idea. However, that only works for the text-based table which is set up to be scrolled. Also, I know you didn't originally like the idea of the Canvas text, but that might not be a bad idea to look into either! You're welcome to borrow my "copy", as I messed with it to make it work inside Konfabulator. It creates a new Canvas for each word, but my Table has shown that doesn't really affect performance. You could also hack it further to use one Canvas to start and draw it all on there. You aren't limited to serif fonts either! Just visit the website (I listed it above and in that file) and convert some open source fonts to use ... some have said the new Droid fonts are nice (from Android).

[Cicerone Pavaloi]

You aren't limited to serif fonts either! Just visit the website (I listed it above and in that file) and convert some open source fonts to use

I can't browse to neocracy.org (probably my country is banned there )...

CODE

The following error was encountered:
Access Denied.

That may be a problem for other developers too.

[g6auc]

The idea is not new, when working with graphics this is called cliping: just don't draw outside the visible area.

I'm quite aware of that, and it is trivial to supply the tableGen function with the data corresponding to a range of rows (for example, just the rows that are currently visible).

The point of my post was to encourage/challenge CSM to do some performance tests to see just how much extra overhead his more flexible component is costing. Trying it with very small files tells you little.

This post has been edited by g6auc: Nov 12 2008, 04:47 PM

[CSM]

I can't browse to neocracy.org (probably my country is banned there )...

CODE

The following error was encountered:
Access Denied.

That may be a problem for other developers too.

No, I get it too. However, the fact that I was able to initially go there (and several times since) I know that it is possible to visit the website. It just seems to have poor uptime as of recently. I can only hope it gets better.

[g6auc]

I did not create text objects for the entire (potentially huge) playlist, but only for the number of rows that are visible in the (height of the) playlist frame. When the frame is resized I create and append more text objects or remove the unnecessary ones. I have a scrollbar that is not linked to the frame (it doesn't scroll it automatically), it just scrolls through the range of playlist (0 to playlist count - number_of_visible_rows) and updates the data in the text rows starting from the "scrolled" position in the playlist array.

I've added code to try your method in my Image Display Widget. I regenerate the visible frame whenever its contents change, either through scrolling or resizing.

This loads and displays (the visible part of) big tables very much faster, but the (vertical) scrolling and resizing are slower and not as smooth as the "native" frame scrolling. I've therefore added a small file / big file option to let the user choose which method to use, although that could be made automatic.

Starting anew, I could probably do a better job by not regenerating all of the visible frame each time it changes, but that is not a reasonable option with the existing Widget.