views:

52

answers:

2

I am creating a site that utilizes the jQuery UI tabs. Whenever the user flips between the tabs, the tab they just left is posted back to the server in order to save the state.

One of the tabs in particular is a bit complicated in that, if I select a particular data option, other options need to be disabled. However, because of the POST, those options reenable themselves in the view when I go back to the tab. The current solution I have found to fix this problem is to check to see if the specific option was selected and to disable the other options appropriately (which happens as the user flips back to the tab). However, this seems like too much work. I am wondering if there is any way for the disabled attribute to remain on the various options even through the POST. (If the answer is "No," I'll accept that, but I wanted to see if there was another alternative to ensuring the view is correct for the user.)

Edit: I wanted to add some code demonstrating the post that I am doing when the user switches tabs. (Particularly based on the responses.)

$.post($(form).attr("action"), $(form).serialize(), function (data, success) {
    if (success) {
        // Inject the resulting form back into the parent of the page.
        var parent = $(form).parent();
        parent.removeData($(form));
        parent.html(data);

        processTabAfterLoad(tab_index);
    }
});

The processTabAfterLoad function does all of the selections and setting the state of the tab back to what it previously was.

A: 

Tabs are usually navigation techniques. Imho, its a bad practice to postback and redirect when a GET (i.e. an ordinary link) would do. A GET resets viewstate back to a known point, is a small payload, doesn't require a page life cycle that gets discarded anyhow before the redirect, etc.

I could also be completely wrong here-- I'm making some guesses since I can't see any code.

MatthewMartin
+1  A: 

If I were you, I'd take a different approach. It seems like your goal in posting back to the server when navigating is to preserve a user's location in an application so when they return, you can restore this state. Rather than reloading the whole page through a POST, what you could do instead is do an "AJAX" post to tell the server to store the user's UI location but do all of your UI enabling logic client-side. That way, not only will UI transitions look smoother, but you'll reduce server load and make the application more responsive.

It'd only be when the user does the initial GET of the page that you'd need to look up the last-known UI location. If there's something stored for that user, you would add logic to set the UI's initial state when the page loads.

Update:

Indeed you are doing an AJAX post, but you're also apparently inserting the HTML response from that post into your UI. That is a somewhat unusual pattern (excepting ASP.NET update panels). Typically, you'd either POST the data and expect no content in the response or you'd receive data back from the post which you'd apply to the UI rather than receiving a fragment of the UI.

If you're committed to the way you're currently handling form submittal, you could look into the jQuery live function which can apply changes to elements as well as newly-inserted elements that match the criteria.

Jacob
@Jacob - I thought I was already doing an AJAX-style post. I updated my question with the code that does the POST when a user switches out of a tab. Maybe this will help clarify things. Thanks.
JasCav
@Jacob - The reason I included the HTML response is because we have server-side validation rules that need to be placed back in the form so the user can see them (via Data Annotations). I'm not sure how else that would happen if I didn't do that when I post the individual tabs.
JasCav
Using `.live(...)` should work for your purposes, then.
Jacob
@Jacob - I'm feeling kind of stupid...not really seeing how live() is going to help me. I have used it before for other purposes (for example, here, due to the fact that the tabs load asynchronously), but I'm not seeing how it would solve my problem of maintaining the correct state within the view (or not losing it in the first place when I switch tabs). Sorry for the question...but I'm a bit lost.
JasCav
I'm not sure how you're currently doing the UI disabling logic, but if the new HTML has the same IDs/CSS classes as the HTML that's getting replaced, then if you had done the disabling logic with `live`, the incoming elements should have the same modifications applied.
Jacob
@Jacob - Thanks. That is the case. I think what I am confused about is that there doesn't appear to be an event with 'live' that would handle setting the state on the load of an element (at least nothing that I have seen) which would allow me to apply the modifications. Did I miss something with respect to the various events? (Part of me is starting to think I should have done all this work server-side, but I'm not sure that would actually fix the problem...)
JasCav
I was thinking the `load` event would work, but I haven't tested that specifically.
Jacob
If `load` doesn't work, maybe `ready` would.
Jacob