Cross-browser DHTML/JS Excel-like "GRID"

[Questman]

Good afternoon,

Does anyone have any code that implements, or approaches implementing, a
cross-browser DHTML/JS solution to provide an Excel-like Grid on a web
page - I'm trying to convert an old Java client/server data maintenance
program to the web - the main display is in a grid format, which allows
the user to select multiple rows and edit them in a new grid, which
processes each grid line individually and validates and saves the data.
In addition users enter new data in another new grid that allows them
to manually type data in and val/save, or paste from, say, excel.

I thought I recalled seeing someone implement this sort of thing, and
I've actually gotten some of it to work IE-centric at one point, but
never finished it, and I'd love a more cross-browser (IE and FF at
least) approach.

Thanks!

Rick

[mouseit101]

You casn use like absolutely positioned textboxes and the eval()
function no?

[RobG]

Questman wrote:

Good afternoon,

Does anyone have any code that implements, or approaches implementing, a
cross-browser DHTML/JS solution to provide an Excel-like Grid on a web
page
A 'grid' can be implemented as a table - get your data and write it into
the cells, one row per record. There are sortable tables that let you
sort by particular columns and to re-size them - but that may not be
what you want (it may add unnecessarily to the script overhead).

There is one here:

<URL:http://www.kryogenix.o rg/code/browser/sorttable/>

Its speed is OK for a few rows (or maybe 30 or 40 on fast machines), if
more are required the sort can be significantly optimised.

I'm trying to convert an old Java client/server data maintenance
program to the web
There are two basic ways to port the client component an application:

1. Make a duplicate of the interface and have it behave exactly as it
did on the original (well, as near as can be done anyway).

2. Look at *what* the application does and replicate that, taking
advantage of the new platform's strengths and avoiding or mitigating the
weaknesses.

Usually 1. is a waste of time, it is really only suitable where die-hard
users absolutely refuse to change they work or the new environment is
pretty much exactly the same as the old (and the application works well
enough that it doesn't need optimising).

Point 2 tries to actually deliver something better and more efficient -
if it doesn't, what's the point of the port? Trying to slavishly copy
functionality to another, very different platform will almost certainly
result in so many trade-offs that rather than a clean port you get some
kind of bastard child that kinda works but not really.

the main display is in a grid format, which allows
the user to select multiple rows and edit them in a new grid, which
processes each grid line individually and validates and saves the data.
You can do that by putting checkboxes on the rows to be edited then have
an 'edit selected' button, or you could make it so that clicking on a
row makes it editable. Or you could just load it into a form in a table
and let users edit as they please.

In addition users enter new data in another new grid that allows them
to manually type data in and val/save, or paste from, say, excel.
Use a form for manual entry, pasting from other applications is
problematic - text pasted from Excel seems to be tab delimited with
returns between records, so you may be able to paste into a text area
and parse it to put values into a form.

I thought I recalled seeing someone implement this sort of thing, and
I've actually gotten some of it to work IE-centric at one point, but
never finished it, and I'd love a more cross-browser (IE and FF at
least) approach.

That shouldn't be a problem if you develop in something other than IE
(say Mozilla or Firefox), then test in IE you will likely get the job
done faster and have fewer (maybe zero) cross-browser issues.
--
Rob