Question

I am working on an event management system for my work, the basic function of it is to allow people in my office to upload new events to the system, track them and edit them.

It is for the most part complete and now I am at the point of cleaning up the system and making it more user friendly. One of the biggest issues I am having is with maintaining view state. I am currently using one search page to filter all of my event results, the user can search by date, date range, client etc and as long as the user stays on the page the system works as intended and all of the search function setting stay as they were.

There are some functions such as the edit link that open a new page (same window) where the event is edited and saved. This also works as intended, I pass a queryString to the page to tell the system which one to edit. The problem is the back button. If I use a link that just links to the search page, I loose all my settings, which is kind of annoying if you want to see the changes you just made to the event, I tried a JavaScript back which maintains your viewstate but the page does not refresh so any edits don’t show until the user refreshes.

There are 3 times I use an outside link on this page, and although it isn’t a deal breaker and is just mildly annoying I would like to figure it out as it has been bothering me for sometime. I also tried making the edits in the page but could not figure that out easier and I figured this would be easier to fix.

Thank you for reading and hopefully someone can at point me in the right direction with this, I am pretty new to ASP.net and any information I am sure is helpful!

Answer 1

Viewstate only exists within the context of the current form (It is contained within a hidden input field). Which means that Viewstate alone will not help (any time you get the page – not post – it will have a new Viewstate). There are a few options though. The easiest of which is using Session to store the context of the search queries (date, date range, client, etc.). This exists on the server side and can be used when loading the page. Another way of maintaining your search queries is to utilize how browsers maintain history. You can add hash (#) codes to the end of your url that can then be read by javascript. The Backbone.js routing and history functionality work this way. However, this is a very complex solution as it is typically meant for asynchronous requests. Both of these possible options have some caveats (Session lives for the life of the session cookie) but if you remove Viewstate (Page.EnableViewState = false) you will have a much smaller request/response network footprint.

Here’s some Backbone routing code:

$(document).ready(function() {
    Backbone.history.start();
});

// create some routes
var DynamicWorkspace = Backbone.Router.extend({
        routes: {
            "search/:date": "search",
            "search/:date/:range": "search",
            "search/:date/:range/:client": "search"
        },

        search: function(date, range, client) {
            // make a request to your server with the queries
        }
    });

var dynamicRouter = new DynamicWorkspace;

var currentDate = '';
var currentRange = '';
var currentClient = '';

// call this via javascript from a page element
function setDate(value) {
    currentDate = value;
    return updateNavigation();
}

// call this via javascript from a page element
function setDateRange(value) {
    currentRange = value;
    return updateNavigation();
}

// call this via javascript from a page element
function setClient(value) {
    currentClient = value;
    return updateNavigation();
}

function updateNavigation() {
    // change the browser url to our known route
    dynamicRouter.navigate('search/' + currentDate + '/' + currentRange + '/' + currentClient, true);
    return false;
}