Replies

• debianlinux Posts: 5Questions: 0Answers: 0

  August 2013

  Here's a hackish solution leaning on TableTools to get the information out of the row:
  
  [code]
  }).makeEditable( {
  sUpdateURL: "./DTemployeetitlesactions.php?action=update",
  sAddURL: "./DTmanagingofficesactions.php?action=create",
  sDeleteURL: "./DTmanagingofficesactions.php?action=delete",
  aoColumns: [{}, {}],
  fnOnEditing: function(input) {
  var oTT = TableTools.fnGetInstance('EmployeeTitles');
  var aData = oTT.fnGetSelectedData();
  currentKey = aData[0].employeetitleid;
  return true;
  },
  
  oUpdateParameters: {
  id: function() {
  return currentKey;
  }
  }
  [/code]
  
  Still looking for that nice, clean, hidden method that looks something like this:
  [code]
  "aoColumns": [ { "mData": "employeetitleid", "bSearchable": false, "bVisible": false, "id": true },
  [/code]
• debianlinux Posts: 5Questions: 0Answers: 0

  August 2013

  This remains an issue with deleting records because the id of the row is not passed to the sDeleteURL. fnOnDeleting is not capable of altering sDeleteURL, apparently the scripting has already loaded sDeleteURL into queue prior to evaluating fnOnDeleting.
  
  For example, the following will not work despite making good logical sense:
  [code]
  
  var deleteid;
  ...
  ...
  ...
  sDeleteURL: "./DTemployeetitlesactions.php?action=create&id=" + deleteid,
  ...
  fnOnDeleting: function () {
  var oTT = TableTools.fnGetInstance('EmployeeTitles');
  var aData = oTT.fnGetSelectedData();
  deleteid = parseInt(aData[0].employeetitleid, 10);
  return true; },
  [/code]
  
  Additionally, if I write out the necessary ajax request in fnOnDeleting I am still required to provide a sDeleteURL which then makes an entirely unneeded server request.
  e.g.
  [code]
  ...
  ...
  ...
  sDeleteURL: "./DTemployeetitlesactions.php",
  ...
  fnOnDeleting: function () {
  var oTT = TableTools.fnGetInstance('EmployeeTitles');
  var aData = oTT.fnGetSelectedData();
  xmlhttp = new XMLHttpRequest();
  xmlhttp.open("POST","./DTemployeetitlesactions.php?action=delete",true);
  xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded");
  xmlhttp.send("employeetitleid=" + parseInt(aData[0].employeetitleid, 10));
  return true; },
  [/code]
  
  Commenting out sDeleteURL forces the script to use the default DeleteData.php URL which is A) non-existant and therefore produces an ugly error message and B) is STILL a redundant server call.
  
  Does anyone know how to specify which column is the ID column so that the program behaves without a bunch of hand holding and redundant server requests? It seems such a simple concept.
  
  A workaround that I find entirely unacceptable is to revert to aliasing each SQL column to a numeric column heading and discarding the use of mData entirely at which point the scripts find and use column [0] as the ID without any fuss. This feels like taking 3 steps backward and I may as well download and use Stables version 1.4 or something.
• debianlinux Posts: 5Questions: 0Answers: 0

  August 2013 edited August 2013

  Okay, using the same hackabout method I discovered the oDeleteParamters inside the dataTables.Editable file:
  
  [code]
  fnOnDeleting: function(input) {
  var oTT = TableTools.fnGetInstance('EmployeeTitles');
  var aData = oTT.fnGetSelectedData();
  currentKey = aData[0].employeetitleid;
  return true;
  },
  ...
  oDeleteParameters: {
  id: function() {
  return currentKey;
  }
  },
  [/code]
  
  Surely there is a more elegant method than this?