How can we disable the Control State of dynamically created controls in Asp.Net 3.5?
You can't. You can disable viewstate but not control state.
You can't, this is one of the big advantages of MVC over WebForms - you get to move away from being dependent on bloated ViewState and ControlState blocks on every page.
ControlState is used by lots of WebForms server controls - you can't disable it, but you can avoid it by writing your own ones that render their own HTML.
OK, I generally agree with Rune that you can't do it, but just a random thought:
To use control state, a control explicitly has to call
Page.RegisterRequiresControlState(this);
on Init. If the controls you add to the page do this, and you reverse it after you've added them to the Controls collection what happens? Can it be reversed?
This sounds a bit stupid, but you might explore.
Related
I have a solution that uses Accordian and tab controls, amongst others.
Is it worth swapping these out and use the jQuery controls instead?
What are the benefits? Is it best practice to load one tab at a time with data?
There are obviously benefits to using both, but in my experience if you are using ASP.NET then you are going to find the (I'm assuming you meant Ajax Control Toolkit) the ASP.NET controls better if you have a requirement for data-binding or have a high tendency to utilise your server execution time a lot.
IMO if the current controls meet your requirements then there isn't a breaking reason to switch to the jQuery controls, some ASP.NET server controls that provide Ajax functionality can be quite heavy-weight and cumbersome, but I've found controls like the Accordion to fit my needs perfectly, and wouldn't see a need to switch unless it wasn't flexible enough.
I had to make this swap in some test on my projects, from ASP.NET Ajax controls to jQuery controls, and my only issues was the UpdatePanel's.
ASP.NET take care the UpdatePanel messages (when you make asynchronous calls), but if you going to change it with jQuery you need to take care this updates by yourself - if you use UpdatePanel.
Update.
I agree with the comments for the UpdatePanel. I was working on a project, that had already many upadtePanels, and we just started to change some things to see what and how. If you build it up from the beginning I agree that it's better to avoid UpdatePanel, and do it with jQuery.
I have a couple of pages that are bulky due to the viewstate. I have following question:
is there any tool that can track viewstate of individual control on page and tell me which control is taking maxm viewstate
also can i know which controls viewstate is not being used and disable it?
There are some Viewstate Utilities listed here http://blogs.msdn.com/rextang/archive/2007/05/25/2868250.aspx. I always store Viewstate in the database rather than send it back and forth over the internet. Example Code here http://www.componentworkshop.com/blog/2009/06/27/advanced-net-storing-viewstate-in-a-database
You can turn on trace on the page and that should show how much viewstate is used for each control.
I have no good answer to your second question, but one rule of thumb I use when i develop webforms is that i set EnableViewState=false immediately after I've created an Ascx.
That way I can turn it on when I actually need it and not wonder if my databound controls uses alot of viewstate.
I have looked around on the Internet trying to answer this question. It seems to be kind of complicated though! Seems to come up with all sorts of different topics such as the HtmlHelper and other stuff.
Basically. How can you use custom controls with MVC? In a way that avoids doing anything that is frowned upon.
Also, Is it true that with MVC you have to put some simple logic IN THE PAGE? Isn't that what we should be getting away from?
Update: So, Seems you cannot use controls which depend on anything which MVC does away with, such as the postback events and viewstate. Can you make your own then? A control which does only rendering of course.
Can you use ASP.NET controls? Maybe. If the control does not use ViewState or postback events, it will probably work. For example, the LoginView control works just fine. Telerik supports ASP.NET MVC with some of their controls. On the other hand, if the control needs either ViewState or postbacks, then it just isn't going to work. Controls with data binding aren't ideal, since you typically have to use code behind him up. But they will work, if you add code behind.
On the other hand, controls with no knowledge of ASP.NET (such as the jQuery UI controls) work very well.
No, you don't have to put your logic in the page. You just don't put it on a code behind page, either. Instead, use helper methods.
With respect to the second question, the page is exactly where view logic should go. Any other logic should be in your controllers or models.
I'm not sure what you mean by custom controls. You can have ViewUserControls that are rendered via partials to reuse view code. If you are talking about 3rd part controls built for webforms, it's likely they won't work -- at least for awhile. If you absolutely must have them, though, there are ways to mix MVC with traditional webforms in the same site.
For example,
If I have a textbox with runat=server on a page, The value will be posted back to the server so I can access the properties in the code-behind.
However, under the following situations, does it still hold true?
A textbox with runat=server but does not appear in the function that is post back to. For example, a button is also on the page, when clicked a post back occurs and within the method that is raised, this textbox was not used.
Within a MasterPage, will a textbox residing on the Masterpage itself be posted back?
Because just thinking, isn't this mechanism bloated in nature?
If all input controls and its value are posted back on every single button click (even when the input control is not needed), doesn't this deteriorate performance?
Having just one Form Tag on the page really restricts us to using this mechanism?
Truly Understanding ViewState is a must read article on the subject of ASP.NET ViewState
There are several options to cut down on the bloat (and yes, there's a lot of it when dealing with lots of controls):
Use AJAX to post only the items required - although be careful to allow clients that don't have JavaScript enabled to still use the page/ site.
The MVC framework allows multiple form tags to be used so you can group sections if needs be.
Set the EnableViewState to false on pages/ controls.
Break up your pages into smaller ones.
Additionally, check out this brilliant graphical representation of the Page Life Cycle in ASP.NET.
Every input on the page is posted back fully unless you use ajax, because of the single form tag. Welcome to asp.net...
As long as the method that you're hitting on the server-side is a non-static member of the page's class, it'll have access to the textbox and all other controls on the page.
And yes, all controls rendered to the browser (whether in the MasterPage, user control, etc.) will be available on post-back.
You may want to look into Understanding ASP.NET View State.
There surely are performance hits with this architecture, but (depending on complexity of the page) it's usually not an issue from the server load perspective, because hardware upgrades are typically cheaper than additional programming hours spend on optimizing application performance.
With that said, (and as others have pointed out) look into using AJAX if you want to avoid whole page-level postbacks to the server.
Yes, it's all posted back, and yes it can cause bloat. I'm sure if you search for ViewState you will find plenty of people ranting about it and how to minimise it :)
Yes your text box will be available in both cases, yes it is bloated. This is where AJAX comes into play. Using AJAX you can send just the data you need.
If you want to send a minimal ammount of data, you could use a Page Method (static method on page decorated so the script manager builds javascript to call it or you could call it using jquery or other methods), or a script enabled web service works nice as well.
You also have viewstate which can get very large. ASP.Net MVC is a new paradigm instead of using WebForms which doesn't have view state, or post backs. It embraces HTTP instead of hidding it giving developers more control.
The textbox data would be posted back as noted. In addition to using Ajax, disabling view state greatly imporoves your page's performance though even then data in properties critical to the functioning of controls (Control state) would still be posted back.
If you didn't have postback for every control on the form, you wouldn't be able to access it in code-behind. I.e. if in your button press you wanted to modify the property of the text control you couldn't do that because ASP.Net would know nothing about the text control.
Since the communication between the server and the client is stateless and every time a page is server the server forgets all about it Postbacks are important if you want to work with the same page again. No matter what programming language you use, this or similar mechanism exists for processing server side code.
If you wish to minimize postback (viewstate size), do this.
Set enableviewstate=false on all controls that you don't want posted back.
Use AJAX and web services wherever possible (and don't use UpdatePanel).
Use HTML control as much as possible instead of ASP.Net controls.
Hmm.. There are some excellent suggestion in other answers and good links too.
You've pretty much hit the nail on the head with vanilla ASP.NET - it's not very good! In both the instances you describe the answer is yes - the textbox will be sent with the form.
The whole postback/ViewState problem is a bit of a pain, one of the first things any competent ASP.NET developer learns to do is avoid them!
We're about to start rebuilding one of our ASP.NET projects and I would like to try developing it without viestate turned on (disabled in web.config).
I know about the upsides and downsides of viewstate and generally speaking what it keeps track of in comparison to control state, however I would like to know:
What are the principle development process differences? Ie how differently do you structure your Page_Load etc?
Is there any functionality in the standard ASP.NET controls that really will just not work without viewstate turned on?
Also, are there any detailed articles on the workflow differences between working with and without VS?
If you are that against viewstate - why not try using the MVC framework? It may be an easier adjustment.
Most controls like TextBoxes and DropDownLists will function perfectly well without viewstate.
I don't know of any development process issues, other than any controls or properties created or modified through code will not persist without viewstate, so you would have to recreate/modify them on a postback.
I have some very big pages with large viewstates. I did an experiment to disable viewstate for the entire project, and found (at first) no noticeable loss of functionality. Then a few little issues came up in testing, so we reinstated it. But our 300 page web app was probably 99% functional without viewstate. The issues we had were centred around datagrids - paging mainly, and dynamically created controls and other things modified by code behind, and thus not persisted without viewstate.
This is a very good article on Viewstate:
http://msdn.microsoft.com/en-us/library/ms972976.aspx
I disable viewstate on my projects. I use scatter/gather methods to populate and get values from the aspx pages to/from my data access objects. It is a lot cleaner and simpler than using viewstate.