DataTables 1.5.2 released - ThemeRoller support

DataTables 1.5.2 released - ThemeRoller support

I'm very pleased to be able to released DataTables 1.5.2, now with full support for jQuery UI's ThemeRoller! :-) There are a couple of bug fixes in there as well, which will solve a few niggling problems some of you have encountered.

You can see an example of the ThemeRoller integration in action here: http://datatables.net/styling/themes . Special thanks go to Brian (bchic869) and Tom (TomC) for their work in getting this kick started. Enabling ThemeRoller support is done through the bJQueryUI ( http://datatables.net/usage/features#bJQueryUI ) initialisation parameter, which is required in order to preserve backwards compatibility for styles which have already been applied to DataTables.

Allan, I found the bug that is putting the sort arrows on a new line. Since you are floating them right the spans for the arrows need to come before the header text node. Just inserting them ahead of the textnode should work.

When you use float:right if you want the element to be on the first line you have to have the floated element come first in the document. I've never been clear on why they did this but I assume it has to do with browser parse order. Maybe parsing the floated right item first lets the browser move it then continue adding stuff to that line?

The way to do it with CSS only in the document order you have is to not use a float:right instead you'd have to not use float and make sure the span is an inline element and then add margin-left to position it. There area couple problems with that including the themeroller definition that makes ui-icon use display:block.

The usual CSS technique to position block elements is to lead with right floated elements so I thought that changing the position in the document of the element would better support themeroller CSS.

I forgot to add there is another way to fix this that maintains your original document order but it requires adding more boxes around the text in your th. I assumed less markup is better so went for the document order fix instead.

Is there any way I can see your actual code or site? It looks like a CSS problem but its hard to diagnose without seeing the stylesheets. Did you replace all workaround stylesheets with the themeroller stylesheet?

The problem here, I think (it's a bit tricky to tell for sure as Tom points out), is basically that there simply isn't enough room to show the column title and the sorting arrows next to each other. In the first column, there is enough room and everything works fine in both browsers (from your screenshots), but when there isn't enough room and the column is quite small, the behaviour of the two browsers is different, with FF overlapping them and IE spacing them out (I've not idea which is correct actually, but going by the law of averages...).

Therefore the simple solution is just to make your table nice and wide so each column does have enough room :-). Might not be as simple as that though, since your table might need to be _very_ wide for that to work correctly with the automatically wide calculation. As such, I'd recommend setting bAutoWidth:false, and then defining the width you want for the columns explicitly (either in the HTML with etc, or using sWidth in DataTables).

Hi,
To follow up on the issue with Themeroller and the sorting arrows, I added the float right to the icon and white-space nowrap to the th tag which helps a lot. However, on columns where the heading text is short, the heading text and sort icon overlap using Firefox. I haven't looked through things extensively, but it appears that the setting of the column widths is not taking the icon into account. Is it possible to change this somewhere?

One other question. What woudl be the best way to move the "Showing x to y of z entries?" I'd like to move it to the top bar instead of the bottom bar. If I change sDom to iflrtp, the table design breaks pretty badly.

I just started looking at this. The original oneoff version I did used sDom to add all the jQueryUI classes and divs I needed. It looks like in the current implementation using sDom and bJQueryUI at the same times lets sDom overwrite all the classes and divs that bJQueryUI adds to the table. I'm looking at ways to make them work together but frankly I hadn't even talked to Allan about it yet. I'm wondering if there will need to be a version of sDom that only changes positioning of the elements as adding divs and extra classes will ikely mess up the bJQueryUI stuff. Or do we extend bJQueryUI further to allow sDom like element positioning.

Don't know if this is relevant, but if bAutoWidth is set to false, the sort icons no longer overlap with the column headings. Unfortunately, the width of the bars above and below the table (fg-toolbar) does not match the width of the table.

@TomC: I also use sDom internally to set up the containers and class names that jQuery UI provides. If you have a look at the source code, you'll see the following defination at one point:

[code]
oSettings.sDomPositioning =
''+
't'+
'';
[/code]
(sDomPositioning is just my internally naming for sDom - I'll change it some day...). As such, if you want to move the elements around while using jQuery UI, you need to use something like this, and move the ipt etc elements around as needed. It's not very elegant, but it was the only way I could see which would provide the flexibility that is required from this. What do you think?

@msruby64: Most likely the columns aren't wide enough for the sort icons to be alongside the title text when DataTables does it's auto width calculation. The way around this (or at least one of them) is to set bAutoWidth:false, and given each column the width that you want it to have (either in the HTML or sWidth in the initialisation object).

Yeah Allan I did look at that. all I did was move the sDom notation around in that line. I guess that isn't the ideal implementation but it works great if you don't want to wait for a new release.

I'm wondering if we couldn't take the sDom "variables" as arguments for the bJQueryUI and then add them back in. Or change bJQueryUI to only add class names. I have family in town but may be able to hack around on it later this week.

I think you are right that having the options as variables is indeed possible, by my concern is that it will reduce the flexibility of sDom when using jQuery UI support. Perhaps it would be cleared is it was something like:

Yes I see how this would work, however, I'm somewhat reluctant to use this method, because it limits the use of sDom artificially. For example, if you wanted to add a class to the header element, you couldn't (there was another question somewhere in the forum with someone asking how to do that).

So what I'm wondering is if it might be an idea to use substitution in sDom, and provide the jQuery UI classes as substitutes. So if we have something like:

I like how short your solution is but I'm not sure how my version could limit sDom. The addClass method will not replace anything added with sDom. Also, how will [code]

't'

[/code] allow someone to use both sDom and bJQueryUI at the same time? I'm hung up on this because the configuration I use doesn't have a div at the bottom of the table. So ideally I'd use sDom to rearrange the elements and bJQueryUI just to decorate the table.

OHHHHH I think I just realized what you are saying. Are you saying get rid of the bJQueryUI method completely and make H and F "official" arguments for the sDom method that automatically add the jQuery UI classes?

Yes that's more or less what I was getting at. There would actually still be a requirement for bJQueryUI since it effects the market that DataTables produces for the table. However, I am indeed proposing to make H and F accepted arguments for sDom to allow the required jQuery UI classes to be applied cleanly and in a readable manner, while still allowing the full range of flexibility that it currently provides. Sound reasonable?

Just a quick idea. Why not make the H and F available to editing in the oSettings.
So they are initialy set depending on bJQueryUI (so either blank or JQueryUI classes), then added to by what ever setting people want in the oSettings (kind of an extensions class list).
[code]
// this in the oSettings
"sDomHeaderExtraClasses": "my-own-classes",
"sDomFooterExtraClasses": "my-own-footer-classes",
"sDom": 't'

// then do H and F replacment for these values.
[/code]
Then the H and F would give loads more flexibility, clean up the sDom values nicley, and then custom classes would not break the JQueryUI classes. This is similar to something i was doing at a little while ago for my old job where they wanted to add extra classes which seemed to overwrite the JQueryUI ones. Cant remember the code I used now but it did seem to work quite well.

I quite like the option of having H and F defined as the jQuery UI classes, even when bJQueryUI !== true. The reason for this is two fold:

1. You might want to use the jQuery UI classes without the DataTables jQuery UI markup (which is mainly in the sorting) - say just to style in sDom or something
2. If H and F are blank without bJQueryUI, then there is no point in specifying them anyway.

sDom needs to be different for jQuery UI on and off out of necessity since the structure has to be slightly different, and I'd like to maintain as much backwards compatibly as possible. So effectively H and F would be short hand macros for those long class strings. The classes themselves would be customisable through the $.fn.dataTableExt.oStdClasses and $.fn.dataTableExt.oJUIClasses objects for giving custom classes.

This sounds like we are coming up on an awesome solution and one that really extends sDom. I'd love to see either of those solutions though I think Allan's idea of changing the classes through dataTableExt is more in line with the way the rest of dataTables is extended.

Agreed, I think this will make sDom a lot easier to use when using jQuery UI theming in DataTables. I've implemented this and it works quite well, but the one thing I'm wondering about now is if H and F should be hard coded to be the set of classes I've specified. Couple of reasons:

1. Less scope for things going wrong when trying to add your own custom classes
2. Easier for debugging etc since that are static
3. Having them in both oStdClasses and oJUIClasses could be confusing and certainly redundant
4. Still easy to add classes ( t - etc)
5. Modifying and removing classes could be done using something similar to my post about 10 back up with sHeaderClasses.

If they are hard coded and someone adds H and/or F to sDom but doesn't use bJQueryUI would you want any error handling? Like ignoring H and F without specifying bJQueryUI? Or is that too heavy handed and it's just "buyer beware"?

I think they should be static regardless of bJQueryUI. They could potentially be useful if you want to use jQuery UI themes, but not invoke the DataTables code specifically designed to handle that (the sorting header icons for example). Not sure why one would want to do that, but it's an option... If you see H or F in sDom you know you are going to get that class string - hopefully fairly bullet proof.

If and when I get around to making a debug version of DataTables, then this would be a prime candidate for a strong warning message if you use H or F without bJQueryUI...