I'm working on replacing an existing web grid in an ASP.NET web application, with a new implementation. The existing grid is powerful, but not flexible enough. It also brings with it all kind of frameworks we don't like to have on our web pages.
While looking into existing options I noticed I can break the available solutions into two main approaches. The older approach is represented best by the ASP.NET GridView. This is a classic ASP.NET control that generates the needed HTML on the server, based on a given set of data. The newer approach is depending on client side rendering, mainly with jQuery. A good example would be jqGrid. Only the data is sent to the client (Usually with JSON or XML)
In the GridView case, if I want an AJAX behavior, I would have to implement it with something like an update panel.
Is there a definitive choice I should make?
Is there a good chance of achieving the same snappy behavior I get with jqGrid (even with many records), with server side rendered controls?
Is there some hybrid implementation incorporating both approaches?
There is no definitive choice you should make, but it's worth noting
that changing to client-side AJAX controls is a pretty big paradigm
shift that will require you to rethink how you do nearly everything
with the grid.
Going half-way (by using a server-side control such as GridView
in an UpdatePanel) will likely improve the user experience, since
the page will still be visible and responsive while it's updating. But
the UpdatePanel-style is still clunky compared to the new client-only
grids, because this technique sends all the page's form data when it posts back
(including all that ViewState in the GridView, if ViewState is turned
on). One brief note of caution: GridView is not compatible with
UpdatePanel when GridView.EnableSortingAndPagingCallbacks is set to true.
I haven't used any of they hybrid implementations (such as Coolite's Ext wrappers for .NET), but they are out there. There was at least one good SO discussion about this topic and the different grids available here.
I am also evaluating jgGrid vs. Gridview. I am just interested in the performance and efficiency of the grid. Even though jqGrid has a bit learning curve, I can invest some time in learning if it can provide great improvement in performance when compared to gridview. Can any expert throw more light on this topic?. Thank you very much.
Related
When creating dynamic controls based on a data source of arbitrary and changing size, what is the official way to track exactly how many controls need to be rebuilt into the page's control collection after a Postback operation (i.e. on the server side during the ASP.NET page event lifecycle) specifically the point at which dynamic controls are supposed to be rebuilt? Where is the arity stored for retrieval and reconstruction usage?
By "official" I mean the Microsoft way of doing it. There exist hacks like Session storage, etc but I want to know the bonafide or at least Microsoft-recommended way. I've been unable to find a documentation page stating this information. Usually code samples work with a set of dynamic controls of known numbers. It's as if doing otherwise would be tougher.
Update: I'm not inquiring about user controls or static expression of declarative controls, but instead about dynamically injecting controls completely from code-behind, whether they be mine, 3rd-party or built-in ASP.NET controls.
This greatly depends on the problem at hand, and the type of controls you're recreating. Are they all simple text boxes or various different complex custom user controls. the main thing here is: if you want your dynamic control to regain state after a post-back, you have to re-create it in the Init phase of a page life-cycle.
Anyway. There's nothing like a Microsoft way or Microsoft recommended way basically. When you're dynamically adding several simple controls of the same type a hidden field with a count would do the trick, but when you have several complex controls other ways would have to be used. You could still hidden fields and save control's full type strings in them (ie. System.Web.UI.WebControls.TextBox) and re-instantiate them. But think of an even more complex example of putting various controls on different parts in the page... And initializing them to a specific state. That would be a bit more challenging. Hence no Microsoft way... The recommended way is to recreate in Init phase. And that's it.
Everything can be solved, but sometimes one took a wrong direction in the UI and things could be done easier using a different approach.
Additional explanation
This state-full technique of ViewState that Asp.net uses is considered the worse culprit with web developers in general. That's why Asp.net MVC developers think the new framework is bliss since its much more suited to the state-less HTTP protocol. Me being one of them. :D
Is there any reason use standart HTML controls (input type=text,input type=checkbox) instead of asp.net controls ( asp:TextBox, asp:CheckBox) to improve performance?
IMHO this would be a micro optimization. You will gain performance but it won't be noticeable. On the other hand you will loose much of the flexibility offered by the server controls.
You could try to reduce the size of the ViewState by disabling it for controls that don't need it. This will reduce the size of the generated pages and improve performance.
The ASP.NET user controls will all have ViewState associated with them unless you explicitly set
EnableViewState="False"
As such, you will bloat the size of the underlying page if you have a large number of controls. As a general rule, use what meets your needs and nothing more.
Do you need to access the user control in the code-behind?
Do you need the control to maintain value across post-backs etc?
In most cases, it won't make a difference, but it is good to keep your page clean if you don't need these features.
As always with performance optimizations: it depends on the situation. Test it in your project and see if it makes any difference.
Also with .net 4.0 another con of using server controls is gone, since you can set ClientIDMode to Static, which will give you full control over ID's on your controls. Previously using just a standard textbox or button (without viewstate) would still render crazy non-readable ID's because of the way Naming Containers work. Those days are over now though :)
Remember your three options are:
use regular html which can't be referenced on the server.
add runat="server" to your existing html-tags (ie. ) and you'll be able to access it as an HtmlControl.
use the asp.net tags (<asp:* runat="server" />)
The disadvantage of option 3 is that you don't always know what the rendered html-markup will be and you have less control over it. I personally only use option 3 for more advanced controls like , the button () and third party controls. For normal html-markup that I need to reference on the server I prefer option 2.
Regarding performance I would mainly look at the rendered output, how much extra bloat is rendered to the client and such. CPU-time on the server using one or the other approach I would say is secondary compared to the different caching techniques ASP.Net has already.
I have read through the information in this question: Controls versus standard HTML but am still rather confused.
The situation was I was asked to do a web project where I made a wizard. When I was done with the project everyone asked why I had used an <asp:Wizard...>. I thought this was what was being asked for, but apparently not, so after this I was led to believe that server controls were just prototyping tools.
However, the next project I did my DB queries through C# code-behind and loaded the results via html. I was then asked why I had not used a gridview and a dataset.
Does anyone have a list of pros and cons why they would choose to use specific html controls over specific server controls and why? I guess I'm looking for a list... what server controls are okay to use and why?
EDIT:
I guess this question is open ended, so I'll clarify a few more specific questions...
Is it okay to use very simple controls such as asp:Label or do these just end up wasting space? It seems like it would be difficult to access html in the code behind otherwise.
Are there a few controls that should just never be used?
Does anyone have a good resource that will show me pros and cons of each control?
Server Controls Rely on ViewState, Restrict Flexibility
Server controls were powerful tools to introduce WinForms developers to web development. The main benefit that Server Controls provide is a sense of statefullness and an event-driven development model. However, the state of web development has been maturing since the introduction of WebForms and server controls, which as a whole are being challenged with an increasingly critical view.
The main issue with Server Controls is that they try to abstract the behavior of the web too much, and in doing so, rely on ViewState data and server resources to perform their magic. ViewState data, when used excessively, can severely bloat the size of your page, resulting in performance problems.
Now it is possible to opt out of ViewState, but by then it probably is better to simply resort to regular HTML controls.
With HTML controls, you have precise control over the content of the web page and you have greater flexibility in what behaviors you want on your web page. Server controls offer limited client-side flexibility and force a lot of work to be performed on the server that can easily be performed in the browser with a good JavaScript framework.
Is it okay to use very simple controls such as asp:Label or do these
just end up wasting space? It seems
like it would be difficult to access
html in the code behind otherwise.
If you need to access the control in server side code, use a server control. If not, don't.
Are there a few controls that should just never be used?
Not in my (mid level) experience. The Wizard control, once you know how to use it, works as advertised (imagine coding all the features yourself, then do the math). I've used it and it resulted in a smooth and functional multi-page sign up form with intermediate saving of data.
Does anyone have a good resource that will show me pros and cons of
each control?
I do not, but I'd recommend using the right control for the right situation. Study the differences between a Repeater and a GridView, for example, and use the best choice for your needs.
There of course are alternatives. For one, MVC is gaining momentum. Personally I have not yet committed to learning it. As far as interactive forms and AJAX goes, many .NET devs opt to use JQuery for any validation and any AJAX (UpdatePanels being easy to use and horribly inefficient), with JSON as the transport mechanism to the server side.
What are the advantages and disadvantages of using Ajax update panels in ASP.NET application. Is there any alternatives available to avoid the use of Ajax update panel?
Advantages:
Easy to use and configure (Well, I don't know of any other advantages!)
Disadvantages:
See here and here
Now for the best part, the alternatives:
Use jQuery's built in support for Ajax to make GET/POST Ajax calls, it's very simple (simpler than the update panel I would say), and absolutely compatible with most browsers!
An example of using one of the many easy ways jQuery provides for doing Ajax calls:
$('#anotherContainer').load('/Home/RegularAjaxResource');
This would simply call a server resource (RegularAjaxResource in this case) and display it's returned data on an UI element with id anotherContainer
I agree with 7alwagy, except just want to add an important point.
You have to use the UpdatePanel if you want to update/change controls AND still work within the Webforms Postback model of state control, in particular, Viewstate.
For example:
if you explicitly use JS to update the values of a DropDownList control on the client, and you're using the built in Webforms Postback model, the changes you've made won't be picked up.
Essentially, if you're relying on the built in Viewstates, then you have to use the UpdatePanel. You can technically not use it, but you'll really have to fight agaisnt the framework to get things done.
If you're not relying on Postbacks or Viewstates, then you totally don't need the UpdatePanel.
I seriously cannot think of 1 advantage of using updatepanels. They are grief and i found that out the hard way.
They're usable only for the most trivial ajax effects and if you're going to do any data retrieval or database lookups they have a huge problem in scaling up. UpdatePanels are frustrating and not a long time I have shared the updatepanel grief here, here, here and here.
If that's not enough to convince you not to use updatepanel then nothing will.
I agree that update panel is evil and dangerous but in some cases you may want to use it, instead of other options.
The page has few asp.net controls, and less viewstate.
The page html is not too big.
The time is limited to finish the task.
The performance is not the first concern.
Want to keep the sate of controls with postbacks.
Have a lot of server side events you want to fire.
Advantages:
Easy to implement
No need to write javascript in the client
Disadvantages
Uses more bandwidth since all view states are transferred
Element which is supposed to fire the ajax call should be inside the update panel. It is not practically possible all the time
Data outside the update panel is not sent to the server which may be needed for further processing.
In practice developer cannot pre-determine what all data is needed to include in the update panel
On my journey into the depths of custom ASP.NET control development I am obviously getting my head around the ASP.NET PostBack model and how it affects control development.
I understand that controls have no "lifetime" in ASP.NET, and therefore must be re-initialized on each and every page load. We overcome this by persisting the objects values/parameters to the ViewState.
Many articles I read therefore suggest not using PostBack since this can add considerable overhead to the Page. I am not looking for how to disable it, I know that.
What I am looking for is:
What alternatives to we have to using the PostBack model to initialize controls?
I know we could use the QueryString, but that seems awfully messy, and obviously unreliable.
Ideally you could give me an overview of the architecture/design of a different approach and the pro's/con's of it..
Many thanks ^_^
Well, Session State is a server-side solution, with its own pile of cruft to deal with if you want to avoid ViewState altogether. Really though, using ViewState in a custom control is all fine and good - just be picky about what you store - only store deltas from the declared control state, don't store anything you're going to get on postback anyway (e.g. from a DB call), etc.
You have to store the values somewhere, so you are limited to the query string and hidden form fields. If you relate that to HTTP, basically it's either GET or POST parameters.
I suppose you could use cookies, but that would be really messy.
Store your object state in the session context: this will shift the burden of keeping state from the client to the server, which may be acceptable for small-scale intranet apps. For sites on the capital-I Internet, this won't work;
AJAX-enable your control: in this case, only state changes need to be posted back. Picking the right framework is key here; see http://www.asp.net/ajax/ajaxcontroltoolkit/samples/ for the official MS approach; many others are possible.
If you're truly looking for alternatives to the PostBack model altogether, then I would suggest researching the ASP.NET MVC Framework. I would love to kick WebForms to the curb and do all my stuff in MVC, but alas, legacy code is a tarbaby and rewriting is almost never the answer, so I plug onwards...
I think you still mis-understand controls somewhat. Controls only have the problem you describe when you add them to the page dynamically. If you declare your controls upfront in the aspx code then they build along with the page.