2 bugs with aoColumnDefs & aTargets

rewen

Hi Allan,

I think I've found 2 bugs with the way that classes are targetted and/or the way sClass within aTargets works.

Bug 1:

When you have two definitions such as:
[code]
"aoColumnDefs": [
{ "aTargets": ["dt-center"], "sClass": "dt-center" },
{ "aTargets": ["dt-currency"], "sClass": "dt-currency" }
]
[/code]

And in your HTML you have:
[code]

Dollars

[/code]

Only the first of the two definitions will be applied to the 's in despite both definitions matching

Bug 2:
When you have definitions such as:
[code]
"aoColumnDefs": [
{ "aTargets": ["dt-editable"], "sClass": "dt-editable" },
{ "aTargets": ["dt-editable2"], "sClass": "dt-editable2" },
{ "aTargets": ["dt-editable3"], "sClass": "dt-editable3" }
]
[/code]

And in your HTML you have:
[code]

Received
ShipBack
Comments

[/code]

The second and third 's will get class dt-editable applied to them because of the first definition. And as a result dt-editable is also applied to all of the 's in for all 3 columns. This happens in any situation where one class name is found within another class name. Ex: aTarget "ab" would also match a with class "abc".

I've worked around bug 2 by simply changing dt-editable2 to dt-editabl2, and dt-editable3 to dt-editabl3, so that there are no definitions that are within other definitions. Bug 1 I have not been able to work around yet.

allan

Hi rewen,

Thanks for the detailed bug report :-)

1. Yup I see what the problem is - but it is actually working as designed at the moment. The reason I say that is that the definitions in aoColumnDefs are not cumulative but rather will replace any setting which might have already been applied by another definition. So example if you had:

[code]
"aoColumnDefs": [
{ "aTargets": ["dt-center"], "fnRender": render1 },
{ "aTargets": ["dt-currency"], "fnRender": render2 }
]
[/code]
it won't apply fnRender multiple times to a single column - but use just the last one that was applied. This is true for all column properties - including sClass. Which is why one of them is getting priority over the other. I'm wondering if sClass should be a special case which is cumulative... I'm not sure to be honest, but I do see how it would be useful! Let me think on it.

2. That certainly is a bug - it was me trying to be a little bit too clever and just use indexOf for speed, which obviously isn't good enough. Speed isn't hugely important at this point since it only executes once per column during init. I've just committed a fix for this, which will be in 1.8. The dev version can be grabbed from here: http://datatables.net/download/ .

Regards,
Allan

rewen

Thanks Allan!