*Feature Request* - Events for API method calls or/and Functionality to proxy/rename API methods
*Feature Request* - Events for API method calls or/and Functionality to proxy/rename API methods
jLinux
Posts: 981Questions: 73Answers: 75
Lately I've been into learning about the DT API and Plugin system, as well as creating some of my own Plugins.
I had an idea for a plugin that that would provide some functionality that I've seen a few members here request, including myself. Its basically just eye candy, just a way to fade in newly added rows (row.add() & rows.add()), and fade out deleted rows (row.remove() & rows.remove()), as well as do some kinda fade or something for updated rows (row.data()), and in addition to the fading, maybe do some color fading (Deleted rows get set to red before fading out, added rows show up as green then fade to normal color, etc).
The other plugin I'm working on right now would be DataTable HotKeys, which what it basically does is keep a list of events that have happened (Currently planning for: column-visibility, column-reorder, row-reorder), as well as the data for each, then when whatever hotkey is pressed (Eg: Ctrl+Z), it will revert the changes of the latest event.
The Problem for both, is that they require some kind of interaction with the API methods, and I can't find a way to accomplish them with the current DataTables functionality.
For the first one (Eye Candy), the easiest way I could think to accomplish it, is basically rename the API methods that I listed, then create my own ones to replace them, which would basically apply the eye candy effects, then execute the original API methods that I renamed. The only way I can think to accomplish this right now, is copy the code for those API methods from the DT JS files, then override the API methods with custom ones, and execute the code taken from the original API methods, which is basically just proxying the API calls. The problem with this is I just don't think it would play well with any possible updates in the future. If any of the API methods I listed get changed, then I would have to add some functionality to check the DT version and execute different code, etc. If I can accomplish the former rename/execute method, then all I need to do is execute my code, then execute the original API calls and hand the exact and unmodified parameters, which would make it more compatible with updates.
The only action I can currently tap into (Out of create/remove/update), would be create. I could just use the createdRow callback, and if there was a callback for updating and deleting, and preferably something that would execute prior to the action (for deleting mainly, to change color and fade out), that would be the best.
For the second one (Hotkeys), as long as users don't use any of row.add(), rows.add()), row.remove(), rows.remove()) or (row.data()), then the plugin would work fine, but thats a hell of a big restriction... lol. Since the plugin basically keeps a list of changes that have occurred via the DT events, if row #3 is moved to #4, then gets deleted, if the hotkey is pressed, the incorrect row would get moved. The insanely terrible "fix" for this one is basically the same as the Eye Candy one, just copy the original API code from the DT JS, then override the function and execute the code manually, which has the same caveats... What could make this possible, is if there were events that fired for the API methods, maybe a row-add.dt for example... That would come in handy for a few things, IMO.
I know that both of these can be accomplished by creating my own API methods that just execute whatever I need, then execute the original API methods, and require users to use those API methods, but that obviously would be a terrible way of doing it. Since any other plugins, as well as the DT code itself uses the original API methods, so not everything would be caught correctly.
If anyone knows of some way to accomplish anything I've said above in a more efficient way than I already stated, then let me know! Thank you.
Ok @allan, ill need this by next week!
(Totally kidding).
Let me know if you think this is a good idea, and if it would be possible! Thank you.
-J
Replies
Hi,
Thanks for posting this. I'm not convinced that putting the ability to rename methods in is a good idea though I'm afraid. As a developer if I am working with a library on one site using a particular API and then work on a different site with the same library, same version and same API method, and it behaved differently the air would turn blue :-).
I would suggest simply giving your plug-in methods unique named - for example could you just use
row.addWithEffect()or similar?Regarding a row add event - yes, that will be added in the next major version of DataTables. It isn't present at the moment because DataTables uses jQuery events, which are an extension of DOM events and that is horribly slow for lots of triggers (for example adding 10'000 rows).
Allan
Well I got this idea from a CodeIgniter project I was working on (Code here), all I needed to do was basically hook some functionality into some methods, I needed them to happen either before, or right after, so I would just overwrite the methods, then execute my code, and execute the version of that method in the parent when I was done, or before I started.. Thats exactly what I need to do here.
If there was just a way to execute something right before or right after... that would be perfect. I mean it doesn't have to be overwriting the methods, (though that would be my preferred method), I guess just pre/post events would do... but thats a lot more work I would think than the latter.
I know its easy to overwrite the API methods when creating new ones, and I keep thinking theres gotta be a way to just rename it.. lol
Thats what i was thinking, but the problem is that means this wouldnt work with ANY other plugins... and thats a huge limitation...
I see what you mean. However I wasnt talking about an event every time a row was added, I mean an event whenever
rows.add()gets called, so maybe just one event, that hands down all the row data, that would suffice.I think if you were to do the first one (renaming/overwriting), you wouldn't have to do the second, as anyone could add events when overwriting it and renaming... ;-)
Question.. how often do the code for these methods change?
I know you're saying you dont want to make it so developers can just overwrite the functions and rename them (like in my CI example), but the thing is... if they're motivated enough, then they just need to copy the code (with a few mods) from the pastebin link I just sent you, and add them to the new versions... so maybe not adding a feature like this is a bad idea? It just makes it harder for developers to write code that will support compatibility going forward, and backwards (past any changes to those methods).. (Hope im explaining that correctly)
If this was just for my application and my app only, I wouldnt hesitate to just overwrite them and add your code into my new methods, but since this is a plugin, and I want others to be able to download it, I need to think twice before doing something like that
As in the internal code? Whenever I need to fix a bug in them or when I need to refactor for whatever reason.
Regarding the events, better event handling is something I've long planned - this will be going in for added rows, removed rows, updated rows etc, in the next major version.
I see your point about replacing the default methods so plug-ins can use them, but what about the case where you add an extra parameter to the input options for that function type to support the extra features of the plug-in, then I add another parameter in the core - future and backwards incompatible.
I currently feel that this is not something I'm likely to endorse in DataTables to be honest (reserving the right to change my mind in future - I'm not a politician!).
Allan
That would be something the developers would need to work with, dont try to take on their responsibility.... lol. And I would simply just hand down the parameters as they are, exactly, to the original method, Im sure theres a way to do that, think of something like func_get_args() in PHP, then passing those to the method, it would grab everything. So if something gets changed, and a parameter gets added or deleted, I wouldnt need to change anything, it would work just fine.
Would there also be pre/post events for each? :-D Because that would be AWESOME! That would mean that developers can execute code on deleted rows just before they get deleted, which would basically remedy the need for for the rename/overwriting of methods (... this time, im sure it could still be very useful for other purposes)
Im just tellin ya what would be useful from a users standpoint :P I could have created two awesome plugins that would use this already, im sure other people could have as well.
Pre / post events: I hope so yes. As long as I can make it efficient enough!
Allan
Awesome! You're da man.
I wont bug you and ask if its done or how long every week, im just curious, when do you aim on the next major release to be released? jw
I really like my idea for the hotkeys, and it would need to be able to keep track of adds/deletes/updates, as well as the data for each.
I'm not actually sure. I would like it to be Q1 2016, but it depends on a number of other factors. I'm hoping to firm up some plans soon and will post about it in the blog when I've done so to lay the groundwork.
Allan