I have a very simple ASP.NET MVC site which displays images from the database. The user fills out some search parameters and a View returns a list of images from the database which match the search criteria.
I'm now adding Pagination, where depending on the page number I skip a certain number of images retrieved from the database. I've got this working for the first page. My search parameters are lost when I click on the second page of results as I have no mechanism in place to store the search parameters between Views at the moment.
What's the best approach to take. I could have lots of search parameters. Should I store them all in the Session or in hidden fields? That feels like a hack. Should I have a seperate ViewModel to hold the search params and store that in the Session?
What's the typical approach to take?
You would typically store cross-pagination data in hidden fields. For scalability, sessions should be limited to session-wide related data. If putting the data in hidden fields opens a vulnerability, you can consider serializing a view model and encrypting it as one hidden field. Putting it in the URL is another option, although you are limited to the amount of content you can put there.
I would put them all in the querystring of your "Next" and "Previous" links. This would allow visitors to bookmark the full URL and return to the same page with the same sort and filter settings.
Related
This is a Rails 3 project.
Am I abusing the use of cookies if I store query values there? I have a dataset that a user can "drill-down" through, so as the user clicks through the data, he amasses a bunch of query values that further limit the data presented on the next request.
Right now I'm doing this with a cookie, and it works great, except that I can't figure out to check to see if cookies are enabled. So some people using IE are giving me fits because the app just fails with no errors.
I used to put values like this in a session variable, which worked great until it mysteriously didn't, i.e. when memcached aged or cleared them out. I wouldn't want to keep the values in a session in the db because I don't want the extra hits on every request.
So I suppose I could put the values either in hidden form fields, or append them to the links on the page that I'm presenting each time. Is there a conventional Rails Way to do this that I'm missing?
If you're showing a different set of results, the URL should reflect this. This makes URL query parameters the natural choice. This provides several benefits:
There is no state at all. You don't have to store anything or break the stateless nature of HTTP.
There is a one-to-one correspondence between sets of query results and URLs.
You can link to query results.
Works on everything, ever.
I have a form where the user can choose options from a lot of select boxes. The form is used to register several items from an RSS feed. The user fills in the form, clicks create and is presented with the same form for the next item in the list.
Sometimes, the same options are valid for several items in the list, and I would like to be able to save some of the selections done so the user doesn't have to make the same selection for the next items.
What is the best way of doing this? I've identified four ways of doing it:
Sessions
Just keep the values in the session hash. This will of course work and is very simple, but I have some undefined feeling that it is a bad idea. It will also not work if the user is using the form from different tabs in the browser.
Cookies
Basically the same as keeping them in the session, I think.
Profile
Can't be done in this case I believe, since profiles are shared between several users.
Database
The most complex way I've come up with is to keep the information in the database and use a query parameter to keep track of which information should be used. This is probably overkill, but in some ways the best way to me. I don't like the idea of keeping this kind of state in session or cookies.
Am I missing some way? Or something?
If after filling first form, some data is saved to db (object is created) then you can use this data from db to fill up new form.
If after filling first form, nothing is saved to db, then you can create in memory some objects based on params from previous post and based on this (on just on params) you can prepare new form. But of course data from previous form should be added as hidden fields in second form.
Im using MVC ASP.NET C#, jQuery
I'm building what could be decribed as the simpliest shopping cart in the world.
Basically My Clients wants users to be able to browse the site, Click on a product they want and it be added to a "list" and then when they "Checkout" they simply fill in a form and it emails my client with the list of products they had chosen!
I was thinking of something like storing them in a cookie. So as the user browses they won't be lost, Then have a jQuery dialog appear when they choose to view/checkout their cart. and it can list all products and then they simply fill in a simple form..
Is this the best way to go about it. Its a cheap website and I would like the simplest way to do this? All i guess I would need to sort is the product Id's..
Any ideas of better ways or any opinions at all!
Using Session depends on whether you think the users will pick the products in one go. Or will they leave the page and come back in an hour? The problem being that if they come back in an hour, the Session State may have been garbage collected to free up resources on the server, or the session might have expired.
To get around this, if all the products are on one page, you could store the chosen products in a hidden field, encrypted and all, that will stay there until the user closes the app.
You just need to serialize the list of product Ids, pass that serialized string to the view and put it in a hidden field.
Another option would be to store it in the users session. A benefit of this is if the user has cookies turned off and the site caters for cookieless session state then they will still be able to select products and checkout.
The thing to look out for is how much you could potentially end up storing in session. From the sounds of it this will not be an issue but if this could potentially use up an unacceptable amount of memory then you would probably need to consider a database approach anyway rather than cookies.
I'd say to go for the Session object. You can always configure the location of Sessions at runtime
I think some may dislike this storage method (it breaks testing isolation, if i'm not mistaken), but it's there for free :)
If you're using jquery, you could store the basket as a json array inside the $('body').data() element (or actually as i do, under a div called '#storage'). this works as a fantastic local storage mechanism, tho' would only be relevant to the current page that the user was on and would be cleared on moving to subsequent 'new pages' unless of course, your design was such that the shopping page was ALWAYS the same page and only refreshed by ajax methods. this way, you could continually append/modify the json structure on the 'worksurface' page.
i use this technique for a different application of the logic, but virtually for the same reason.
here's a snippet of the kind of thing i do:
/* example of data params key*/
var keyParams = "Data-Search-type-" + $('#searchtype').val();
/* add json to body with key*/
$('#storage').data(keyParams, jsonData);
/* get same data back later */
var jsonData = $('#storage').data(keyParams);
When i 'save' the data to the server, i then clear the data() element back to null. There is of course the other option of localstorage itself which can be used well, especially in disconnected environments (such as mobile apps).
another way to skin the many skinned cat!!
I am working in ASP.NET 3.5 MVC application. We have a functionality where we search for say "Customer search results", using some parameters.
If the user enter some search parameters like say, Date of birth/SSN/address, and hits search, the search results are displayed in a grid below. One of the records in the results can be clicked and it navigates to the customer information page. And from that page you can click on "Return to Search results" to come back to the search results page again, which can potentially show up the search parameters and the results of the last search.
We use sql server session state. And I am using the viewmodel and model binder to store the search parameters and results. So when the user comes from Customer information page back to search results page I am using the data stored in my model binder to bind the search results back.
However say the user is in customer information page and by the time the session expires, and when user tries to return back to search results page, the search parameters and search results are lost.
I should be able to pull the search parameters from SOMEWHERE where it can be restored(the store should not be a SESSION) when the information is lost. What I was trying is to store the parameters in the SQL table and pull it back when the data in my session is lost.
I don't necessarily worry about the search results as I may need to call a service to pull the results, but only care about the way to retrieve the search parameters when its lost due to session expiry.
May I know if there is any other way to do this apart from storing the search parameters in a table?
SARAVAN - you can use localstorage (if using javascript). this is implemented in quite a few libraries out there and is even used as part of the jquery .data() method. i'm using mvc2 and make a lot of use of this mechanism - it works!!
see:
http://dev.w3.org/html5/webstorage/#the-localstorage-attribute
or
http://en.wikipedia.org/wiki/Web_Storage
or
http://msdn.microsoft.com/en-us/library/cc197062%28VS.85%29.aspx
jim
[edit] some localstorage jquery links:
http://plugins.jquery.com/project/DOMCached
http://plugins.jquery.com/project/jStorage
using asp.net mvc, I'm initializing a list in the server code, and allowing the end-user to add to the list on the form (using JQuery to add entries). I know how to obtain a list's selected items on a post back, but I don't need to do that here. I want the complete contents of the list accessible in the server code after a post back.
Is a posted list just not going to give me the full content? Should I use Ajax to send each item to the server as each items gets added to the list?
thanks
There are a couple of ways that I can think of doing this.
make an ajax call each time an item is added - as you suggested
when an item is added to the list, you also add a hidden field to the form that will be submitted. Then on post back (although that terminology is very Web Forms-y), in your action method, you'll have access to the contents of the list. If you name things correctly you should be able to model bind to a List.
The latter would be my preference, it depends on your particular situation though.
Some things to keep in mind:
Bandwidth from the user to the web server is very small compared to bandwidth from a database to the web server
The database most likely cached whatever query you just ran to populate that list
It sounds like you're asking for the entire list to be included with the postback data, and that means having the browser upload that data for the user.
With all that in mind, it should be obvious that you're better off rebuilding your base list from the database.