Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Manual resizing of columns #15

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
2 participants
Contributor

thegrandpoobah commented Jul 11, 2011

Basically, this patch adds a third method for sizing columns in the DataTables.net code base. The first method is the bAutoWidth path which sizes the columns based on the dimensions of their largest visible text. The second is to set the widths during initialization, turn off bAutoWidth and never adjust them again. This third method basically gives full control of column sizing to the user.

The user would modify th eaoColumns[n].width field in the fnSettings property bag to specify new fixed column widths and then calling fnAdjustColumnSizing to apply the new widths exactly. Without this patch, fnAdjustColumnSizing would call the fnCalculateColumnWidth function (if bAutoWidth is true) thereby modifying the values the user gave, or if bAutoWidth is false, the fnAdjustColumnSizing function is no-op. This lets the user set bAutoWidth to false and applies their specified column dimensions.

If you have any questions please do let me know.

Contributor

thegrandpoobah commented Mar 7, 2012

Allen, any thoughts on this one? We find it useful anyways :)

(Sorry for constantly bugging you, I am trying to upgrade to 1.9.x and want to see what patches I have to reapply, so I'm cleaning out my pull queue)

Owner

DataTables commented Apr 29, 2012

Hi - sorry for the massive delay on this one. I missed it coming in originally and haven't been keeping quite on top of my Github account as I should!

Without this patch, fnAdjustColumnSizing would call the fnCalculateColumnWidth function (if bAutoWidth is true) thereby modifying the values the user gave

The reason I've done it that way is that, in theory at least, if the user has specified the "correct" column widths (i.e. they can be applied without modification) then they should be used unmodified (the auto width calculation does take the dev given changes into account). However, if they don't give the correct size, then it will be adjusted accordingly.

I can certainly see that finer control of column widths would be very welcome, and this is very much something that needs to be looked at in future, so I'm certainly open to this idea. If you could perhaps show a case where the current two options aren't sufficient, that would be really helpful!

Contributor

thegrandpoobah commented Apr 30, 2012

I'll try to put up an example somewhere, but basically it boils down to the idea that there are situations where neither of datatables.net's built in column sizing algorithms are sufficient. Again, there are two built in:

  1. Calculate based on the maximum content width of the columns
  2. User specifies and that width is locked in forever and ever

In our situation we wanted a third way where the width of columns was dependent on the width of the parent container and the amount of space was distributed to columns based on the idea of priority. A somewhat complicated and domain specific algorithm that arguably has no place in the DataTables.net code base. Hence why it would be nice if manual resizing was integrated in.

As a further argument for my cause, the change is small and AFAIK, does not affect speed, size or the other two sizing algorithms adversely, so why not :)

Again, I will try to put up an example of our use case online somewhere when I get the chance (hopefully tonight).

Owner

DataTables commented May 1, 2012

An example would be fantastic! Thanks.

One comment:

In our situation we wanted a third way where the width of columns was dependent on the width of the parent container and the amount of space was distributed to columns based on the idea of priority.

Why not just specify sWidth or the width attribute on the TH elements in the header as percentage values? DataTables would apply those values and then calculate the pixel equivalent.

Contributor

thegrandpoobah commented May 5, 2012

Check out an example of the semi-complicated logic here: http://www.saliences.com/dt_example/index.html

The example uses DataTables.net 1.8.2, but the same applies to 1.9.x (I only have an upgraded DataTables.net at work).

What is important to note about the example is that the columns each have the following properties:

  • minimum width
  • maximum width
  • distribution priority
  • visibility threshold (if visibilitythreshold > minwidth && col.width < visibilitythreshold => column is hidden)

the following four properties are mixed together to dynamically compute the dimensions of each column in a way that CSS or DataTables.net's built in sizing algorithms could not. We use this sizing algorithm at work for literally all of our tabular presentations.

Hopefully this illustrates the need for manual sizing and answers you question about why we can't use the built in DataTables.net stuff. Let me know if you need any more information.

Owner

DataTables commented May 5, 2012

Hi - thanks for the link, although I might be doing something a bit stupid? There is a link which says "Download source bundle here" to source.zip, but if I click on that, I get what appears to be a 404 error.

Contributor

thegrandpoobah commented May 5, 2012

sigh. its not you. When I moved it to the server I forgot to update the url to the source. Should be good now.

Contributor

thegrandpoobah commented May 21, 2016

This is horribly out of date at this point. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment