I know this is rather a trivial question but anyhow I want to know if it is solvable.
I have an ASP.NET webform page with a nested masterpage and JavaScript includes. I make extensive use of jQuery and Ajax calls. Once a page is loaded, all communication with the server is done with Ajax calls, so I don't need ViewState enabled, and this is resulting in a reduced HTML output code.
I now have to implement a page where a user can upload a file. So I used the AsyncFileUpload control of AjaxToolkitFileUpload. Once a file is uploaded, I do a Ajax call to the server to request the filename.
It all works fine but I noticed that FireBug found 10 errors per file upload between the OnClientUploadStarted and the OnClientUploadComplete events. The file is uploaded properly and the events on the client side are working too. But I can't ignore the fact that there are errors thrown so I went looking for the problem.
I rebuild the page piece by piece and I found out that this control needs the Viewstate enabled.
However with viewstate=disabled in the page directive the file size is 76.6kb, and with viewstate=enabled the size is 99.2kb.
Again, I know it is trivial and will not affect performance on the site, but it is a nice to know.
- Why does this control needs the viewstate? (I suppose because it actually post the file to a iFrame or something like that?)
- How can I reduce the viewstate and let this control still work properly?
For reducing view state and having this one control work properly, you can use leave view state enabled on your page and set the ViewStateMode to Disabled for the page and then set the ViewStateMode to Enabled for the one control that needs view state. For all other controls they should inherit the setting of the parent by default.
Related
I was able to setup some ASP.NET Image controls to render images from a database by using an HttpHandler.
// Notice the ImageHandler.ashx
<asp:Image ID="imgSrvcGrp" runat="server" ImageUrl='<%# DataBinder.Eval(Container.DataItem, "ServiceGroupID", "~/ImageHandler.ashx?id={0}") %>' />
It works great and was surprisingly easy to setup. My question follows...
I noticed that the HttpHandler (ImageHandler.ashx) gets hit at certain times when I don't expect it to. For example, I have a break point at the Page_Load event of the page that contains the Image tags consuming the HttpHandler and another break point in the handler itself, and I found that even though there is no postback (ie - the Page_Load break point is not hit) the handler sometimes gets hit (ie - the break point in the handler is hit).
Oddly, I found this occurs when I close a jQuery dialog on the page. I have a jQuery dialog popup on the page, and I found that when I close the jQuery popup (by clicking on the X) the image handler is hit for every image on the page that consumes it and yet no postback occurs.
The only other detail that I can think to add is my webpage is using Telerik's RadTabStrip, and it is possible that it is somehow having an effect upon this matter.
I realize that my explanation was rather long-winded, so to be more succinct with my question: Why does my image handler get hit so often even though there are no postbacks occurring?
Because loading a page resource and posting a form are different actions.
Don't think of it from an ASP.NET perspective with postbacks and Page_Load handlers and whatnot. Think of it from the perspective of the actual HTML in the browser. A "postback" is nothing more than a form being posted to a page. If you're not doing anything to trigger a form post, the page won't post back.
However, the page is hitting the server when it requests other resources. CSS files, JavaScript files, images, and so on. The resources referenced within the HTML which the page needs to load. So when a page is loaded, it doesn't just hit the server once. It hits the server to get the HTML document (this is where Page_Load for the page gets triggered), and while it renders that HTML it hits the server again and again for every resource referenced in the HTML document.
If the page is hiding/showing resources with dynamic style tweaks, then it shouldn't need to re-load those resources each time it shows them. However, if the page is doing something which causes it to have to re-render the loaded content (and that content isn't cached in the browser), then it will hit the server. This would be what causes that ASHX handler to get hit.
One suggestion for you would be to load up the page with some debugging tools (FireBug in Firefox continues to be my personal choice), and watch the actual traffic coming and going on the page (the "Net" tab in FireBug, possibly something similar in other tools.) This can help you determine exactly what is being requested and possibly what is requesting it. For example, if that RadTabStrip is for whatever reason removing img elements from the page and re-adding them, it'll request the image from the server each time.
I've always wanted to know what is, in a general way, the opinions about popups in web (I mean, those who are implemented via divs).
I've always liked not to load the user with the entire size of this popup in his navegation (when the popup is not visible). I assume that it's better load the content by demand (when the user clicks in the corresponding button). If you have five popups in one page, I always thought that the increase in 'bytes' can make a difference downloading the page.
Following the 'on demand' option I've always liked iframes because they let me change his URL via Javascript. So, I display a popup (div) which contains an iframe in wich I can change his contents downloading the page in this moment.
In my probably limited view, this method has another advantage. The validation logic (usually Asp.NET validators) are isolated in the popup page, so they don't enter in any kind of conflict with the validators located in the parent page (if applicable).
But it seems that iframes are not so well supported by some browsers and they are not too much appreciated by the community of designers (and it's a object with strong security implications).
So Basically I was wondering what are your experiences displaying these kind of UI. I know Jquery can load dynamically HTML in one div, but probably without isolating client validation scripting.
Opinions? THANKS a lot!
Firstly, you can create validation groups (http://msdn.microsoft.com/en-us/library/ms227424.aspx). That will help you with your validation problems.
You're right, you can use jQuery to dynamically load HTML as appropriate, but I'm not sure how well that works with aspx pages. There are problem a number of gotchas. Consider, you have page1.aspx and popup.aspx. If you load popup.aspx in an iFrame, you're fine, because it's a separate page. If you load it dynamically via JQuery.load() - the output of popup.aspx will load into your page1.aspx (this includes html tags, form tags, viewstate fields etc). That will likely cause some problems. (I haven't tried just guessing).
I have used .load in the past, but I tend to load standard html pages, not aspx pages. Then when the "submit" button is pressed, it calls a webservice with the relevent fields. This adds more javascript coding on my part - coding the "submit" button, coding a webservice to handle the ajax submit, coding the "wait screen" while an action is being done or data being submitted via ajax. I also have write the js to do client side validation and any code to handle server side validation and report that back to the user.
jQuery Validation plugins work well for this - or alternatively, you can instantiate .net validators if you don't want more plugins / frameworks (http://msdn.microsoft.com/en-us/library/yb52a4x0.aspx)
my web site structure is like this :
1- master page with stylesheet and scripts
2- aspx which render (number 3)
3- web user control and scripts inside them
in the number 3 I have some javascript that are call some ajax method they are about 20 lines code and I can not move them to js file in order to using <%= myAspControl.ClientID %> for some purpose
my default.aspx is so heavily now I checked it by google chrome developer tools it is equal to 2.7MB for document only document not images or style sheet.
I have about ten controls but I think it is effect on viewstate and encoding them it creates all in default.aspx dynamicly and make it so heavy.
Have you read these SO-suggestions to minimize ViewState?
That seems like poor ViewState use. I saw it in a project with some Telerik controls, which had a feature that stored the whole data source in the ViewState / which included more than was being displayed.
Keep the ViewState to what's absolutely necessary. Don't try any clever workaround, you should never store large amount of info in the view state.
I have a DataGrid control that refuses to reload itself from View State on Postback. I've traced this all the way back to the Load event on the control. It just flat refuses to reload from ViewState. It just doesn't do it.
The control is situated like this:
Webform
--> Dynamically loaded User Control (via "LoadControl")
----> Statically placed User Control
------> DataGrid
Yes, I know it's a little convoluted, but all the other controls on the page are reloading themselves, except for this DataGrid.
I've tried all the usual suspects --
The Control Tree is the same on page load and postback.
I've tried setting TrackViewState as well. That didn't do anything either.
Now, this is the weird part: this worked fine, then broke. I've gone back through Subversion and reviewed all the code changes for the last month, and there's nothing that would have changed this.
This makes me wonder if this can behavior somehow be affected from some external variable -- something external to the code. Is there some setting or something that might change how this behaves?
Are you hitting the issue where the control isn't actually present when its doing the load from ViewState? http://msdn.microsoft.com/en-us/library/ms178472.aspx
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!