Answers

• btree Posts: 99Questions: 14Answers: 11

  November 2015

  Hi,

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

  Cheers
  Hannes
• jLinux Posts: 981Questions: 73Answers: 75

  November 2015 edited November 2015

  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 Posts: 99Questions: 14Answers: 11

  November 2015

  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 Posts: 65,256Questions: 1Answers: 10,817 Site admin

  November 2015 Answer ✓

  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 Posts: 981Questions: 73Answers: 75

  November 2015 edited November 2015

  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 Posts: 65,256Questions: 1Answers: 10,817 Site admin

  November 2015 Answer ✓

  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 Posts: 981Questions: 73Answers: 75

  November 2015

  OK, got it. Thanks!