Using history.js with Knockout and ajax - javascript

I have some filters on the left hand side of my page which use knockout and updates the results displayed using ajax when they are clicked. I would like to use history.js to maintain state such that if the user clicks back it will load the relevant content. This seems to work fine but knockout still has the filter checkboxes I selected ticked as I am using ko.observableArray() which gets added each time a filter is selected. How do I go about ensuring that the filter is unticked without a lot of code. I know it can be done by checking the url params and then comparing them to what is already in the array.

Related

Reload partial and retain form values

When purchasing a course, the user can enter 1 or more students to register for the course. By default there is only one entry but the user can use a dropdown to select more and then the form will update to show more.
I am accomplishing this by triggering an event when the user changes the dropdown value that uses ajax to call an action which returns a partial with the appropriate number of entries and then I just replace the existing div with the new one.
My question is whether there is a way to implement this so that it's kind of like "refreshing" the page where the form remembers and automatically refills in he values the user already entered just like if you were to refresh the entire webpage. Is there a way to do this, or will I need to pass in the existing values into the action in my ajax call and have the partial set them?
A secondary question I just thought of (and perhaps this should be in another post but I will go ahead and put it here for now) is whether I should be concerned about any weird behavior with validation when doing it this way? (I'm using stock, built in validation with annotations).

Dynamically show/hide subset of records?

I am writing a web app using PHP, MySQL, jQuery, and some miscellaneous add-ons like jEditable and DataTables. On most pages, the user will submit a form which will query the DB and bring back records matching my query rules. This works for 95% of my users 95% of the time. It's the other 5%/%% I am trying to help.
I am excluding records that are no longer being processed (completed/cancelled/accepted/rejected/etc.), leaving only "live" records. However, sometimes the leadership team needs to see the records I exclude. I could write a whole other page or report for each case, but that seems a huge waste of time.
Is there a way to add a "show all records" checkbox or button to my page? When clicked, the button would get and display the rest of the data, so users don't have to refresh/go to another page/etc.
you should add a toggle switch - it could be just a check box, or you could use something fancy like this: http://simontabor.com/labs/toggles/
Bind an event to it that preforms a table.ajax.reload() in datatables to pull in the new records. Also, for the datatables ajax request, provide a callback that returns the toggled state of the toggle control as a post variable, then handle the filtering in your sql on the back end.
Note, this solution means you will have to configure datatables to source data via ajax, which, from what you described sounds like you should be doing anyway.

Strange Update Panel Issue with Devexpress Controls

I have some strange issue with Update Panel.
I am using Devexpress Controls, JQUERY AJAX in one of my applications. I have used Server side coding + Client side coding aproach i.e. using Jquery, JS and AJAX + Update Panel on some pages where aspxgridview is there.
I am creating a scenario via example situation according to the problem I have faced:
1) There are some ASPxcomboBoxes for e.g.County, State and City.
2) On client Selected index change of Country, I have fetched the data via AJAX and bind the states in State ASPxComboBox using JSON and same for the city combo on client index change of State.
3) On the city combo's index change, I have bound a ASPxGridView with some related data and ASPxGridView and City combo is wrapped in Update Panel as we cannot bind the ASPxGridView via AJAX so to avoid postbacks I have used update panel and its working fine.
4) If user doesn't selects any record from the Grid on submit click then its prompts the user that select any one record and I have kept the validation on server side button's click event.
Now, The problem is after submiting and validation occurs. The State's combos items are repeating for e.g. initial items were : --select--, USA and after validation occurs on submit its showing --select--, USA, --select--, USA.
I have not bind the control on page load event as its binded via client side. The property of EnableSynchronisation is True to synchronise client and server items of aspxComboBox.
When I saw using debugger when I click on submit. I have quick watched State combo on page load event and its items count is 4 as 2 are repeatative items.
The problem is on even first line of page Load event when I Add Watch to it I get the items count as 4 that means items are posted wrongly to the server.
When I remove Update panel, everything works fine.
I don't know why wrong items/ repeatative items are posted on server. Please help.
Solved the Issue.
Wrapped the Update Panel to State Combo.
Actually It was not needed as State Combo need not be refreshed via Server Operations as I have used AJAX to bind it on client.
But Wrapping the Update Panel to it did solved the issue.

Radio buttons not retaining selection when user controls are posted back

I am facing some problems when page is posted back partially. I have some radio buttons based on which I am making tr display="" and display="none" by javascript. After that I am adding rows gridview. The gridview contains empltyTemplate and footer to add new rows. But when I add row in grid view, the user control is posted back and hence all the tr becomes displa="none" which is default when page is loaded. I tried to keep gridview in update panel but it not working. Hierarchy of my controls is as below.
Level-1-Master page--->Level-2-master page--->Level 3-.aspx page--->Level 4-user control--->Level-5 -multiple accordians-->Level-6: 1 user control in each accordian..
code is too long to past here.. I tried to keep update panel inside user control(Level 6) but it was not working. After some googling I found that update pane not works if it is inside accrdian. So I tried to keep all accrdian inside update panel but in that case .aspx page is not posted back but all user controls placed inside accrodian are posted back so the selection is set as they are on default load.
I want all selection to retain when the last level user control is posted back.
The situation is quite complex to understand but this is what the things are..How to solve my problem?
Changes made to the DOM from JavaScript are not retained cross-PostBack; the server has no idea what you've done, and therefore has no way to track it.
To solve this, you either need to have your JS code update state on the server side with a Callback or Ajax call -- or perhaps have it update a hidden input field in the form that reflects the state of your tags, and have the server look there and update the rendered HTML accordingly.

Maintain View State After POST

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.
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.
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.

Categories

Resources