Tuesday, April 05, 2005

Tables static or dynamic

Right now, I seem to be caught up with tables — the (X)HTML sort. My current project has lots of them. No, not for layout; that's so last millenium. We use tables to present tabular data; results and summaries, for example. And tables to accumulate entered data prior to submitting a page. Those are the dynamic ones. The user enters data into text fields and selects from dropdowns, but instead of submiting straight away, we add (remove or edit) data to the table. A new row? Use the DOM. Hidden variables? Store them in hidden columns; or maybe in attributes of the row element.

Now the next step is in-place editing; imagine a screen displaying rows from a report. Now users want to click on a data cell and edit the data just as if it were a spreadsheet. That's interesting; I mocked up a prototype pretty fast, but them got stuck aligning the text field over the table cell. Tricky to get it right accross browsers. I'm getting there. Yesterday, I noticed that someone else was doing something similar. No tables, though. I'm not eager to have shadow edit cells for each display cell; it wouldn't scale for my requirements. I prefer to create and destroy the edit field on the fly. But encouraging that there's some one else out there trying to do something similar.

Oh and in some cases, when the user edits the data and hits enter, we have to fetch a whole new row from the server. We do that using a Javascript http client — that is the technique that just got itself a fancy new name, Ajax. But that's a new topic — I'll save it for another post.

0 Comments:

Post a Comment

<< Home