Adding another header row

peterkronenberg

Allan,
How can I add another header row? Datatables is building the header. There doesn't seem to be away to add another row.
I want to use it as individual column filters as in http://datatables.net/examples/api/multi_filter.html. I know there has been a lot of previous discussion about putting these filter controls in the header as opposed to the footer. It's not clear if all the issues have been resolved, e.g., for hidden columns

allan

You need to do an $().append() or appendChild to the THEAD element with your second TR row - DataTables will not add this automatically, and there is no option to do so. Multi-filter works just fine with hidden column - just remember to take into account the hidden columns if you are using $().index() to calculate the column index to pass to fnFilter.

Allan

peterkronenberg

The problem is if the column is hidden, appending to THEAD won't work. I need to append directly to the DataTables structure, don't I?
When I needed to iterate through hidden TDs, you pointed me to fnGetTd and fnGetTds. Is there a similar option for the header?

allan

Ah yes I see what you mean. You would need to attach the hidden element to the internal pointer that DataTables has ( aoColumns[].anThExtra[]). It's do-able but it will be messy, and reliant on the internal structure of DataTables not changing.

A cleaner approach might be to simply create an HTML table and then initialise DataTables on that.

Allan

peterkronenberg

I guess DataTables is not as good as I thought when it comes to letting it handle the initialization of the data. Don't get me wrong. It's great and I will continue to use it. But when I first discovered it, and saw how the data is passed using the aaData array, I assumed that was the way to go. One of the main reasons I started to do that was because DataTables was much faster at initializing the table with lots of data, since it doesn't have to create all the TR's. Only those that are visible.
Directly modifying the DOM is fine for visible data, but if DataTables is going to support hidden columns, which is a great feature, there need to be more api's to handle that hidden data.

I'm not sure yet if I'll go this route. Can you give me a brief synopsis of how anThExtra is used? Does it basically contain all the TH's in a TR? Will it be ok to have 2 rows of TH's or does the 2nd row need to use TD?
Would I have to call fnReDraw after I add the row?

allan

> One of the main reasons I started to do that was because DataTables was much faster at initializing the table with lots of data, since it doesn't have to create all the TR's. Only those that are visible.

This isn't quite right. DataTables will create all TR elements that are needed in order to display the table. There are trade offs for using aaData (as you are finding out...), it can sometimes be faster, but equally there are times when it can actually be slower (reading the DOM v creating it) and generally less flexible. DataTables is mainly focused on progressive enhancement, rather than creation of DOM elements, which is why this isn't possible at the moment, nor is it likely to be added to the core (a plug-in might be an option).

> Can you give me a brief synopsis of how anThExtra is used?

Basically it's one element in the array for each extra row (note that colspan / rowspan will throw it out completely and are not supported for hidden columns). So if you had two TR elements in THEAD there would be one extra TH to have in the extras array.

I personally wouldn't modify anThExtra externally in my own projects, although as I mentioned it is possible to do - just messy and if I change it, it would break your app (it's an internal variable so no guarantee it won't change - although obviously it wouldn't be done lightly...).

Allan

peterkronenberg

I suppose the easiest way might be to initialize the table with all columns visible and then hide the columns that I want to be hidden from the beginning.

peterkronenberg

Oh, I just saw this for fnSetColumnVis: Set the visibility of a given column on-the-fly. Please note that this function does not support 'complex headers' (colspan and rowspan on columns) or multiple rows in the header / footer.

Is it still true that this won't support multiple rows in the header? Does the ColVis plug-in support this or setting bVisible to false?

allan

That statement is still true in the 1.7.4 stable release, but not in the 1.7.5 development on where I have committed a change to take multiple rows into account (the anThExtra parameter is new in 1.7.5 dev). ColVis also supports this now (again in dev), and I've added an example to ColVis which specifically shows column input filters in the header :-)

Allan

peterkronenberg

That's great! I'm already using the 1.7.5 dev release.

Is the ColVis example posted yet?

allan

The example is actually a ColReorder example, but it uses ColVis as well: https://github.com/DataTables/ColReorder/blob/master/col_filter.html

Allan

peterkronenberg

Thanks. Does this work with the current nightly versions of ColVis and ColReorder? Do you have the examples online so I could actually see it in action?

peterkronenberg

Looking at the code, what is _fnVisibleToColumnIndex? I don't see that documented anywhere

What's the difference between that and looping through oSettings.aoColumns[].nth?

allan

> Do you have the examples online so I could actually see it in action?

Not yet - they will be publicly visible when that software is released. Until that time you can check the code out from Github and get all the examples.

> _fnVisibleToColumnIndex

This is an internal method (hence the underscore indicating it should be treated as such), so it's not documented anyway other than the code comments - although it can still be useful :-). It's not a defined public function for the same reason as most of the other internal functions, they don't need to be. But it is accessible and could be accessed using a plug-in API function if you wanted a proper public API.

> What's the difference between that and looping through oSettings.aoColumns[].nth?

That is effectively that this method does - it just does all the leg work for us. No point it rewriting existing code :-)

Allan

peterkronenberg

What's the difference between getting the code from GitHub and the nightly builds that you have?

allan

Nothing - the nightly build process checks out the latest code from GitHub and builds it (for the min file). However GutHub includes all files in the distribution, where as the nightly is of course just the main JS files.

Allan

peterkronenberg

Allan,
When I create a second header row using TD's, FixedHeader gives me an error at initialization:
[code]
jQuery("thead:eq(0)>tr th:eq(" + i + ")", nTable)[0].style.width is not a function

Line 658
[/code]

Seems to work ok with TH, but it's early still :-)

peterkronenberg

Got your example working. Had the same problem with the TD's from FixedHeader. Had to change them to TH. But FixedHeader creates another problem. There's some weird behaviour of the keyup handler. After one keystroke, the field automatically loses focus. I can't quite figure out how to fix it. I need to disable FixedHeader to get it to work. I tried just putting the keyup handler only on the FixedHeader nodes, since that is the one on top, but that doesn't seem to fix it either.
Any ideas?

allan

The reason for this is that the table is being recloned on every draw of the table - resulting in the HTML elements being recreated, and thus the old element which had focus is destroyed and the new element which does not have focus is inserted.

This is basically a limitation of the current implementation of FixedHeader as it stands at the moment. Oddly enough just a couple of days ago I committed a change to FixedColumn so that it doesn't have this problem, and something similar can probably be done for FixedHeader in future. I've added it to my to-do list.

Allan

peterkronenberg

Hmm, there is no workaround at all? No way to have input elements in the header while using FixedHeader? So after all the fighting I've done with FixedHeader, it looks like I'm going to have to drop it :-)

I guess the other option would be not to use a keyup handler and just have the user press enter after he has completed his search term. I'll no longer have the cool real-time update, but at least it will work.

allan

You can have the elements in the FixedHeader, but they aren't particularly usable for the reasons discussed above. It just needs a modification to the code to stop it from doing the full clone on every draw, which I'll look at doing as soon as I can.

I recently put together an example of individual column sorting with FixedColumns and ColReorder, and it's fairly cool :-). So something that is worth adding to FixedHeader in future.

Allan

peterkronenberg

I added the following to your keyup handler:

[code]
if (e.which !== 13) {
return;
}
[/code]

which only does the filtering when the user presses enter. Although functionally it works, it's still not user-friendly because the search term is no longer visible to the user, since FixedHeader has rebuilt the cell.

Drat.

allan

A work around might be to add an fnDrawCallback function that will stick the value back into the newly created element...

Allan

peterkronenberg

by the time fnDrawCallback is called, has FixedHeader also re-drawn everything? This is tricky because I have header elements in both the regular table and the fixed header

allan

It probably isn't actually thinking about it - since FixedHeader is initialised after the user configuration for the table. It would be possible to work around this by manually adding to the aoDrawCallback array... Another option is to just add a little setTimeout into your callback function.

Allan

peterkronenberg

This is getting far too complicated. Also, during the callback, fnFilter is getting called and is somehow forgetting that I was only filtering by a single column and it is adding my search term to the general input field. And not only do I have to remember the values of my input fields, but I also have to reset the initVal as well as the class. Deadline is coming up. I think I'm going to have to give up on FixedHeader.

allan

Another option would be to used the scrolling option in DataTables and put the filter into the header there. But it depends on the interaction you want :-)

Allan

peterkronenberg

At this point, I think I'll just wait for FixedHeader to be fixed, whenever that happens.