Best Row Detail Solution - What is the most efficient method of having a second row per record?

Rob

Best Row Detail Solution - What is the most efficient method of having a second row per record?

I'm currently using the "row detail" method with the open/close button. I've found that if a field is edited (via jEditable), all opened details are closed. I foresee this behavior, along with having to open the details for multiple records to properly identity a record, being a user experience issue. To make the interface more intuitive and head off potential negative feedback, I'm trying to come up with the most efficient solution.

Two solutions come to mind:

1. Have a permanent second row per record. There is a thread in the forum on this, but the proposed (and untested by me) solution doesn't seem like the most efficient method of having a second row per record.
http://datatables.net/forums/comments.php?DiscussionID=120&page=1

2. Alter the functionality of the "row detail" method (which I'm currently using).
http://datatables.net/forums/comments.php?DiscussionID=227&page=1#Item_0

2a. Have all of the details open by default, instead of being closed.

2A. In addition to having the row details open by default, remove the open/close button functionality (thus an alternate method of producing a permanent detail row).

2B. Better yet, create an option (e.g., a button or checkbox) to open/close all row details. This option would work on all records, not just those displayed, like a toggle. This setting should be "remembered" via a cookie (the datatables cookie?).

I like the thought of either a permanent detail row or toggle switch for row details. That said, I'm not sure what the best (most efficient) way of going about it is. I'm working with the row details now, since I've already got that functionality implemented.

Any feedback is appreciated. Thanks!

Rob

Rob

Simply copying the "Initially have all row details open" code outside the click function will initialize the table instance with all details open while retaining the open/close functionality. This isn't ideal from a user experience perspective, but may be a first step. Note (again) that redrawing a row when updating a value via jEditable will reset the initial row detail state (which may contribute to user frustration).

As I look into this functionality (which may go in a completely different direction :) ), I'll continue to post the associated code. Hopefully someone finds this helpful. If someone has already done this, feel free to save some of my time! ;)

[code]
function fnOpenClose ( oSettings ) {
$('td img', oTable.fnGetNodes() ).each( function () {

// Initially have all row details open
var nTr = this.parentNode.parentNode;
this.src = "IMAGES/details_close.png";
oTable.fnOpen(nTr, fnFormatDetails(nTr), 'details');

// Open/Close row details when clicking row detail button
$(this).click( function () {
var nTr = this.parentNode.parentNode;
if (this.src.match('details_close')) {
// This row is already open - close it
this.src = "IMAGES/details_open.png";
// fnClose doesn't do anything for server-side processing - do it ourselves :-)
var nRemove = $(nTr).next()[0];
nRemove.parentNode.removeChild( nRemove );
} else {
// Open this row
this.src = "IMAGES/details_close.png";
oTable.fnOpen(nTr, fnFormatDetails(nTr), 'details');
}
});
});
}
[/code]

allan

Hi Rob,

What I tend to do for this kind of thing is to have the information we want to display in the table as a column (or multiple columns), which I see you are using as a basis:

http://datatables.net/1.5-beta/examples/api/row_details.html
http://datatables.net/1.5-beta/examples/server_side/row_details.html

These could certainly be expended to use cookies etc. Why would you have all rows open initially?

Thanks,
Allan

Rob

Update:

As is, this code functions on the first datatables instance, but causes the following error:

oTable.fnSettings().aoData[iIndex] is undefined

This issue may be easy to remedy, but I don't have the time to look at it now. I just wanted to give anyone interested in this a heads up.

Allan - Thanks for your feedback! Yes, I used your server side row details example (thank you). The details row contains a single field, which happens to be a verbose description. Some of the descriptions are so long that as a column, a single record can utilize more than a screen to display, making it difficult to navigate the records (think of several nice-sized paragraphs being squeezed into a 2.5" column). The details should be displayed initially because it's possible that a user will be unable to identify the record just by referring to the displayed columns.

I feel confident that the direction I'm taking is for a permanent detail row. There may be a toggle checkbox/button (details on/off), which is set "on" by default. The details button will be removed, which will have the added benefit of allowing more space for data.

An alternate option I just thought of (as I read another forum post) is the possibility of returning the row detail to a column and using an "ellipsis" to truncate the description. I'm not sure how I'd handle that and still like the idea of a second row better, though... but as in the "cloning" example (http://datatables.net/forums/comments.php?DiscussionID=120&page=1) (as I understand it), it'd be nice for the row details to inherit properties/functionality of the record they're associated with.