API Methods wont register on AJAX Sourced table

jLinux

Im running into the weirdest issue.. Im trying to register some API Calls inside the init within the plugin JS code. The code works perfectly fine, unless I specify an ajax source, then the exact same code wont register the API methods..

If you go to this JSBin Example with NO ajax sourced data, and Run with JS, open your browser JS Console, then click the Click Button in the upper left, you'll see it worked fine, you should just see ABORTING in the console.

Now if you go to this JSBin Example, which has the exact same code, with the exception of the tbody being removed from the HTML, and the ajax source being specified, and run the exact same steps, you'll see that you get an error in the JS Console when you click the Click button:

Uncaught TypeError: Cannot read property 'abort' of undefined

Thus, the myPlugin.abort() API Method hasn't been registered...

It took me a while to narrow this down to the ajax being the issue, but I can't see what else it could be.. I mean thats the only thing thats changed...

Has anyone ran into this?

btree

Hi,

it looks like a Problem with "myPlugin" chaining. When you register "abort()" without chaining it works like table.data().abort().

Cheers
Hannes

jLinux

But calling table.data().abort() wouldn't be the same as calling table.myPlugin.abort()...

If it works, you should see this in the browser js console (not the JSBin console thing):

myPlugin.abort()

ABORTING

Which would be the same console output as in this JSBin example

btree

Hi,

ahh ok seems odd. So with ajax source it's not registered as top level api and only works with chaining when you use another api, eg: table.data().myPlugin.abort()

Cheers
Hannes

allan

So the issue here is the async behaviour of the ajax option. What is happening in the no ajax case is:

1. Start the table initialisation
2. init is triggered during that initialisation (i.e. before table has been assigned).
3. Your plug-in is added
4. The API instance is created
5. table is an API instance that has been extended by your plug-in.

In the with ajax case this is what happens:

1. Start the table initialisation
2. Ajax data request is made
3. The API instance is created (note that the plug_in has not been added.
4. table is an API instance that has not been extended by your plug-in.
5. init is triggered once the Ajax data has been loaded
6. Your plug-in is added

So basically the issue is that the plug-in isn't being added before the instance. If the plug-in were to modify the object's prototype this wouldn't be an issue - but it doesn't. It will extend the instances on an ad-hoc basis.

So not a bug as such, more an implementation "quirk" perhaps. Either way, I would always recommend simply adding API methods up front.

They can't be added on a per table basis, so there isn't really any benefit in only adding it in a function such as init. Indeed, that might end up with it being added multiple times unless you add additionally logic (although that wouldn't cause anything to happen, the later would overwrite the new).

Allan

jLinux

I would always recommend simply adding API methods up front.

As in something like this? Thats how I have it now. I was just trying to get it so they would only register if the plugin was initiated.. Meaning:

var _options = oSettings.oInit.myPlugin;

if (_options === true || $.isPlainObject( _options ) ) {
    // HERE..
}

But I guess thats not possible?

I just dont want people to be able to call the plugin, when they dont even have a table using the plugin...

allan

Yes - like that.

I don't really see any benefit in having it added only if the plug-in is initialised to be honest. You'd still need to take account of the situation whereby it isn't used on the table (for example consider a page with two tables, one which uses this option and one which doesn't).

The API structure is common to all tables, so it can't exist only for certain tables. You could throw an error is someone calls it on a table that doesn't use the plugin (they've got it coming to them ;-) ).

It is possible to do it that way, but as I say, they'd need to create a new API instance after the plug-in has been registered.

Allan

jLinux

OK, got it. Thanks!