This is a very general question. I am using MVC on the back in and JQuery for the front end. I have a select list of values for the user to choose from. I want the user to select the values on at a time by clicking the add button. But this truly does not save them this only stores them in an array. Then when the user clicks the save button i would pass the array to MVC controller method to do the database saves. My problem is that my array is not keeping values. i declare it global but if the page get refreshed or i call a method to filer the list by keyword value the array looses the contents that it had. How to i have an array in JQuery that keeps it value even after a post back?
Normally you shouldn't store unsaved data in javascript array and do postbacks. Obviously if the page is refreshed the data is being lost. So you should choose from two options:
1) You do it on the clientside. So you still have your javascript array, but you don't refresh your page until you are ready to save the data. In this case all the filtering and other stuff you mentioned should be done via AJAX calls from the clientside.
2) You do it on the serverside. So when you have the javascript array and you want to do a serverside postback with complete reload of the page, then you need to push your array to the serverside, but not save it into the database until you are ready. You can temporarily store it Session for example or other collections that persist data between different post backs.
This is high level explanation, I hope you can dig more.
EDIT:
James suggested another valid option of using browser storage of cookies. However storage is not supported in some older versions of different browsers. And I don't feel like this is the task you should use cookies for. It feels like work around to bad architecture.
Related
I have a doubt why we use ViewState because Session can keep its state throughout the application. Then why is the need for ViewState which can keep the state only in a single Page?
First Thing first is to know what is
View State
Is information of a particular page in webforms. It is stored in hidden field. It is used to maintain that the page remembers what he did on it the last time.
Session
Is information that is related to a specific session.i.e. certain browser
now coming to your question
When to use and not use is a cluster F......
as all have their specific pros and cons specially ViewSate is more a con I guess since the MVC was introduced.
One can use viewstate to store values to remember when its page have a post back as every time, when a page is in a post back stage it removes all the values of user controls .i.e. like Label and TextBox in asp.net . So to keep the value you've toEnableViewState property to true
Session on the other hand is used when you wish to move from page to page, to keep some specific value for all the pages. For example: one keeps UserId in session so he can visit all the page which need some kind ofauthorization or authentication
Update
As you've changed you question while I was type:
In that case
Sessions is for specific time whereas Viewstate does not as Viewstate is a temporary storage mechanism. Controls that use viewstate have their state rendered into the html page as hidden input.
Hope this will help you in any way, and don't worry about vote down you'll get use to of it
If the user opens several instances of the application in different tabs of the browser, the data stored in Session will be shared by all of them (unless something special is done to avoid that). One instance modifying a value in a Session variable will overwrite the same variable saved by the other instances, causing a mixup of the data. Using ViewState ensures that each instance is not affected by the others.
I'm working on a page that has several server side dropdown lists, one with 500 items. Based on what's selected, I show/hide other page elements during postback (I only bind the data on initial load). The customer opens this page a lot and I don't want them pulling the 500 items down every time they open it. Currently, it takes about 2 to 5 seconds for the page to render. I've started to migrate to a fully javascript/jquery version of the page but want your opinion because I'm not loving the new version.
Is there a way to make this page faster and limit pulling down all 500 items every time?
Note: Some users will want to enter the dental procedure code directly. Others will need to do a look up.
We work on a system where a user's name can be selected from a dropdown list and then user information is displayed below. There are approximately 600 users and one of the stakeholder requirements was that the users had to be selectable in a dropdown list - the stakeholders felt that non-technical users better "understood" how to use a dropdown list.
Our performance for loading the dropdown list is very good. We do the following:
Load the page as quickly as possible but DO NOT load the dropdown list
On page load, display a loading indicator and then immediately fetch the data for the dropdown list
We get the data by calling a webservice using jQuery that returns ONLY usernames and IDs and data is returned in JSON format
The query that requests the data is cached on the server for future requests
The resulting JSON object is used to populate the dropdown list
Hide the loading indicator and you're done
The above occurs extremely quickly and makes for a very pleasant user experience.
If anything, try very hard to do the following:
Avoid postbacks even if you're using an Update Panel - these will kill performance if you have a large viewstate
Only return the absolute bare minimum of data that you need to populate the dropdown list
Don't access any data that isn't immediately necessary. Get the page loaded as quickly as possible and then fetch the remaining information while the user is reading the page
When adding large amounts of data to a page, milliseconds count. Anything you can do to reduce calls for data (and the subsequent adding of that data to the page) will drastically improve the user experience.
It's been a while since I've done asp.net but remember something from the Ajax control toolkit that is like a set of filtering drop downs that group items so you don't have to get the full list.
For example if you're getting a list of all cars, you could have the first drop down as Manufacturer, which when selected activates a second drop down with their range of Models. It limits the ammount of data you have to load at once.
A dropdown list is not a good container for 500 items because the looong list looks ugly and it's hard to locate an item. You can change it to a table-like control(from server view, a gridview or a repeater) with paging function(e.g. display 20 items per page), also you can add some textboxes above the table, users can quickly locate an item by typing some keywords. After that, put the table in a update panel to make the page partially updated when clicking some button.
Anything you can do on the page that doesn't require the entire page to change can be made AJAX-y by enclosing it in an UpdatePanel. UpdatePanels and ScriptManagers allow ASP.NET pages to perform partial postbacks using AJAX, which will speed up anything but a full page reload by drastically reducing the number of data that has to come across.
Other performance tips/tricks:
If you're using an ORM, or generic queries, to pull in records, try to pull the minimum amount of data you need to show the results. The more data that has to come from the DB and be digested into the viewmodel, the slower the back-end will be.
Avoid nested MultiViews. Multiviews are great for organizing a lot of data in a "tabbed" fashion, but behind the scenes a MultiView is rendered as a series of divs with CSS to hide/show them. That means that EVERY tab of a MultiView must be rendered on the initial page load. When multiple MultiViews are nested as Views of other MultiViews, the problem is compounded. You can avoid this by using the codebehind to dynamically select and insert the proper control into the page, or by using other code to detect whether the View that this control corresponds to is the currently-selected view, and skip any heavy lifting of data retrieval/processing that would otherwise happen. You may combine either approach with some AJAX components.
I'd start with correctly indexing the database.
One way to speed things up would be to get rid of the postbacks. Showing/hiding page elements is a client-side operation and doesn't require a postback. If you're using jQuery already, you can .show() and .hide() any element on the page.
This doesn't necessarily address the performance of the initial page load, but would improve the performance of the overall user experience when interacting with the page.
For the initial load, perhaps break out various data-bound elements into AJAX calls that happen behind the scenes after the initial page markup loads? I'm kind of shooting in the dark here without knowing a whole lot about the page, but it's worth a try. Maybe load the basic markup without the data in the lists, then on $(document).ready() make an AJAX call to a server-side handler which returns the elements for the first menu. Then, when each menu is selected, fetch the elements for the next menu in the same manner.
The overall load time would be roughly the same (maybe even a fraction of a second longer), but the UI would fully render in the meantime and you'd be using the time the user spends looking at the page and starting to interact with it, a few precious seconds, to load the rest.
Edit: In response to one of your comments above on the question, maybe you can use the jQuery UI Autocomplete to improve the user experience a little? Do the users necessarily want to select the codes from a list, or would it be easier for them to start typing the code and narrow down to the correct one? From a data-entry perspective, avoiding mouse usage is often a good idea.
Using javascript or any of client script is not an solution because the client browser may have javascript disabled...
I would suggest you these opmization,
Optimise database query if your table containing 500 records and
is not frequently have insert/update operations then create unclustered indexes.
Cache the data if not changes frequently.
Create stored procedures improves query results because it's being precompiled query and prevents sql injection attacks.
In my ASP.NET WebForms application, I have a WebForm that contains an UpdatePanel and multiple views used for a wizard like interface.
At the end of the wizard, the user has an option of moving to another page by clicking a button. This new web page needs about 5 values from controls in the previous page.
What is the simplest way to do this? (Edit: ONLY using an HTTP POST with data - this is a requirement as I would use database/session otherwise)
I tried using cross-page posting with no luck, possibly because of my update panel and multiple views?
I tried using Server.Transfer, but this also breaks because of the update panel.
Important:
Data has to be sent via HTTP POST - The data can't be stored anywhere
The scenario can't be changed. I can't put everything on the same page
The simplest way to do this is by putting those values in the session object.
You could make a class that describes the data that you need to display on the redirected page. Instatiate a new instance of that at the time the user is filling out the wizard data, populate the new classes' object with the information you need, then add it to the session in the button_Click event before page redirection. On the page you are redirected to, grab the Session object, put it into a variable and extract the data you need.
I recommend you combine all the relevant pages into one; hiding panels that are not in play. ASP.NET will maintain the values of all the controls for you from post to post. The Viewstate was designed for sceneries like you describe. To keep to Viewstate size to a minimum, make sure you fill lookup values for drop-down controls in their "Init" methods.
You don't want to use the session state. The last thing you want is for the users to loose their data from previous pages because they took too long to answer.
If they're moving to another page in the solution, you have a few options.
ViewState - The ViewState is sent with the page delivery. It resides in the HTML, but is encrypted so no one can see the information. Depending on the size of the information, your page size could get rather large.
Session - This puts the information client-side via cookies.
Query String - Using the URI. This should only be used if it's non-sensitive information and if you don't want a user to be able to link back to the same action again.
I have an list of paged results that is using AJAX requests to populate next/previous page clicks. I am using the jQuery history plugin to keep track of the page # the user is on. This basically appends http://site.com?query#pg=5 to the url.
If I click through to another page, I am trying to implement a Go Back button in the breadcrumb control. In trying to use:
Request.UrlReferrer
it seems that this does not preserve the # value at all. Is this possible?
The browser is responsible for setting the HTTP_REFERER header and sending that to the server. There has been research done for other questions on Stack Overflow (e.g. this one) and it appears that none of the modern browsers send the hash value.
All is not lost, however. A colleague of mine was faced with a similar situation and ended up setting up an AJAX call to the server to track the hash values on the server as well as the client. It's a bit hack-y, but you can make it work.
I have a complex page with maybe a dozen POST element and a file upload (non ajax ATM).
I have a form with a description, if it causes akismet to find it as spam i would like the user to be informed and either hit back on their browser to try again or to hold call POST data so the user can fill in a reCaptcha to bypass the spam marking.
How do i hold the POST data? i have no idea how to redirect the user to this captcha page and to keep all the post data. It would be preferable if it was generic and i didnt need to copy the post and get data by hand.
One solution could be to create hidden form fields with all received data. This is easy to do it generically, just iterate through all $_POST elements and create a new hidden field for each one.
Obviously you must create a valid form.
Once this new page is loaded you should redirect to desired location.