DataTables 1.5.2 released - ThemeRoller support

allan

Hello all,

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.

You can download DataTables 1.5.2 here:
http://datatables.net/releases/dataTables-1.5.2.zip

Full release notes:
http://datatables.net/download

Also, please remember to make a donation to help support DataTables for future releases and support in this forum :-) :
http://datatables.net/donate

Enjoy!

Regards,
Allan

TomC

Awesome! I need to look into updating to this version of datatables and taking out my theme code! Great job Allan!

TomC

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.

Here we go:

Your code line 2211:
[code]oSettings.aoColumns[i].nTh.appendChild( nSpan );[/code]

Replace with:
[code]var fNode=oSettings.aoColumns[i].nTh.firstChild;
oSettings.aoColumns[i].nTh.insertBefore(nSpan,fNode);[/code]

allan

Hi Tom,

Thanks for this. Doesn't this change just require slightly different CSS to achieve the same effect? Or is the float:right causing issues?

Regards,
Allan

TomC

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.

allan

Hi Tom,

Thanks for the information - I hadn't considered that this would be used with block level elements as well. Your fix will be in the next release. Thanks :-)

Regards,
Allan

raycist

Hi Allan and Tom,

I just update my DataTables to 1.5.4 and now I am seeing that the sorting arrows, is now shown above the header.

The dom looks like this now, which is supposedly the solution to make the arrow be on the right side of the table header.

[code]


Service

[/code]

Can you shed me some light on this problem?

Thanks,

- Ray

allan

Hi Ray,

Do you have .css_right { float: right; } in your CSS? That is required to float the arrow icon across.

Regards,
Allan

raycist

Hi Allan,

Thank you for the lightning fast reply (<1hr), I tested my project after adding your solution and the results is as follow

it works great on chrome

In FF3, the headers are shown as 1 line, but the arrow overlaps with the header text.

in IE, The arrow stills shows up on top and the header text at the bottom. (EXCEPT for the first column).

I will try to post pictures really soon. This problem is really weird.

Thanks

- Ray

raycist

Hi Allan,

I uploaded the screenshots in flickr, hope you can access it.

http://www.flickr.com/photos/30000893@N02/4057169150/ - in IE
http://www.flickr.com/photos/30000893@N02/4057169136/ - in FF

Thank you very much in advance,

- Ray

TomC

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?

allan

Hi Ray,

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).

Hope the helps,
Allan

raycist

Hey Allan and Tom,

@Tom: Yes, I only used the themeroller stylesheets (you mean the JQuery UI right?). The only thing I added is .css_right { float: right; } in the css.

@Allan: You were right on the problem, there is not enough room in the header. The solution was I ended up assigning the table widths manually.

Thank you very much for both of your help. (I felt that I am asking about basic css questions instead of data tables related question.)

allan

Hi Ray,

A perfectly valid question I think, with direct impact on DataTables ;-). Good to hear you got it sorted!

Regards,
Allan

msruby64

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.

Thanks for all your work.
Mitchell

TomC

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.

msruby64

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.

allan

Hi guys,

@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 =
'<"fg-toolbar ui-widget-header ui-corner-tl ui-corner-tr ui-helper-clearfix"lfr>'+
't'+
'<"fg-toolbar ui-widget-header ui-corner-bl ui-corner-br ui-helper-clearfix"ip>';
[/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).

Regards,
Allan

TomC

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.

allan

Hi TomC,

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:

[code]
var sHeaderClasses = '"fg-toolbar ui-widget-header ui-corner-tl ui-corner-tr ui-helper-clearfix"';
var sFooterClasses = '"fg-toolbar ui-widget-header ui-corner-bl ui-corner-br ui-helper-clearfix"';
oSettings.sDomPositioning =
'<'+ sHeaderClasses +'lfr>'+
't'+
'<'+ sFooterClasses +'ip>';
[/code]
Regards,
Allan

TomC

What if you use that as the code if the sDom method isn't called and if it is the sHeaderClasses variable can be added with jQuery?

Pseudo code:
[code]
if( sDom){
if(sDom Div Before Table){
$(sDom Div Before Table).addClass(sHeaderClasses);
}
if(sDom Div After Table){
$(sDom Div After Table).addClass(sFooterClasses);
}
} else {
oSettings.sDomPositioning =
'<'+ sHeaderClasses +'lfr>'+
't'+
'<'+ sFooterClasses +'ip>';
}
[/code]

I've got too much company to sit down and write this correctly right now. :)

allan

Hi TomC,

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:

[code]
// Sub H for 'fg-toolbar ui-widget-header ui-corner-tl ui-corner-tr ui-helper-clearfix';
// Sub F for 'fg-toolbar ui-widget-header ui-corner-bl ui-corner-br ui-helper-clearfix';

// jQuery UI sDom default:
'<"H"lfr>t<"F"ip>';
[/code]
That seems to clean things up quite a bit, possibly making it that bit more accessible. What do you think?

Regards,
Allan

TomC

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]

'<"H"lfr>t<"F"ip>'

[/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.

Modification to bJQueryUI I currently use:
[code]

oSettings.sDomPositioning =
'<"fg-toolbar ui-widget-header ui-corner-tl ui-corner-tr ui-helper-clearfix"lirpf>'+'t';
[/code]

TomC

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?

So the new sDom Documentations would be:
H - Classes for jQuery UI header div
F - Classes for jQuery UI footer div
l - Length changing
f - Filtering input
t - The table!
i - Information
p - Pagination
r - pRocessing
< and > - div elements
<"class" and > - div with a class
Examples: <"H"lirpf>t //Example includes header div classes

allan

Hi TomC,

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?

Regards,
Allan

izzy6150

Hey Guys,

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": '<"H"lfr>t<"F"ip>'

// on initialisation within dataTables
if (bJQueryUI)
{
oSettings.sHeaderClasses = 'fg-toolbar ui-widget-header ui-corner-tl ui-corner-tr ui-helper-clearfix ' + sDomHeaderExtraClasses;
oSettings.sFooterClasses = 'fg-toolbar ui-widget-header ui-corner-bl ui-corner-br ui-helper-clearfix ' + sDomFooterExtraClasses;
}
else
{
oSettings.sHeaderClasses = 'fg-toolbar ' + sDomHeaderExtraClasses;
oSettings.sFooterClasses = 'fg-toolbar ' + sDomFooterExtraClasses;
}

// 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.

Regards,
Izzy

allan

Hi Izzy,

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.

What do you think?

Allan

TomC

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.

allan

Hi guys,

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 ( <"H my_header"lfr>t<"F my_footer"ip> - etc)
5. Modifying and removing classes could be done using something similar to my post about 10 back up with sHeaderClasses.

What do you think?

Regards,
Allan

TomC

I think they probably should have a hardcoded default.

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"?

allan

Hi TomC,

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...

Regards,
Allan