Compact web form type #2
In some cases, at edit database record, it is usefull to see also data from neighbouring records, eventually to see complete database table. For example, when edit capacity standards for new product type fits to see older, already checkout data. Or else, when editing technological procedure in application Mould and Tools it is desirable to see whole techological procedure description when edit one suboperation. Some simple tables, typically codebooks, are as well suitable for editing with help of this form type.
In principle, complete table is displayed at first. By click on specific row, edit form opens only for this one row. Form is visual part of table and such method of editing could remind the work with spreadsheet. I call that inline editing.
Example form here is not fully interactive (form keeps open on default row, it is not possible to select other row, edited data are not saved). The purpose of this live form is illustration how to display tabular and form data in one common table and keep maximum uniform appearance in various browsers.
Alignment of tabular and form data on the left and on the right conform in browsers IE and FireFox. Opera browser makes 1 pixel error in number justification. That is caused by setting padding: 0 1px 0 0;. Using padding: 0; removes error, unfortunately then text cursor disappears at right margin of form element in IE and Opera. Problem also makes checkbox, which influences the height of form row. Crossbrowser unified height of form row is very difficult to reach because of hardly stylable checkbox. The width of simple table and table with form are identical in IE, FF and Opera browsers.
It seems, that Safari do not understand this type of fixed layout table. Created table is off the specified size. Nor alignment text and numbers in table and form is not error free.
In real application, after form submitting and data saving, server returns the same, updated table to enable user edit next row. It is convenient to set background color of last edited row for easy backward verification of entered data. Sometimes it is good to extend form by auxiliary button for quit edit mode (close form), eventually by another button for record delete. In codebook, where it is not possible to delete records, form element <input type="checkbox" /> can be used to switch record's active status.
Table formatting and row cursor are described in article table and CSS.
<style type="text/css">
/* ---- table ----- */
table, input {font: normal 13px Arial, SansSerif, Verdana;}
table {
border: 0;
border-left: 1px solid #aaa;
border-top: 1px solid #aaa;
table-layout: fixed;
}
th, td {
border: 0;
border-right: 1px solid #aaa;
border-bottom: 1px solid #aaa;
}
th {
background: url(/at/files/bg_table.png);
font-weight: normal;
border-left: 1px solid #cff;
border-right: 1px solid #358;
}
td {text-align: center; padding: 0 4px; margin: 0;}
.tdL {text-align: left;}
.tdR {text-align: right;}
/* ------- form -------- */
td.inp {background: #ffa;}
.iL, .iR, .iC {width: 100%; margin:0; border:0; padding: 0 1px 0 0;
background: #ffa; float: left;}
.iL {text-align: left;}
.iR {text-align: right;}
.iC {text-align: center;}
.ok {width: 13px; height: 14px; margin: 0; border: 0;}
</style>
Long page
At work with this form type takes turn request to server for form opening, followed by request to save form data (and close form). Server always returns the same (slightly modified) table. As far as page exceeds the high of browser we need to keep vertical position of scroll bar in order to keep page returned from server in the same vertical position. Otherwise we would have to roll vertical scroll bar and search open form, or just modified row.
Following script returns top position of vertical scroll bar. This value is saved by validation script to hidden form field before submit to server. Server returns the position of vertical scroll bar in the statement for page scrolling scrollTo(...) in body element.
<script type="text/javascript">
...
function topSL() {
if (window.innerHeight) {
return window.pageYOffset; // FF
}
else if (document.documentElement && document.documentElement.scrollTop) {
return document.documentElement.scrollTop; // IE
}
else if (document.body) {
return document.body.scrollTop;
}
return 0;
}
</script>
<body onload="scrollTo(0, 245)">
...
</body>
If you got idea, that for similar way of edit database tables fits technology Ajax, I'd like to share my experience. At first I tried dynamically change the content of row <tr> to form row and after saving changes back to data row. That worked in IE only. Therefore I replaced table with system of nested tags <div>. Then that already worked in common browsers.
Unfinished stayed server side error processing and row "switching". Writing to the database is critical point of each web application. At classical method of work with form, at server script error, bug report page is returned. Some users print that, send by e-mail, or call and dictate line and error number to programmer. In case of Ajax, no error messages are displayed. The worst errors are that one, you do not get to know.
I made balance. At minimum one additional server script, client script for keeping vertical position of page is not need in case of using technology Ajax, another slightly complicated script for sending and recieving of XMLHttpRequest messages is needed. CSS section was longer thanks to many tags <div>. Resulting effect from user point of view was identical.
Forms for inline editting then stayed at original, classical version (for the present). New technology would had either simplify solution, or bring new experience. To change existing solution only therefore, that is available something new, seemed to me purposeless.
updated 25.12.2007