Plans for DataTables v1.7 and beyond
Plans for DataTables v1.7 and beyond
allan
Posts: 63,678Questions: 1Answers: 10,498 Site admin
Hello all,
While bug fix version are good (v1.6.2), and you want to be using stable software (who doesn't!) it is at the same time a little boring ;-). So I'd like to talk a little bit about my thoughts for v1.7 and get feedback from all of you who are using DataTables. v.1.6 hasn't been out for long - but it's quite stable now and I'm happy with the optimisations that have been made, particularly in 1.6.1.
So v1.7:
1. Reuse of the selector - at the moment you need to keep a copy of the DataTables object created by the initialisation (I tend to use 'var oTable') to make use of API function. I'd like to introduce a method by which you could do something like this:
[code]
$('#example').dataTable( { ... } );
$('#example').dataTable().fnAddData( ... );
[/code]
This would same messing around with global variables etc. One thing to note is that it will not be possible to reconfigure a table by passing in different options the second time the initialisation is called! As such, you will need to either pass nothing, or an object with a flag set to indicate that you know this will happen. Otherwise a warning will pop up like it does in 1.6.
2. aoColumns change - one real pain at the moment in DataTables is it's need for aoColumns to exactly match the number of columns in the table - giving 'null' when you don't want any special settings. I'm not 100% sure how I'm going to specify this yet, so that will be presented in future.
3. Destructor API function - fairly simple. Call this and it will return the page to how it was before you initialised DataTables.
A couple of other nice things. :-)
Beyond DataTables 1.7 there is still a wealth of opportunity for where it can progress. A much stronger plug-in structure would be the main point for progressing to v2 while keeping the main feature set more or less the same (don't want the core library to become to large - it's about right where it is). At the same time there are a load of plug-ins and developer tools (like KeyTable, TableTools and FixedHeader which we already have) that could be developed for DataTables.
Obviously the key ingredient here is time, v1.7 won't happen over night, and anything beyond that is a case of wait and see. Also the support balance needs to be addressed, as noted in the "Support levels" thread. Obviously if you want to sponsor any specific feature - work want someone working on DataTables and it's plug-ins full time ( ;-) ) ping me!
Here is to the journey!
Regards,
Allan
While bug fix version are good (v1.6.2), and you want to be using stable software (who doesn't!) it is at the same time a little boring ;-). So I'd like to talk a little bit about my thoughts for v1.7 and get feedback from all of you who are using DataTables. v.1.6 hasn't been out for long - but it's quite stable now and I'm happy with the optimisations that have been made, particularly in 1.6.1.
So v1.7:
1. Reuse of the selector - at the moment you need to keep a copy of the DataTables object created by the initialisation (I tend to use 'var oTable') to make use of API function. I'd like to introduce a method by which you could do something like this:
[code]
$('#example').dataTable( { ... } );
$('#example').dataTable().fnAddData( ... );
[/code]
This would same messing around with global variables etc. One thing to note is that it will not be possible to reconfigure a table by passing in different options the second time the initialisation is called! As such, you will need to either pass nothing, or an object with a flag set to indicate that you know this will happen. Otherwise a warning will pop up like it does in 1.6.
2. aoColumns change - one real pain at the moment in DataTables is it's need for aoColumns to exactly match the number of columns in the table - giving 'null' when you don't want any special settings. I'm not 100% sure how I'm going to specify this yet, so that will be presented in future.
3. Destructor API function - fairly simple. Call this and it will return the page to how it was before you initialised DataTables.
A couple of other nice things. :-)
Beyond DataTables 1.7 there is still a wealth of opportunity for where it can progress. A much stronger plug-in structure would be the main point for progressing to v2 while keeping the main feature set more or less the same (don't want the core library to become to large - it's about right where it is). At the same time there are a load of plug-ins and developer tools (like KeyTable, TableTools and FixedHeader which we already have) that could be developed for DataTables.
Obviously the key ingredient here is time, v1.7 won't happen over night, and anything beyond that is a case of wait and see. Also the support balance needs to be addressed, as noted in the "Support levels" thread. Obviously if you want to sponsor any specific feature - work want someone working on DataTables and it's plug-ins full time ( ;-) ) ping me!
Here is to the journey!
Regards,
Allan
This discussion has been closed.
Replies
Allan
I'd like to get some feedback on what I am thinking for the aoColumns change for DataTables 1.7 (point 2 in my original post). My current line of thought is to introduce a new variable called aoColumnDefs (or something like that) which would provide exactly the same options as aoColumns, but not be bound to any specific length. Instead, to bind a definition in the aoColumnDefs array to one or more columns you would use a parameter call 'aTargets'. This array would take:
- strings: class name of the TH element for the column (or multiple columns)
- a non-negative integer (0+): the column number to target
- a negative integer: the column number to target counting from the right (so -1 would be the right most column)
This example:
[code]
$(document).ready(function() {
$('#example').dataTable( {
"aoColumns": [
null,
{ "sType": "html" }
]
} );
} );
[/code]
could then be rewritten as:
[code]
$(document).ready(function() {
$('#example').dataTable( {
"aoColumnDefs": [
{
"sType": "html",
"aTargets": [ -1 ] // or 1
}
]
} );
} );
[/code]
The aoColumns initialisation option would remain, and would still have the same constraints that it currently does (i.e. must match the number of columns exactly), but you have the option to use aoColumnDefs now.
The two could be used together, and / or you could target multiple definitions to a single column (it might get confusing though if you are doing something really complex!). I haven't decided if the first or last definition applied should take priority (probably the first, but it might be more complex to write that way...) - for example if two definitions applied to a column both specify an sType, which is where some potential confusion might lie - but equally a powerful option for those who are interested in using it.
All thoughts are welcome!
Regards,
Allan
I think I am understanding correctly that you are suggesting the ability to have one column definition apply to multiple columns, and also the ability to not specify a column at all, yet have it appear with default settings (not having to enter "null"). You probably know better than me (us) what kind of problems people are trying to solve, but one solution which might be less flexible but possibly easier to use would be: 1) the ability to leave out a column definition as you suggest, and it will get default settings 2) the ability to define a "custom" default setting for all columns that would override the built-in default, and 3) the ability to define the rest of the columns, the ones that would differ from the default, by name instead of by index.
So in this case you would specify the name of the column inside of the definition along with your desired parameters. The script would match the given name to the sql column name apply the definition to the correct field. Any column not named would be assumed to have default settings, either the built-in or the custom definition if supplied (possibly named "_default_" or some such thing). Visibility and all the other parameters would stay the same. I tend to find naming easier to debug than counting indexes, but maybe that's just me.
Cheers, Doug
I was reading over the JqueryUI planning wiki: http://jqueryui.pbworks.com/GridTable
And I saw a mention about retrofitting existing jquery widgets to have them included in the JqueryUI base. Is this something that you would consider for 2.0 Allan? Or Perhaps branching Datatables into a new project? I'm not sure you'd have the time, I imagine you don't since the following would be a mammoth undertaking!
------------------------------->8--------------------------------
Richard D. Worth said
at 2:00 pm on May 7, 2010
Some have been modified to use the jQuery UI CSS Framework (yeah), making them ThemeRoller-ready
As far as I know, none have taken (started?) the much larger step of being built on top of the jQuery UI Widget factory. This is what drives our design and API, that all widgets have
- a create: .pluginname() or .pluginname(options)
- an init: .pluginname() or .pluginname(options) called again after already created
- optional options that can be set on init: .pluginname() or .pluginname([options])
- the same options can be get and set after init, with appropriate side-effects: .pluginname("option", "key") or .pluginname("option", "key", value)
- state (see above): .data("pluginname").options
- a destroy that returns the element to its pre-init state: .pluginname("destroy")
- events that can be handled by passing a function as an option to the eventname option or by .bind()-ing to the event type: .pluginname({ eventname: fn }) or .bind("pluginnameeventname", fn)
- event callbacks are passed two arguments: event, ui: .pluginname({ eventname: function(event, ui) })
- chainable methods: .pluginname("method1").pluginname("method2", "option1", "option2")
- a11y considerations: WAI-ARIA
- testing in all supported browsers: FF2+, IE6+, Safari 3.1+, Opera 9.6+, Chrome
------------------------------->8--------------------------------
- Not target a column at all (i.e. no target using aoColumnDefs or aoColumns) in which case it will simply get the default settings
- Target all columns by using "_all" as the target in aoColumnDefs[].aTargets[] (aTargets will always be an array, to allow more than one target to be specified - although it's kind of pointless in this case, it maintains consistency)
- Target one or more columns using aoColumnDefs with >=0 numbers (counting from the left), <0 numbers (counting from the right) or classes applied to the column's TH
- Target each individual column with aoColumns, just as it currently is
The problem with giving each column a name (which is actually possible using sName at the moment) is that you need to give a name to each and every column, and thus you end up with the situation we have now where you must know the number of columns for aoColumns. So this part certainly can be done now, and will continue to be available in future versions, but aoColumnDefs is about providing flexibility that you don't need to know that exact number of columns.
@gavin - Heh - yes - not something for 1.x :-). I would love to work with the jQuery UI team on developing DataTables for inclusion with jQuery UI in future - there is an obvious concern that as soon as jQuery UI release a table component, none of the already established plug-ins will get a look in any more, and of course I want DataTables to continue and not just die when this happens. At lot of their requirements sound very sensible and were along the lines I was thinking of anyway for the API in 2.x, but I do have some concerns about tying DataTables to closely to a single framework (for example it should be possible to port it to any other library with a few hours work at the moment, and I have done that for Glow already).
In short I don't know what will happen there - it would be superb to get a chance to work on DataTables properly for a while as part of a "day job", when this kind of close integration and feasibility might become possible.
Regards,
Allan
Heh - yup - save to PDF would be a great addition to TableTools. TableTools actually has the potential to become quite a complex project in and of itself :-)
Allan
----------
hello allan I managed to export the table (table in text only) in PDF by dompdf and call ajax with jquery, if you agree I can send you the code to insert it in the next version of tabletools
sorry for my english.
Allan
First let me echo dugb's comments, that this is a powerful tool and you are doing a great job.
My idea is an advanced filtering section, maybe another row under 'show entries' and 'search' row:
More of a styling thing really, so at the moment, you have to create extra filtering inputs outside datatables itself.
Another thought, an easy way to create Select/pull down boxes that apply exact match filter to certain columns, the select boxes could be populated automatically by finding unique entries within given column - for large data sources this might be an issue though.
Finally... I'm having a nightmare with range filter.. anyway to make that easier would be great! :)
Cheers ,
Emeka.
Thanks for the kind words :-)
1. Advanced filtering: I agree that it would be great to have a pre-built module which will do this, but I am reluctant to include it into DataTables core, as I don't believe the benefit of adding it in would out weight the extra code that it would involve. Allowing developers such as your self to put search boxes wherever you want keeps it general and flexible. But it is definitely a perfect example of what could be done with a plug-in!
2. There is an example showing how filtering can be done with select menus: http://datatables.net/examples/api/multi_filter_select.html
Range filtering... I'll take a look at your other thread :-)
Regards,
Allan
mcpalls: Ooo - yes please! I'd be most interested in seeing what you have got for that. You can get in touch with me directly at http://datatables.net/contact if you prefer to post code there (it might not fit into the forum...).
Allan
----------
have you received and read my code? What do you think?
Regards,
Allan
unfortunately it is almost impossible to create a pdf from html using javascript
with collinsPdf.js you can write plain text and it's free
collinsHtml.js it's not free.
But you could use dompdf (server client) with datatables? much easier...
however, your philosophy no question sorry, but it would give a touch of class to this fantastic project. :)
I really like the ability that you've added to TableTools here! While I am working on TableTools 2 I will make certain that it provides options for plug-ins, which could provide something like this, and can then be customised by each developer to match their own needs. TableTools really could become a very complex project when considering both client-side and server-side together!
Allan