I have a grid with several thousand rows that can be filtered and sorted. On each row you can click a details button, which will bring you a new page with detailed information about the page. Because this is a button, you can't middle click or right click and open in a new tab. In addition, when clicking back you lose your filters and search results.
To solve this problem, I considered the following: Switch the buttons to links, and when filtering and searching, use get instead of post requests. This way, you could switch to new pages with a right click or middle click, and if you did follow a link normally, back would work properly.
This change was not made however. We were asked add a 'next result / previous result' set of buttons on the details page, that would allow you to navigate. While not an elegant solution, it would at least work.
I proposed adding querystring parameters to the details page, that would regenerate the search query based on filter, and allow you to get the next and previous results in code.
A team member took issue with this solution. He believes that it is a waste of server resources to re-query the database. Instead, a solution was proposed to add session variable that included a list of results. You could then use that to navigate.
I took issue with that because you can't have multiple tabs open without breaking navigation, and new results aren't appended to the list in real time. Also, if you worried about optimization, session would be the last thing to use since it eats memory and prevents server replication... unless you store the results back in the database.
What's the best solution?
Session doesn't sound like a winner, won't scale with lots of users.
Hitting the database repeatedly does seem unnecessary, but it depends on the cost - how many users, how often would they refresh/filter and what is the cost of that query?
If you do use querystrings you could cache the pages by parameter.
What about some AJAX code on that button to retrieve details - leave the underlying grid in place and display details in a div/panel or a new window/tab.
Related
I am making a website where users can see photos uploaded,
In any page, the users can click a button and "see three more photos", this is limited up to 100 photos per webpage.
basically I can use ajax to read the next 3 rows from the photos table, and load them to the user using ajax, but, while the user is browsing the site, the DB is most likely to have already been updated, and changed.
I have come up with two solutions and I can't decide between the two:
use ajax to load in the background first 100 items into an array (just the urls of the photos), and use javascript to display them on the page when the user click the "see three more"
create a new temporary table in my db, containing the first 100 rows, so I could access every time with ajax, while I'll know it will not change by another user uploading a new photo.
the goal is to find a way that will not be too time consuming for the server (in case there are a lot of requests and many temporary tables will have to be created),
and also a way that will not be too heavy and bandwidth consuming for the user (I don't want to load 10 MB of stuff to the clients browser "just in case" he will push a button).
which option would be the better one?
is there a third option i'm not thinking about?
Thanks guys!
I would say that creating temporary tables isn't a good solution for the reasons you have already mentioned; you'll be doing a lot of cleanup work and you're not really solving your other problem, which is heavy bandwidth consumption.
I think the problem is your user experience expectation, which I'm not really clear on.
So - I'm a user of your site, I go to a page and see some (how many?) photos - with a button that says "see 3 more". I click it and see the next 3 photos, loaded using AJAX.
Does it matter if there are 50 new photos added in between each time click "see 3 more" ? Surely I want to see the next 3, not the newest 3 ?
Loading "the next 3 via AJAX" doesn't mean you have to preload the 100 URL's into a client-side array; just keep the most recent Image ID or most recent date/time client side, and pass this to your server-side function in "see 3 more"; should be straightforward enough to return the next most recent 3 URL's (if there are any) and then update your "current" Image ID.
Does that help ?
I have to mock up a ticking dashboard which is part of a proposal. I am looking for ideas other than the HTTP Refresh option that I am thinking of. The objective is to quickly mock up a look and feel and a working dashboard that ticks over. It only had to provide new content every five seconds. EG there are a bunch of KPI's and their outputs which are percentages have to be updated..
A simple bunch of HTML pages using HTTP Refresh is on my mind. Is there a better option anyoine can think of. EG can HTML5 do this better? Is CSS an option? Thank you in advance for any ideas
I would be going for an ajax call back to the server to get the latest update and then embed that wherever it needs to go - you could set the ajax function on a timer to run every 5 seconds or 1 second or whatever. This way your entire page is not being refreshed, and additionally you can be calling back to the server for a new update even while the previous on is still being rendered.
Downside is that you won't have a page history (i.e. the users will not be able to navigate 'back' to previous ajax updates) unless you explicitly create one; I can't see that being necessary though.
Please post a comment if you need more info about ajax.
Currently reading Bloch's Effective Java (2nd Edition) and he makes a point to state, in bold, that overusing POSTs in web applications is inherently bad. Unfortunately, he doesn't specify why.
This startled me, because when I do any web development, all I ever use are POSTs! I have always steered clear of GETs for security reasons and because it felt more professional (long, unsightly URLs always bother me for some reason).
Are there performance differentials between GET and POST? Can anyone elaborate on why overusing POSTs is bad, and why? My understanding - and preliminary searches - seem to all indicate that these two are handles very similarly by the web server. Thanks in advance!
You should use HTTP as it's supposed to be used.
GET should be used for idempotent, read queries (i.e. view an item, search for a product, etc.).
POST should be used for create, delete or update requests (i.e. delete an item, update a profile, etc.)
GET allows refreshing the page, bookmark it, send the URL to someone. POST doesn't allow that. A useful pattern is post/redirect/get (AKA redirect after post).
Note that, except for long search forms, GET URLs should be short. They should usually look like http://www.foo.com/app/product/view?productId=1245, or even http://www.foo.com/app/product/view/1245
You should almost always use GET when requesting content. Only use POST when you are either:
Transmitting sensitive information which should not appear in the URL bar, or
Changing the state on the server (adding/changing/deleting stuff, altough recently some web applications use POST to change, PUT to add and DELETE to delete.)
Here's the difference: If you want to give the link to the page to a friend, or save it somewhere, or even only add it to your bookmarks, you need the full URL of the page. Just like your address bar should say http://stackoverflow.com/questions/7810876/abusing-http-post at the moment. You can Ctrl-C that. You can save that. Enter that link again, you're back at this page.
Now when you use any action other than GET, there is simply no URL to copy. It's like your browser would say you are at http://stackoverflow.com/question. You can't copy that. You can't bookmark that. Besides, if you would try to reload this page, your browser would ask you whether you want to send the data again, which is rather confusing for the non-tech-savy users of your page. And annoying for the entire rest.
However, you should use POST/PUT when transferring data. URL's can only be so long. You can't transmit an entire blog post in an URL. Also, if you reload such a page, You'll almost certainly double-post, because the above described message does not appear.
GET and POST are very different. Choose the right one for the job.
If you are using POST for security reasons, I might drop a mention of other security factors here. You need to ensure that you send the data from a form submit in encrypted form even if you are using POST.
As for the difference between GET and POST, it is as simple as GET is used to send a GET request. So, you would want to get data from a page and act upon it and that is the end of everything.
POST on the other hand, is used to POST data to the application. I am talking about transactions here (complete create, update or delete operations).
If you have a sensitive application that takes, say and ID to delete a user. You would not want to use GET for it because in that case, a witty user may raise mayhem simply changing the ID at the end of the URL and deleting all random uses.
POST allows more data and can be hacked to send streams of files as well. GET has a limited size though.
There is hardly any tradeoff in using GET or POST.
What is the most standard or best way to persist data between requests?
Should I use cookies or session variables? I'm interested in keeping data like sort order, sort column, and page number (for paginiation).
I'm coming from a webforms background so normally this type of thing was automatically handled for me in the viewstate of the controls I was using.
update
I like the querystring idea, for searching and more meaningful URLs; however, I'm working on an "index/list" view, which consists of a View with header, and "control" options, like DDLs for filtering and a partial view that renders the table of data.
The DDLs use a $.load() to call an ActionResult on the controller, which returns the partial view, passing parameters there in the querystring, but since these are ajax requests the main page url of the user's browser does not get updated.
Is there a best-practice for taking querystrings off the main-page URL and using them in ajax requests to other ActionResults?
If you want it to survive only through one request/redirect TempData is your friend.
However, for things like your pagination, URL is the best method, for the ability to share links alone.
A standard way is to pass those sort of things via URL Query Parameters. You can modify your routing to expect certain URL variables. That way the pages become more search engine friendly as well.
It depends on how permanent you want the information to be:
Things like the page number should indeed be in the URL (as others have pointed out) - this helps with bookmarking, etc, but remember that if you add more content to the list, then that bookmarked result set will not always be what the user wanted...
If you're happy for these values to be lost when a session times out (by default around 20 minutes), then put them in Session.
If you think that sessions are going to timeout before the next request, or you want to save it across visits then you should be storing them in either cookies, or a profile (potentially allowing "Anonymous" profiles, which work with the users cookies, so they would lose them across machines).
Personally, I'd think very carefully about putting sort order and columns in the URL if you do you could actually end up really confusing search engines:
Lots of pages with very similar content (page 1, sorted by date desc, page 1 sorted by date asc, etc) - search engines don't like duplicate content, and nor should you as Google (for instance) will only show two pages from your site in a default result set, you want them to be valid, not duplicates.
Search engines will spend lots more time crawling your site, and potentially give up - If on every page they find links to "Sort by this column", they will attempt to follow them, resulting in more work on the server, higher bandwidth use, etc.
These can be mitigated through the use of a Robots.txt file denying access to sorted versions of the page, but if this is generated almost dynamically that will be very complex to maintain going forward.
In response to your update, a nice way to achieve that for pages would be to have links to "Previous" and "Next" pages of results (or better yet, a list of all pages in the list), output on the page, with the page numbers, that you then hide with JavaScript.
This way users should see your nice, AJAXy behaviour, and search engines (and users without JavaScript - mobile, or those using older screen readers for instance) will still be able to get access to all your pages - this will help your pages to degrade gracefully, or use "Progressive Enhancement".
Things that were previously in viewstate should probably be put back in the clients hands via either hidden fields or cookies.
Session is "too" easy. In a dev environment it works great, pretty much no matter what you put in it. In production scalability and persistence become a problem. In-process session is likely to disappear unexpectedly if you have crashing bug in your site, and requires server affinity when load balancing. Out-of process session fixes the durability and affinity issues, but can still be a performance bottle neck if too much stuff is put in session. A VERY common problem is that each page will put 1 or 2 items into session but never take them out again when they are done. And even if a page removes it session data when it is no longer needed, the data can still get orphaned if a user starts a process and never completes it.
Cookies is a fast and simple way to persist data between requests, and you can also make them live only for a limited time depending on your needs.
Session are easiest.
I have this GUI that shows, let's say Customer Orders. When my client nailed down the requirements, he asked me to keep pagination like this,
Show Items Per Page : 10/50/150
For each customer there could be thousands of orders and each order will have atleast 50 attributes to show up in the screen. So, assume a 50 column html table with 2000 or 3000 records associated with it spanning across multiple database tables (anyway, this is a different story)
Things were breeze until yesterday, now my client has come up with new change requests, in that he specified Show Items like this,
Show Items Per Page : 10/50/150/All
Yes, he wanted to see 2000 or 3000 records by just select "All" option. Internally, this is not a big change, I would go back and remove the filters I apply on rowcount etc., but when it is loaded in GUI it really sucks ... view state was huge etc., etc.,
I know, this is a standard problem. How you guys deal with it? I cannot convince my client to remove this "All" option, he got stick to it. (the reason is simple, he got a big 42" screen where he can easily see 1000 items in one page)
I also tried to use javacript to prepare DOM in a ajax call .. but still, inserting 2000 TDs is really slow.
Any help is greatly appreciated.
Some Extra Info
This application is a intranet application or else accessed through VPN connection
This problem is about browser performance.
I suppose you can do two things.
1) you can use <div> instead of <table> (this is possible with CSS) because browser do not render table until closed tag. So it will take long to load page but it will render first results faster.
2) If you use Ajax+Json and render every <tr> piece by piece, you can render whole thing and only than put it in DOM. That will be faster because browser will not render every time you put another row
If you want you can load the data in sort of installments. Sort of like how pagination works but it is not quite pagination to be precise. You can label your installments/pages with a proper ID. Load the page one after another via ajax calls. You can even show a progress bar to show how much data is actually loaded. Append this data to the table you are displaying the data in. I would not go about using server controls for this...you have to handle this via javascript or jquery.
You might want to append table rows incrementally.
When client scrolls close to page bottom - fire an ajax call, return next page and render it.
But best solution would be to convince your client - this is not how web applications works. We had similar situation - pure nightmare.
Instead of an ASP.NET GridView, you'd be better to use a DataRepeater.
Better yet, if you are not constrained by technology, you can use Microsoft Ajax Preview 4 with WCF REST Services. You would just need to find some hacks to "stream" data from the service and display it.
Also there is JQuery Grid (if you don't want to use Microsoft Ajax Preview 4) that supports JSON serialization.