I have an ASP.NET application that displays various views into a largish database of protein sequences. As a visitor browses the data, I'd like for them to be able to select a CheckBox in the GridView row to flag sequences for later download as a zipped text file. I don't want to store the selections so they should just be valid for the session.
My idea right now is to add a TemplateField to the GridView and then add a CheckBox to that. I intend to handle the check events and store the sequence IDs in the session state. When the user heads to the download page I'll get the session data, display the list of sequences they are about to download and then send the file along. Obviously I'll also have to reparse the session data on every form load / page switch.
So I actually have a couple of questions about this:
1) Am I doing too much work? Is there an easier way to implement this?
2) Are all the round trips to the server for the session state likely to be a performance problem? I can put a "Save for Download" button on the page to batch it to help things. Handling the check events just seems more error tolerant since you can't accidentally lose your state if you navigate away.
3) Is it possible to sort the GridView by the checked box column? I'd like to sort by the checked box column first then the currently sorted column (e.g. If the GridView is sorted by last name, sorting by the check column and then by last name).
In case it matters, I'm using C#, .NET 3.5, VS2008 and I'm using the simple drag-n-drop way of creating a GridView from a SQLServerExpress table.
Use AJAX via a Page Method to keep track of the checkbox status in the session state. This will minimize the round-trip cost.
I don't think you'll be able to sort by the check box in the GridView as you need to specify the sort column. You may be able to do this by making a synthetic data source that basically joins your saved session information with the data from the table but not by using a SQLDataSource connected directly to the table.
I'm not sure there's an easier way to do it, but as for your other questions:
2.) You need to decide for yourself the balance between robustness and network traffic. If you use the check event, you're going to go back to the server quite a bit. If you use a different event (losing focus on the grid, an explicit "update/save" button click, or navigating to another page), you cut back on traffic at the expense of possibly losing information. It's a UI design decision with no "right" answer.
3.) It's possible, though it may not be automatic. I know that DataGridViews will generate handlers to sort by checkbox columns automatically. I'm not sure it's that easy with the regular GridView. Is there a reason you're using a GV and not a DGV?
Related
I have created web page that retrieves data from MS SQL database and display it to the user in well formatted manner. Data retrieved depend upon criteria selected by the user. But sometimes data retrieved is very large. I want to display records to the user page wise, i.e. 100 records on first page and next 100 records displayed when user clicks next button. This means only 100 records should be retrieved when user first select search criteria, next 100 records retrieved when he clicks next button and so on, as to reduce data transferred from server to client.
Please suggest me how to achieve this as soon as possible. Thanks in advance.
What you are looking for is called paging.
This can be done a million ways. You mention jquery, javascript and asp.net. For displaying purpose that is quite all righ but for good performance you want to make sure that the actual selection of the page has to be done at the backend.
One approach is this:
http://msdn.microsoft.com/en-us/library/aa479347.aspx This is not jquery but it shows a way to do it.
You can use jqGrid or DataTables. Both are very popular grids
Ask user to set there criteria and then render the grid according to that.
If you want simple fast and way then think in using jQuery plugins like these
jpaging OR datatables.
you should search for design pattern for this.
kindly look at this Easily build powerful client-side AJAX paging, using jQuery
Your use of both asp.net and C# makes me (probably because I am partial to it) think "WebMatrix". If, indeed you are using WebMatrix, check out its Grid Helper. However, be warned that this method can generate some very serious overhead for your html page (by that I mean that if you query 1,000 rows and only use 100 per page, it will retrieve all 1,000, use 100, and waste the other 900). Also, using the WebGrid generates the results in a table, which may not be your preferred style.
Alternatively (still thinking "WebMatrix"), you could use this article here (this is my preferred method): http://www.mikesdotnetting.com/Article/150/Web-Pages-Efficient-Paging-Without-The-WebGrid
Don't worry, that article is explained with EXCELLENT brevity and accuracy (and explained better than I could, so I leave it to Mike to vicariously answer that one).
I'm developing a webpage where users can filter data and then export the selection to pdf or excel. The website is using ASP .NET C#.
To filter the data I have crated a webpage containing a left column with boxes and drop downs enabling users to enter search criteria and then click a search button. This is the typical search/filter functionality that a lot of websites contains. After filtering the data, the selecting is displayed using an asp listview. This listview generates a table. I've implemented Dragtable, enabling users to alter the sequence of the columns in this table, and also the columnManager enabling users to select which columns to display.
So my problem is that the filter/search functionality is resolved back-end using asp .net C#, while the selecting and rearranging of columns is done client-side using jQuery. When users now click the "export"-button, I'd like to collect the filter done by the asp controls in addition to the filter done by jQuery, and create the file. This file should only contain the columns selected using columnManager, in the same order they are in after being altered using dragtable.
What is best practice when using both server side filter and client side filter? I've also considered to drop all of the server-side filtering and use only ajax.post() to send all filters in JSON format to the server.
I also want to enable users to save their current filter for another time.
Update
I've decided to drop the server side and use ajax (getJSON to be more precisely) to get the search result. This way I don't loose the ordering and sorting of columns that is done with jQuery/js, which I would with a post-back (could use cookies'n stuff, of course).
I also keep all the logic in one place, and JSON objects can easily be wrapped/unwrapped server-side. Thanks for your answers, though!
It's not at all bad to have Client side and Server side working at same place.
All the good applications running in the world have these combination together.
However we need to see the approach.
If you don't want any postbacks , I would recommend to go with Jquery.
If you are ok with roundtrips, go ahead with Server Side and Ajax.
Your approach has another problem: What happens if the user orders the columns first and than filters it? The order of the columns is resetted.
However with the jquery ui draggable you are able to fire ajax calls to notify the server side code about the change. You can bind a function to the stop event: http://api.jqueryui.com/draggable/#event-stop
So I would do the following:
Fire ajax call when the user changes the order of the columns, but do not refresh the data
Fire ajax calls when the user adds a filter AND refresh the data
The server side code is always up to date and renders the correct ouput if it has to.
Hi
Let's say that I've to list thousands of records for my client.
How should I implement this? Some say that I have to retrieve just 300 or 400 records from the database and show those to the client. But I think there will be some problem with pagination. If I get all records from the database then I will have a performance problem. Some say to implement our own store procedure. How should I do this?
Thanks
You definitely have to use paging and not retrieve all the records at once, I recommend using some ORM tool to abstract the complexity of the required query for paging, if using LINQ it would be something very simple: ...Skip((pageNo-1)*pageSize).Take(pageSize)
I am in favor of sending ~100 records with the page, paginating through them by JavaScript, and retrieving further records in a batch by some higher number, say, 1000, when user navigates to unloaded data. All with no-script fallback links if you can't force user's to use JavaScript.
(Not sure how easy this is with C# frameworks; with Java's Wicket, this is quite easy.)
Paginate the records ! That will the the only solution (which you haven't yet tried by the way!). You could add Button controls to move between pages, and data loaded to a page when the page is loaded. Or the records could be loaded all at once and stored by the app, and just shown to the user when a page is shown.
Paging is definitely an answer to this. However - Do all your match inside SQL Stored Proc.. Instead of depending on the GridView default paging...
If you don't want to use Paging (some clients are very adamant to show all records) then you can use Scroll event to fetch records on the fly. If you using a Web Application, you can use Ajax Call to fetch next set of records by passing the pageNo,pagesize etc....
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.
I have a database that stores an arbitrary number of phone numbers. There are a few pages that (should) allow admins to change these numbers and add them.
I plan to create a custom control that will:
Show all existing numbers
Provide an edit button
In Edit mode, will show an add button
Have an add button that adds the requisite fields in a way that does not cause a postback.
Provide a save button (of course)
These seems like a complicated task. I've done a bit of research, but haven't found any ready-made solutions. Is there anything I should have spotted or should know before I go about writing this from scratch?
I've built something like this using jQuery. Use a table to display the phone numbers. Then, jQuery excels at being able to hook into button presses and manipulate elements on the page (wrap a table cell's contents with an input box, or add add a table row) without causing a postback, completely aside from any server-side ASP.NET controls. Then, on Save you can stuff the phone numbers into an <input type="hidden runat="server"> in a delimited format (e.g., "212-555-1212|617-555-1212") and let the Save button do a regular postback.
You could probably find a commercial datagrid control with Ajax features to enable editing and add rows but you'd probably spend as much time customizing it as you would writing it from scratch with jQuery. It's the sort of thing you've seen dozens of places but everyone does it a little different.
I've never seen a custom control that worked specifically like that. I'd search on CodeProject to see if a custom control exists before writing one.
Are the existing numbers in a variety of formats? For example: 123-456-7890 and (123) 456 7890? If so, you may have to decide in advance on the format you are going to use and then run a script to clean up the existing records. I would use JQuery as suggested by Marc to enhance the editing experience. Validation will have to be precise.