Is there any setting to store the current presenting page number like as persistentLayout:true?
I created Back Button with history.back(); that always back to first page of table.
There is no built in way of doing this, but you could use the pageLoaded callback to store the current memory in local storage:
var table = new Tabulator("#example-table", {
pageLoaded:function(pageno){
//pageno - the number of the loaded page
localStorage.setItem('currentPage', pageno);
},
});
And then on page load set the page of the table after you have instantiated it with the setPage function
table.setPage(localStorage.getItem('currentPage') || 1)
Related
Using the HTML5 window.history API, I can control the navigation pretty well on my web app.
The app currently has two states: selectDate (1) and enterDetails (2).
When the app loads, I replaceState and set a popState listener:
history.replaceState({stage:"selectDate",...},...);
window.onpopstate = function(event) {
that.toStage(event.state.stage);
};
When a date is selected and the app moves to stage 2 I push state 2 onto the stack:
history.pushState({stage:"enterDetails",...},...);
This state is replaced anytime details change so they are saved in the history.
There are three ways to leave stage 2:
save (AJAX submit)
cancel
back button
The back button is handled by the popstate listener. The cancel button pushes stage 1 so that the user can go back to the details they were entering the back button. These both work well.
The save button should revert back to stage 1 and not allow the user to navigate back to the details page (since they already submitted). Basical, y it should make the history stack be length = 1.
But there doesn't seem to be a history.delete(), or history.merge(). The best I can do is a history.replaceState(stage1) which leaves the history stack as: ["selectDate","selectDate"].
How do I get rid of one layer?
Edit:
Thought of something else, but it doesn't work either.
history.back(); //moves history to the correct position
location.href = "#foo"; // successfully removes ability to go 'forward',
// but also adds another layer to the history stack
This leaves the history stack as ["selectDate","selectDate#foo"].
So, as an alternative, is there a way to remove the 'forward' history without pushing a new state?
You may have moved on by now, but... as far as I know there's no way to delete a history entry (or state).
One option I've been looking into is to handle the history yourself in JavaScript and use the window.history object as a carrier of sorts.
Basically, when the page first loads you create your custom history object (we'll go with an array here, but use whatever makes sense for your situation), then do your initial pushState. I would pass your custom history object as the state object, as it may come in handy if you also need to handle users navigating away from your app and coming back later.
var myHistory = [];
function pageLoad() {
window.history.pushState(myHistory, "<name>", "<url>");
//Load page data.
}
Now when you navigate, you add to your own history object (or don't - the history is now in your hands!) and use replaceState to keep the browser out of the loop.
function nav_to_details() {
myHistory.push("page_im_on_now");
window.history.replaceState(myHistory, "<name>", "<url>");
//Load page data.
}
When the user navigates backwards, they'll be hitting your "base" state (your state object will be null) and you can handle the navigation according to your custom history object. Afterward, you do another pushState.
function on_popState() {
// Note that some browsers fire popState on initial load,
// so you should check your state object and handle things accordingly.
// (I did not do that in these examples!)
if (myHistory.length > 0) {
var pg = myHistory.pop();
window.history.pushState(myHistory, "<name>", "<url>");
//Load page data for "pg".
} else {
//No "history" - let them exit or keep them in the app.
}
}
The user will never be able to navigate forward using their browser buttons because they are always on the newest page.
From the browser's perspective, every time they go "back", they've immediately pushed forward again.
From the user's perspective, they're able to navigate backwards through the pages but not forward (basically simulating the smartphone "page stack" model).
From the developer's perspective, you now have a high level of control over how the user navigates through your application, while still allowing them to use the familiar navigation buttons on their browser. You can add/remove items from anywhere in the history chain as you please. If you use objects in your history array, you can track extra information about the pages as well (like field contents and whatnot).
If you need to handle user-initiated navigation (like the user changing the URL in a hash-based navigation scheme), then you might use a slightly different approach like...
var myHistory = [];
function pageLoad() {
// When the user first hits your page...
// Check the state to see what's going on.
if (window.history.state === null) {
// If the state is null, this is a NEW navigation,
// the user has navigated to your page directly (not using back/forward).
// First we establish a "back" page to catch backward navigation.
window.history.replaceState(
{ isBackPage: true },
"<back>",
"<back>"
);
// Then push an "app" page on top of that - this is where the user will sit.
// (As browsers vary, it might be safer to put this in a short setTimeout).
window.history.pushState(
{ isBackPage: false },
"<name>",
"<url>"
);
// We also need to start our history tracking.
myHistory.push("<whatever>");
return;
}
// If the state is NOT null, then the user is returning to our app via history navigation.
// (Load up the page based on the last entry of myHistory here)
if (window.history.state.isBackPage) {
// If the user came into our app via the back page,
// you can either push them forward one more step or just use pushState as above.
window.history.go(1);
// or window.history.pushState({ isBackPage: false }, "<name>", "<url>");
}
setTimeout(function() {
// Add our popstate event listener - doing it here should remove
// the issue of dealing with the browser firing it on initial page load.
window.addEventListener("popstate", on_popstate);
}, 100);
}
function on_popstate(e) {
if (e.state === null) {
// If there's no state at all, then the user must have navigated to a new hash.
// <Look at what they've done, maybe by reading the hash from the URL>
// <Change/load the new page and push it onto the myHistory stack>
// <Alternatively, ignore their navigation attempt by NOT loading anything new or adding to myHistory>
// Undo what they've done (as far as navigation) by kicking them backwards to the "app" page
window.history.go(-1);
// Optionally, you can throw another replaceState in here, e.g. if you want to change the visible URL.
// This would also prevent them from using the "forward" button to return to the new hash.
window.history.replaceState(
{ isBackPage: false },
"<new name>",
"<new url>"
);
} else {
if (e.state.isBackPage) {
// If there is state and it's the 'back' page...
if (myHistory.length > 0) {
// Pull/load the page from our custom history...
var pg = myHistory.pop();
// <load/render/whatever>
// And push them to our "app" page again
window.history.pushState(
{ isBackPage: false },
"<name>",
"<url>"
);
} else {
// No more history - let them exit or keep them in the app.
}
}
// Implied 'else' here - if there is state and it's NOT the 'back' page
// then we can ignore it since we're already on the page we want.
// (This is the case when we push the user back with window.history.go(-1) above)
}
}
There is no way to delete or read the past history.
You could try going around it by emulating history in your own memory and calling history.pushState everytime window popstate event is emitted (which is proposed by the currently accepted Mike's answer), but it has a lot of disadvantages that will result in even worse UX than not supporting the browser history at all in your dynamic web app, because:
popstate event can happen when user goes back ~2-3 states to the past
popstate event can happen when user goes forward
So even if you try going around it by building virtual history, it's very likely that it can also lead into a situation where you have blank history states (to which going back/forward does nothing), or where that going back/forward skips some of your history states totally.
A simple solution:
var ismobilescreen = $(window).width() < 480;
var backhistory_pushed = false;
$('.editbtn').click( function()
{
// push to browser history, so back button will close the editor
// and not navigate away from site
if (ismobilescreen && !backhistory_pushed)
{
window.history.pushState('forward', null, window.location);
backhistory_pushed = true;
}
}
Then:
if (window.history && window.history.pushState)
{
$(window).on('popstate', function()
{
if (ismobilescreen && backhistory_pushed && $('.editor').is(':visible'))
{
// hide editor window (we initiate a click on the cancel button)
$('.editor:visible .cancelbtn').click();
backhistory_pushed = false;
}
});
}
Results in:
User opens editor DIV, the history state is saved.
User hits back button, history state is taken into account.
Users stays on page!
Instead of navigating back, the editor DIV is closed.
One issue: If you use a "Cancel" button on your DIV and this hides the editor, then the user has to click the mobile's back button two times to go back to the previous URL.
To solve this problem you can call window.history.back(); to remove the history entry by yourself which actually deletes the state as requested.
For example:
$('.btn-cancel').click( function()
{
if (ismobilescreen && backhistory_pushed)
{
window.history.back();
}
}
Alternatively you could push a URL into the history that holds an anchor, e.g. #editor and then push to history or not if the anchor exists in the recent URL or not.
I searched the whole web and I couldn't found any good topic which expose the proper way to do it.
I have a very simple web which I developed using Kentico 9 CMS. This web only contains two subpages and a header to navigate between those.
The "Home" subpage contains a custom form which remains connected to a SQL table which is populated every time you press submit with certain data.
On the other hand, the other page, shows the stored data by using a custom web part which connects to the DB by using BizFormItemProvider and this object is used as a layer to binding the data in a control.
Now is my point. If you see, there is a button to "Edit" a certain row and my intention is to Redirect to "Home" (which contains the form) and sending via QueryString the ID of the row attempted to edit.
I was unable to understand how can you re-fill the form with its data using an ID.
Maybe because I never worked with a CMS before, I'm looking the development such as pure ASP.NET and it could not be the correct one.
Custom
Given that your solution uses a custom form for entering the data, as well as a custom web part for listing the stored data, you will need to use a custom solution to handle the editing of data, as well.
In the custom webpart on the Home page, in a load event, you can retrieve the form data and set the values on the form controls.
protected void Page_Load(object sender, EventArgs e)
{
// Ensure that the form is not being posted back,
// to prevent entered data from being overwritten
if(!IsPostBack)
{
// Get the form item ID from the query string
var personId = QueryHelper.GetInteger("personId", 0);
if(personId > 0)
{
// Get the biz form item, and set form control values
var bizFormItem = BizFormItemProvider.GetItem(personId, "customFormClassName");
txtFirstName.Text = bizFormItem.GetStringValue("FirstName", string.Empty);
}
}
}
Similarly, when Submit is clicked, you can update the existing form item with the new data
protected void btnSubmit_OnClick(object sender, EventArgs e)
{
// Get the form item ID from the query string
var personId = QueryHelper.GetInteger("personId", 0);
if(personId > 0)
{
// Retrieve the existing biz form item,
// and update it from the form control values
var bizFormItem = BizFormItemProvider.GetItem(personId, "customFormClassName");
bizFormItem.SetValue("FirstName", txtFirstName.Text);
bizFormItem.Update();
}
else
{
// Your code for inserting a new form item...
}
}
The Kentico way
You should really consider using the Kentico form engine for accomplishing this task. Instead of using a custom form for entering the data, use the built-in On-line form webpart.
The benefits are numerous, such as:
Ability to set the form layout through the CMS, and use alternative layouts
Automatic confirmation email to the submitter of the form, as well as notification emails to the administrators
To accomplish your task, you can customise the On-line form webpart to support loading of existing data.
In the bizform.ascx.cs file, add code to the SetupControl method:
protected void SetupControl()
{
if (StopProcessing)
{
// Existing code...
}
else
{
// Existing code...
// Get the form item ID from the query string
var personId = QueryHelper.GetInteger("personId", 0);
if(personId > 0)
{
// Get the biz form item, and set form control values
var bizFormItem = BizFormItemProvider.GetItem(personId, "customFormClassName");
if(bizFormItem != null)
{
// Set the item ID
viewBiz.ItemID = bizFormItem.ItemID;
}
}
}
}
This will automagically switch the form to Edit mode, instead of Insert mode, as soon as you set the ItemID property. Clicking the Submit button will save changes on the existing form item.
You will not need to worry about validation in your code, and inserting data will still work.
Is this a contact form that you are using Kenticos built in form application for, or is it a custom form? If it is a custom form you can create a transformation with a link that will contain the ID. If it is a biz form, you can still create a transformation in Page Types (create a new page type and select "The page type is only a container without custom fields"), then write a custom query to get the biz form data, and use a repeater to display the data with that transformation.
How do I set "onDemand" as default when the form is loaded?
(Background: There is a hidden text box which should only be visible when "Predefine" is checked. Unfortunately, it is visible when the form gets loaded first. At this point I thought about making the onDemand checked by default to keep the textbox invisbile at first page load)
{"key":"discountType","type":"radioType", "templateOptions":{"options": [{"name":"OnDemand","value":"OnDemand"},{"name":"Predefined","value":"Predefine"}]}},
{"key":"discValue","type":"input","templateOptions": {"type":"input"}, hideExpression: "model.discountType=='OnDemand'"}
]
}
Did some trial and error after sleeping over it and I got it.
discount.discountInfo.discType="OnDemand"; resolved it.
var discount = this;
discount.title = title;
discount.discountInfo = {};
discount.fields=[{"key":"discountType","type":"radioType", "templateOptions":{"options": [{"name":"OnDemand","value":"OnDemand"},{"name":"Predefined","value":"Predefine"}]}},
{"key":"discValue","type":"input","templateOptions": {"type":"input"}, hideExpression: "model.discountType=='OnDemand'"}
]
discount.discountInfo.discType="OnDemand";
I want to display multiple datasources in a cesiumjs viewer but need to allow the user to select which ones they want to see at any given time. For example, if I load a kml and a czml file, how do I hide one and show the other? I can't find the cesiumjs way to do this with its API.
Update Feb 2016: A show flag has been proposed and may be added to a future version of Cesium.
Original answer:
Currently there is no show flag on the dataSource, however it is easy to add and remove the dataSource from the list of available dataSources, and this is used to get the show/hide functionality.
Here's a working demo: Load the Cesium Sandcastle Hello World example, and paste the following code into the left side, then hit Run (F8). It should display a checkbox in the upper-left with show/hide functionality.
var viewer = new Cesium.Viewer('cesiumContainer');
// Create a typical CzmlDataSource.
var dataSource1 = new Cesium.CzmlDataSource();
dataSource1.load('../../SampleData/simple.czml');
// Add a checkbox at the top.
document.getElementById('toolbar').innerHTML =
'<label><input type="checkbox" id="showCheckbox" /> Show CZML</label>';
var checkbox = document.getElementById('showCheckbox');
checkbox.addEventListener('change', function() {
// Checkbox state changed.
if (checkbox.checked) {
// Show if not shown.
if (!viewer.dataSources.contains(dataSource1)) {
viewer.dataSources.add(dataSource1);
}
} else {
// Hide if currently shown.
if (viewer.dataSources.contains(dataSource1)) {
viewer.dataSources.remove(dataSource1);
}
}
}, false);
This code could be improved, for example it could be a "lazy load" where the dataSource.load does not get called until the first time it's shown. Also if a dataSource has been hidden a while, you have to consider at what point should you be saving memory by destroying the dataSource rather than continuing to hold onto it (triggering a new lazy load if it is later shown again).
as of now, show is a property of the data source, you can control it by accessing the property in dot or bracket notation:
https://cesiumjs.org/Cesium/Build/Documentation/CzmlDataSource.html#show
const src = new Cesium.CzmlDataSource();
src.show = false;
My code looks like below. I am feching the json records from the server side using structs action. it is returning the records fine and i could able to see the table with data. pagination links created fine. when i click next and datasource is called on each click of any link on the pagination. if i click on colum header also, the datasource is being called.
my questions are:
1)When datasource is being called. because i am seeing sometime called and some times not. like when i got from 1page to 2page, datasource is called fine. when i go back to previous pages by clicking 'prev' link, datasource is being called. but after that if i click again on next to go to 2nd page, datasource is not being called. when exactly datasource is called and how many times it will called. is it for every link in the pagination calls datasource?
2)If my datasource returns 100 recods of data and my records per page is set to 25, then do i see the 4 pages. I am confused here with server side pagination and datasource calls.
datasource is not called for each page link and next or prev link clicks? if not, when datasource is called? please explain me. I know how many total records are there in the begining and my requirement is showing 25 records per page when ever user clicks on page number or next or prev links. i have the capability to bring corresponding 25 records based on the page number from server side.
3)how to capture the 'next' and 'prev' clicks on the pagination.
my requirement is to dynamically fetch the json data using datasource from the server whenever user click on page number links or next or prev.
Please help me out with this. I am new to YUI. I have to User YUI 2 only since we are already using it.
<div id="dynamicdata"></div>
<script type="text/javascript">
YAHOO.example.DynamicData = function() {
var myColumnDefs = [ // sortable:true enables sorting
{key:"PIN", label:"PIN", sortable:true},
{key:"CODE", label:"CODE", sortable:true}
];
// Customize request sent to server to be able to set total # of records
var generateRequest = function(oState, oSelf) {
// Get states or use defaults
oState = oState || { pagination: null, sortedBy: null };
var sort = (oState.sortedBy) ? oState.sortedBy.key : "PIN";
var dir = (oState.sortedBy && oState.sortedBy.dir === YAHOO.widget.DataTable.CLASS_DESC) ? "desc" : "asc";
var startIndex = (oState.pagination) ? oState.pagination.recordOffset : 0;
var results = (oState.pagination) ? oState.pagination.rowsPerPage : 25;
var total = YAHOO.util.Dom.get("total").value *1;
// Validate input
if(!YAHOO.lang.isNumber(total) || total < 0 || total > 200) {
YAHOO.util.Dom.get("total").value = 0;
total = 0;
alert("Total must be between 0 and 200.");
}
// Build custom request
return "sort=" + sort +
"&dir=" + dir +
"&startIndex=" + startIndex +
"&results=" + (startIndex + results) +
"&total=" + total;
};
// DataTable configuration
var myConfigs = {
generateRequest: generateRequest,
initialRequest: generateRequest(), // Initial request for first page of data
dynamicData: true, // Enables dynamic server-driven data
sortedBy : {key:"PIN", dir:YAHOO.widget.DataTable.CLASS_ASC}, // Sets UI initial sort arrow
paginator: new YAHOO.widget.Paginator({ rowsPerPage:10 }) // Enables pagination
};
var myDataSource = new YAHOO.util.DataSource("<%=request.getContextPath()%>/results.do?startIndex="+localStartIndex+"&rowsPerPage="+rowsPerPage);
myDataSource.responseType = YAHOO.util.DataSource.TYPE_JSON;
myDataSource.responseSchema = {
resultsList: "data",
fields: [
{key:"SSN"},
{key:"PIN"}
]
}
var myDataTable = new YAHOO.widget.DataTable("dynamicdata", myColumnDefs, myDataSource, myConfigs);
// DataTable instance
var myDataTable = new YAHOO.widget.DataTable("dynamicdata", myColumnDefs, myDataSource, myConfigs);
// Update totalRecords on the fly with values from server
myDataTable.doBeforeLoadData = function(oRequest, oResponse, oPayload) {
oPayload.totalRecords = 200;
return oPayload;
};
return {
ds: myDataSource,
dt: myDataTable
};
}();
As far as I remember, the DataTable will always ask for fresh data whenever it changes pages or sorts by a different column. It doesn't cache previous requests nor does it keep track what it has asked. If you don't see requests arriving on the server side it might be because of caching, but not in DataTable or DataSource but by the browser itself, which is a matter of issuing the proper headers on the server to tell the browser not to cache.
If I am not mistaken, that this is supported by the behavior you describe. The first page is requested twice, once when you first draw the table, once again when you return from page 2. All other pages are never requested twice. Why? Because the first time around the URL formed is slighty different from the URL when you return to it. The browser cache only knows about URLs.