How to force a refresh of Ajax data - tablesorter

I'm using the Ajax pager and I have some code that adds a record to my database. What I want to do is force the records to be refreshed. I'm trying to use $("builders_table").trigger("update"), but that doesn't work. If I change pages or filter the records, then the updated records are returned, but I would like to force a refresh as soon as the database is changed.
Thanks
$('#builders_table')
.tablesorter({
theme: 'blue',
widthFixed: true,
cancelSelection: false,
sortLocaleCompare: true, // needed for accented characters in the data
sortList: [ [1,1] ],
widgets: ['zebra', 'filter']
})
.tablesorterPager({
container: $('.pager'),
ajaxUrl : '/builder_data.php?page={page}&size={size}&{filterList:filter}&{sortList:column}',
// use this option to manipulate and/or add additional parameters to the ajax url
customAjaxUrl: function(table, url) {
// manipulate the url string as you desire
//url += url_extras;
// trigger a custom event; if you want
$(table).trigger('changingUrl', url);
// send the server the current page
return url;
},
ajaxError: null,
ajaxObject: {
dataType: 'json'
},
ajaxProcessing: function(data){
if (data && data.hasOwnProperty('rows')) {
return [ data.total_rows, $(data.rows) ];
}
},
// Set this option to false if your table data is preloaded into the table, but you are still using ajax
processAjaxOnInit: true,
initialRows: {
// these are both set to 100 in the ajaxProcessing
// the these settings only show up initially
total: 50,
filtered: 50
},
output: '{startRow} to {endRow} ({totalRows})',
updateArrows: true,
page: 0,
size: 50,
savePages: false,
storageKey: 'tablesorter-pager',
pageReset: 0,
fixedHeight: false,
removeRows: false,
countChildRows: false,
// css class names of pager arrows
cssNext : '.next', // next page arrow
cssPrev : '.prev', // previous page arrow
cssFirst : '.first', // go to first page arrow
cssLast : '.last', // go to last page arrow
cssGoto : '.gotoPage', // page select dropdown - select dropdown that set the "page" option
cssPageDisplay : '.pagedisplay', // location of where the "output" is displayed
cssPageSize : '.pagesize', // page size selector - select dropdown that sets the "size" option
// class added to arrows when at the extremes; see the "updateArrows" option
// (i.e. prev/first arrows are "disabled" when on the first page)
cssDisabled : 'disabled', // Note there is no period "." in front of this class name
cssErrorRow : 'tablesorter-errorRow' // error information row
});

The pager has a built-in method to force an update named "pagerUpdate":
You can force an update as follows:
$('table').trigger('pagerUpdate');
or, if you want to force an update and change the page
$('table').trigger('pagerUpdate', 3); // update and set to page 3

Related

Recommended workflow for tablesorter serverSideSorting?

Question for Mottie's tablesorter version 2.30.5.
What is the recommended workflow for serverSideSorting? More specifically, when / how do I apply / insert / update the table data coming back from the server such that I don't wipe out information like last.sortList?
I'm following Mottie's answer here as close as I can but I am unable to sort on multiple columns, because when I reinitialize tablesorter, it clears last.sortList.
jQuery("#search_results_table")
.on("sortEnd", function(e, table) {
jQuery('#search_sort').val(JSON.stringify(table.config.sortList));
// yuck
if (gTableSorterReady) {
// call server here, which calls this code on completion
}
})
.on("tablesorter-ready", function(e) {
// yuck
gTableSorterReady = true;
})
.tablesorter({
theme : 'search-theme',
widgets : [ 'zebra', 'stickyHeaders' ],
widthFixed : false,
widgetOptions : {
stickyHeaders_attachTo: '#search_results_container',
},
cssAsc : "headerSortUp",
cssDesc : "headerSortDown",
cssHeader : "header",
sortList : inSortList,
serverSideSorting: true
});

search functionality using relay

How to implement a search functionality with relay?
So, the workflow is
user navigate to search form.
there should not be any query (as in relay container) when initializing the view.
user fills the field values, and press the action/search button.
a relay query is sent to the server
results are received from the server.
page displays it and relay reconciles the filtered results with local cache.
I have not seen an example of ad hoc query but only part of a relay container (which it resolves before component initialization). So, how to model it. should it be like a mutation?
If I understand correctly you'd like to not send any query at all for the component until the user enters some search text, at which point the query should sent. This can be accomplished with the example posted by #Xuorig, with one addition: use GraphQL's #include directive to skip the fragment until a variable is set. Here's the extended example:
export default Relay.createContainer(Search, {
initialVariables: {
count: 3,
query: null,
hasQuery: false, // `#include(if: ...)` takes a boolean
},
fragments: {
viewer: () => Relay.QL`
fragment on Viewer {
# add `#include` to skip the fragment unless $query/$hasQuery are set
items(first: $count, query: $query) #include(if: $hasQuery) {
edges {
node {
...
}
}
}
}
`,
},
});
This query will be skipped initially since the include condition is falsy. Then, the component can call setVariables({query: someQueryText, hasQuery: true}) when text input is changed, at which point the #include condition will become true and the query will be sent to the server.
This is the way I've implemented simple search in my project:
export default Relay.createContainer(Search, {
initialVariables: {
count: 3,
title: null,
category: null,
},
fragments: {
viewer: () => Relay.QL`
fragment on Viewer {
items(first: $count, title: $title, category: $category) {
edges {
node {
...
}
}
}
}
`,
},
});
Your search form simply has to update the initialVariables using this.props.relay.setVariables and relay will query the new data.

Loading pages of ajax select2 data in the background

I have a AJAX select2 drop-down menu set up to do infinite paging. What'd I'd like to do is go ahead and load the first page of results in the background so that as soon as the user clicks the drop-down, they have a set of options immediately, instead of waiting on the initial AJAX call.
When I search Google for how to do this, I only see results about trying to set an initial selection, which isn't what I want to do. I just want to pre-load the first page of results from my endpoint so the user sees data immediately instead on waiting for the AJAX call to return. Is this even possible?
My select2 setup code is below:
$(".my-class-identifier").select2({
ajax: {
cache: true,
dataType: "json",
delay: 500,
data: function(params, page) {
return {
name: params,
otherParams: $(this).data("other-params")
page: page
};
},
results: function(data, page) {
return {
/* The server returns no data after all the pages have been returned. */
more: data && data.length > 0,
results: data
};
},
type: "GET",
url: function() {
if ($(this).data("url")) {
return $(this).data("url");
} else {
return DEFAULT_ENDPOINT;
}
}
},
allowClear: true,
minimumInputLength: 0,
placeholder: "Search for some data..."
});
So what you are looking for is to initialize your select2. Select2 has an initialize option to load your values, it would look something like this:
initSelection: function(element, callback){
callback([
{id:1,text:'one'},
{id:2,text:'two'},
]);
}
Be sure to add this outside your ajax call, but inside your select2.
An example here in JSFiddle
How about in your backend, you check your search string. If the size is zero or the search string is empty, then send back your first-page result. Otherwise, do the search and return the result.

Pass data to a html page opened in jQuery UI dialog

I have succeeded in opening a html page in a jQuery dialogbox. I have also passed a data called 'vendorid' to it, but do not know how to retrieve it in the html page that opens.
$('#btnShowSupplierStats').click(function () {
showUrlInDialog('../supplierstats.htm?vendorId=' + $(this).attr('vendorId')); return false;
//showUrlInDialog('../Default2.aspx'); return false;
});
function showUrlInDialog(url) {
var vid = $(this).attr('vendorId')
var tag = $("<div id='statsDiv' vid ='"+ vid +"'></div>");
$.ajax({
url: url,
success: function (data) {
tag.html(data).dialog({ show: "fadein", hide: "fadeout",
modal: true, minHeight: 550, minWidth: 800, autoOpen: false,
close: function (event, ui) { $(this).remove(); }, buttons: [{
text: "Close", click: function () { $(this).dialog('close');
return false; } }] }).data("vendorid", vid).dialog('open');
return false;
}
});
}
UPDATE: The answer from Farrukh would do this job ( i.e. second option he mentioned, since I am using a 100% client-side approach). But I did not store the data to be passed in a hiddent field. Instead I used the following approach which also works always:
When you are about to open the dialog through jQuery, just before this, set the attribute for the button which is the opener of dialog. In my case, I set an attribute called 'vendorid' on this button. Let's say the id of the opener button is 'btnOpenVendorDialog'. So need to use the following code.
$('#btnOpenVendorDialog').attr('vendorid', 'Vendor1234');
//open your dialog here ....
2.Then, in the html page that opens in dialog window, I can easily retrieve this attribute without any problems.
var vid = $('#btnOpenVendorDialog').attr('vendorid');
THAT's IT. YOU ARE ALL READY TO do whatever you want with this passed data.
There are two ways to do this:
Use server side and get the passed data in post or get(in your case vendor ID is get) and use it to populate a hidden element or data-vendorID attribute of any available element.
If you are using javascript then data vendorID that you have passed as vid is available after success function so place it in as a hidden input field or place it as a data-vendor-id on one of the other DOM elements and access it from there.

Persisting jqGrid column preferences

I've got a few jqGrids on my ASP.NET MVC 3 application that have a number of columns. I added the following to the column definitions to default some columns to be hidden:
colModel: [
{ name: 'IceCreamID', hidden: true},
{ name: 'RecipeID', hidden: true }
and this works nicely. Those columns aren't visible on my grid.
Then I added this to implement the column chooser:
var grid = $('#icecreamGrid');
grid.jqGrid('navButtonAdd', '#icecreamPager',
{ caption: "Columns", buttonicon: "ui-icon-calculator",
title: "Choose Columns",
onClickButton: function() {
grid.jqGrid('columnChooser');
}
});
Great, brings up the column chooser now. I then added the following to columns I never wanted to show up in the column chooser:
colModel: [
{ name: 'IceCreamID', hidden: true, hidedlg: true},
So I can now hide/show columns just fine. Now, how would you persist this information? DB? As a cookie? Other way? Is there a preferred way to store this sort of information that is really a user preference rather than something related to the data itself?
More Info
Based on Oleg's comment below, I want to provide a little more information.
The point here is that I've got grids with 10-15 columns which could be display based on the user's preference. For a simple example, one of my grid's has the following 9 columns:
IceCream|ShortName|HasNuts|SugarAdded|LimitedRun|PromoItem|Facility|FirstRun|LastRun
Users can hide/show any of these 9 columns based on their personal preferences.
What I want to do is provide a way to persist which columns a particular user wants to see so that s/he doesn't have to re-choose those columns to view each time the page with that grid is shown.
I found you question very interesting. The question about saving the user state of grid are interesting in many cases. There are some interesting answers on such problems which uses cookie (see here for example).
In my opinion saving of the grid state in database on the server or in the localStorage is better way as the usage of cookie. The best way depends on the project's requirements in which you use it. For example the usage of the database storage on the server allows you to implement roaming state of the grid. If you use the localStorage instead of cookies the user preferences will be lost if the user goes to another computer or just if the user will use another web browser on the same computer.
Another problem with the grid state is the maintenance. The information about the columns of the grid you hold typically in the JavaScript or HTML files and not in the database. In the case the both sources can be not synchronous on the changes in the grid. Different scenarios of the update problem could you easy imagine. Nevertheless the advantages of user's preferences so large in some scenarios that the problems with small disadvantages are not so important and can be solved relatively easy.
So I'll spend some time to implement two demos which shows how it can be implemented. I used localStorage in my demos because of many reasons. I mention only two from there:
Cookies is the way which send permanently different information to or from the server which is not really requited. It increases the size of HTTP header and decreases the performance of the web site (see here for example).
Cookies have very hard restrictions. Corresponds to the section 6.3 of rfc2109 or 6.1 of rfc6265: At least 4096 bytes per cookie, at least 50 cookies per domain (20 in rfc2109), at least 3000 cookies total (300 in rfc2109). So the cookies one can't use to save too many information. For example if you would save state of every grid of every your web page you can quickly achieve the limits.
On the other side localStorage are supported by all modern browsers and will be supported in Internet Explorer starting with IE8 (see here). The localStorage will be automatically saved per origins (like a1.example.com, a2.example.com, a3.example.com, etc) and has arbitrary limit of 5 MB per origin (see here). So if you use the space carefully you will far from the any limits.
So I used in my demos the localStorage. I should additionally mention that there are some plugins like jStorage which use localStorage if it's supported by the browser and use another storage, but the same interface for you in case of old browsers like IE6/IE7. In the case you has only less size of storage: 128 kB instead of 5 MB, but it's better as 4K which one has for cookies (see here).
Now about the implementation. I creates two demos: this and it's extended version: this.
In the first demo the following states of grid will be saved and automatically restored on the page reload (F5 in the most web browsers):
which column are hidden
the order of columns
the width of every column
the name of the column by which the grid will be sorted and the sort direction
the current page number
the current filter of the grid and the flag whether the filter are applied. I used multipleSearch: true setting in the grid.
In the same way one can extend (or reduce) the list of options which are the part of the saved grid state.
The most important parts of the code from the demo you will find below:
var $grid = $("#list"),
saveObjectInLocalStorage = function (storageItemName, object) {
if (typeof window.localStorage !== 'undefined') {
window.localStorage.setItem(storageItemName, JSON.stringify(object));
}
},
removeObjectFromLocalStorage = function (storageItemName) {
if (typeof window.localStorage !== 'undefined') {
window.localStorage.removeItem(storageItemName);
}
},
getObjectFromLocalStorage = function (storageItemName) {
if (typeof window.localStorage !== 'undefined') {
return $.parseJSON(window.localStorage.getItem(storageItemName));
}
},
myColumnStateName = 'ColumnChooserAndLocalStorage.colState',
saveColumnState = function (perm) {
var colModel = this.jqGrid('getGridParam', 'colModel'), i, l = colModel.length, colItem, cmName,
postData = this.jqGrid('getGridParam', 'postData'),
columnsState = {
search: this.jqGrid('getGridParam', 'search'),
page: this.jqGrid('getGridParam', 'page'),
sortname: this.jqGrid('getGridParam', 'sortname'),
sortorder: this.jqGrid('getGridParam', 'sortorder'),
permutation: perm,
colStates: {}
},
colStates = columnsState.colStates;
if (typeof (postData.filters) !== 'undefined') {
columnsState.filters = postData.filters;
}
for (i = 0; i < l; i++) {
colItem = colModel[i];
cmName = colItem.name;
if (cmName !== 'rn' && cmName !== 'cb' && cmName !== 'subgrid') {
colStates[cmName] = {
width: colItem.width,
hidden: colItem.hidden
};
}
}
saveObjectInLocalStorage(myColumnStateName, columnsState);
},
myColumnsState,
isColState,
restoreColumnState = function (colModel) {
var colItem, i, l = colModel.length, colStates, cmName,
columnsState = getObjectFromLocalStorage(myColumnStateName);
if (columnsState) {
colStates = columnsState.colStates;
for (i = 0; i < l; i++) {
colItem = colModel[i];
cmName = colItem.name;
if (cmName !== 'rn' && cmName !== 'cb' && cmName !== 'subgrid') {
colModel[i] = $.extend(true, {}, colModel[i], colStates[cmName]);
}
}
}
return columnsState;
},
firstLoad = true;
myColumnsState = restoreColumnState(cm);
isColState = typeof (myColumnsState) !== 'undefined' && myColumnsState !== null;
$grid.jqGrid({
// ... other options
page: isColState ? myColumnsState.page : 1,
search: isColState ? myColumnsState.search : false,
postData: isColState ? { filters: myColumnsState.filters } : {},
sortname: isColState ? myColumnsState.sortname : 'invdate',
sortorder: isColState ? myColumnsState.sortorder : 'desc',
loadComplete: function () {
if (firstLoad) {
firstLoad = false;
if (isColState) {
$(this).jqGrid("remapColumns", myColumnsState.permutation, true);
}
}
saveColumnState.call($(this), this.p.remapColumns);
}
});
$grid.jqGrid('navButtonAdd', '#pager', {
caption: "",
buttonicon: "ui-icon-calculator",
title: "choose columns",
onClickButton: function () {
$(this).jqGrid('columnChooser', {
done: function (perm) {
if (perm) {
this.jqGrid("remapColumns", perm, true);
saveColumnState.call(this, perm);
}
}
});
}
});
$grid.jqGrid('navButtonAdd', '#pager', {
caption: "",
buttonicon: "ui-icon-closethick",
title: "clear saved grid's settings",
onClickButton: function () {
removeObjectFromLocalStorage(myColumnStateName);
}
});
Be carefully to define myColumnStateName (the value `'ColumnChooserAndLocalStorage.colState'``) in the demo) to different values on the different pages.
The second demo is the extension of the first one using the technique from my old answer to your another question. The demo use the searching toolbar and synchronize additionally information between the advanced searching form and the searching toolbar.
UPDATED: The next answer contains extended version of the code included above. It shows how to persist the selected rows (or row) additionally. Another answer shows how to persist the list of expanded nodes of the tree grid and expand the nodes on the relaoding of the page.

Resources