In terms of performance. Is it a good idea to build your own data grid (assuming you have the time) having in mind that you will create one that match perfectly your need? Getting rid of many unnecessary properties and methods. The rendered page might be smaller making the download faster?
thanks
The properties and methods of a server control have no direct relationship with the size of the rendered HTML. Simply removing methods won't make the slightest difference in the size of your download. In my experience, the .NET controls work well enough. If you encounter a performance problem, you can always drop in a different implementation later.
As ASP.NET already includes the Repeater control and the DataList control, both of which allow you to specify the HTML output of the control, there is little need to create a new control for performance reasons.
Related
Sorry in advance if this is not the right place to ask this.
I have a task of making a asp.net site into responsive. The site consists of various ASP.NET controls as well as Telerik ones. The problem is that the designs that i have for the mobile view do not comply with the current structure of site, so in many occasions i have to put the same control twice in the same page, and the hiding/showing depending on the width of the screen.
So i did my research and found that only unique IDs are permitted in same page. Is there any alternative to have the same control twice in same page?
No, there isn't. Controls' IDs must be unique.
Perhaps wrapping them in user control instances and using those a few times over and exposing public properties for what you need is one approach.
Consider using tools like RadPageLayout that help you hide/move unwanted controls/pieces of the page: http://docs.telerik.com/devtools/aspnet-ajax/controls/pagelayout/overview.
Or, create helper methods that get the needed user input/control depending on what is visible or not. These could even be properties in your page that return the currently visible control so you can set properties, data sources, get input, etc. With this you will reference the duplicated controls via this property rather then via their instance ID. Tough to maintain, but without completely redesigning your page and needing duplicates I am not sure there is much else you can do.
I am using ASP.NET 4.0 WebForms. I am also using master pages which inherit from other master pages. I have controls inside panels. Basically there are multilevel containers. This is causing elements to have HUGE ID's. I am seeing ID's about 300 bytes long!
When there are hundreds of elements in a page, these ID's increase the page's size dramatically. I have a GridView with binding controls.
What is the best way to have each server control have the shortest ID possible? Is there a way to have each element not be dependent on its container (other than ClientIDMode="static") ID even if but still be unique in the page? Last, does ASP.NET MVC alleviate this issue?
I would suggest changing the ClientIdMode to either Predictable or Static in order to see if that produces shorter ID's.
Further to that this CodeProject article appears to achieve what you need.
MVC absolutely alleviate this issue because there is no server side rendering of html code in the same manner. All of your html is directly in your views so you have full control over every item. You also run the risk (in the case of a page that has hundreds of inputs) of colliding inputs.
One way you can help shorten all the html produced in WebForms is to remove anything that is not absolutely necessary to be a webusercontrol. For instance, most labels are static. They can replaced normally with standard text or items that don't include the runat="server" attribute. This will prevent ids from being generated in the first place. Another way to reduce the amount of junk that gets generated is to remove as many controls as you can from the ViewState. This will prevent them from loading their state data and keep the ViewState shorter.
ClientIDMode is an inheritable property so you can set it in the web.config (global), web.config (local) or page level. You could also use it individually. Your question specifically eliminates this, but it would probably be the best option with the most flexibility without rewriting what you already have. If rewriting is not an issue, I'd recommend using MVC.
I think ClientIDMode=static is in one of the way. YOu can set this in your web.conf also. And in Asp.Net mvc, you have the full conrol over html (especially in Razor). There is no such thinks like webforms. You have control over assigning ids to html tags. Infact Asp.Net mvc is answer to all other frameworks.
Last, does ASP.NET MVC alleviate this issue?
Yes.
There is no ViewState in MVC and you are not running any controls on the server.
You are not using any server controls which generate tons of hard to read HTML.
You have complete control over ClientID's in MVC.
Click
The above markup will always have the id of myID unless I change it myself.
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'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.