Forwarding to component owner for consideration.

Hi Satyam,

i reviewed this request with Jenny. Her thought ar that this is simply a wrapper around a send request which should be implemented by the developer and that this in not generic enough to add to the library. Thoughts?

- george

Indeed, it is just a wrapper, but being the documentation (not the API) for the DataSource almost non-existent, and that assuming the developer looks at the API for the DataSource, since he/she probably would read that of the DataTable, it cheaply produces an entry into the DataTable API right where people would look for it: refreshVew, requery, they both fit together.

Also notice that most parts of the function are hard to find and put together. It was just in this release that all the config parameters became documented for all the components and even then, did you notice the get() and set() methods are not listed? (I just noticed that, it is a bug to file, you want me to do it?) Then, as I said, DataSource is poorly documented and though onDataReturnInitializeTable is well documented in the API, you would have to know what to look for in the first place.

The only place where all these are put together, more or less, is the server-side pagination and/or sorting example, which might not be the obvious place to look for if you want, for example, to refresh the table periodically, a question that came up several times in the mailing list.

So, I guess it is cheaper to add this few lines to the code than answering the same question over and over again for lack of better documentation. People will look for this functionality under the DataTable, few would go to the DataSource and within the DataTable API docs, as close to 're...' whatever, the best, that's where people will expect to find a clue.

Either that or add a paragraph to the documentation at: http://developer.yahoo.com/yui/datatable/#using

added to tinernal db for tracking #1549319

In the new long example under the heading "Server-side Sorting and Pagination" almost to the end of the DataTable there are two identical calls to sendRequest with the same setup for the callback object, all of which is quite unnecessary had there been a requery method as suggested. The code for that method now has to be modified according to the new way of passing the callback arguments which has become so long that now the method is no longer the simple one-liner above and makes even more sense that there should be a method provided for that.

This ticket was imported from Source Forge.

Orginially submitted by: devasatyam

Comment by Jenny Han Donnelly 2008-06-25 16:35:29

Fleshing out the DS documentation will help. Also need to address generateRequest, SS data, and polling for DT.

Comment by Jenny Han Donnelly at 2008-08-19 13:36:57

Copying over Luke's description from the duplicate bug:

In response to Satyam's popular requery method, perhaps it would be a good idea to encapsulate common DS->DT communication into a DT method. Suggestion:

/* In initAttributes */
setAttrConfig('loadMethod',{
value : DT.proto.onDataReturnSetRows
});
setAttrConfig('lastRequest',{
value : null
});

/* in the proto definition */
DT.proto.load = function (req,payload,methodOverride) {
req = req || this.get('lastRequest') || this.get('initialRequest');

var method = methodOverride || this.get('loadMethod');

this.getDataSource().sendRequest(
this.get('generateRequest')(req),
{
success : method,
failure : method,
scope : this
argument : payload || {}
});
};

then either add a custom event that is fired from within DS.issueCallback and subscribe to it, or subscribe to the DT's dataReturnEvent to set('lastRequest',oRequest);

Comment by Lucas Smith at 2008-09-10 23:26:31

In dialog with Satyam, he suggested:
a) also have methods for append, insert, and possibly initialize that wrapped a call to load, passing the appropriate onDataReturn method as the last param
b) for local data (at least?), providing a data object/collection as the first parameter would either update the DataSource's liveData or something similar, affecting this sort of transaction:

var myDataTable = new DataTable(tbl,cols,dataSource,config);
myDataTable.load([{foo:1,bar:1},{foo:2,bar:2},...]);

This would be, imo, a very intuitive interface, but this poses questions regarding data source abstraction and consistent handling of data between local and remote data sources.

I wonder if you'd considered this type of API/interaction model:
function DataTable(el,config) {...}
DataTable.prototype.load = function (data, config, methodOverride) {...}

var dt = new DataTable('tbl',{ cols : [ {key:'foo'},{key:'bar'} ], paginator: ... });
// dt.render() at this point would draw table chrome w/ no data rows

// load would render the data rows only if the DT were already rendered
dt.load(my_uri,{ responseType: JSON, responseSchema: { ... }, payload : {...} });
dt.render()

where load's config would take the key parts of the DS config and cache them, so future calls to load (or sibling methods append etc) would need only specify payload info if any were needed.

Ticket #2528710 was marked as a duplicate of this ticket.

created 4849629: "[fixes #1804089] Added load() as a convenience method to DS.sendRequest()."

[fixes #1804089] Added load() as a convenience method to DS.sendRequest().
View Commit:

[fixes #1804089] this.initialRequest -> this.get('initialRequest')
View Commit: