Are there any tools for analyzing the controls in an ASP.NET page, to make sure they do not need to use the viewstate?
We are trying to optimize a website written in C# asp.net 3.5 , and wanted to see if a tool would automatically analyze the project and make recommendations.
I'm not familiar with tools specifically for analyzing the ViewState of different elements on an asp.net page.
I almost never save ViewState of table elements like DataGrid or GridView, since these element have HUGE ViewState objects that aren't neede most of the time. You need to think logically which element's state you need to save for the user.
You can also enable 'Trace' (Enabling Trace), proxy sniffer tools like Fiddler and different performance add-ons (like YSlow for FireFox) to see how much data you're sending to the server on each call and how much you're getting back, where the time is being taken up mostly, and try to see which data isn't necessary.
A good article on improving performance of an asp.net web application : http://www.dotnetfunda.com/articles/article45.aspx
The only one I know of is a FireFox extension called Viewstate size, which displays the size of the viewstate in the bottom status bar in the browser. You can see the size on the unmodified page, make some code changes and refresh the browser to see if your changes made any difference in the viewstate size.
Related
Our team is building a new web site with ASP.NET. We plan to use a 3-tier architecture. The problem is that the controls shown on the web page need to be changed all the time according to the customer's requirements, which means adding a pair of label/textbox, or removing a pair of label/dropdownlist when the customer needs it. So the layout needs to be flexible and allow to easily add or remove controls, although it just shows some simple product messages like price, discount, tax, etc.
The previous version of the web site saved all the control information in a database, like control name, control type (textbox, label, dropdownlist), which page and panel it belongs to, etc. You can see there is a big performance hit because every time there is a request to this page, it needs to get all the required controls from the database and add them to the page manually, no matter whether the request is a postback or not.
We thought about adding the controls directly to the .aspx page, but in this case it will be difficult to change them later. We also considered holding all the controls' information in XML files, which may give a little performance advantage, but it still needs to render the controls all the time.
So this is the problem we have, to improve the app's performance and also meet the users' needs at the same time. Could anyone help me with any solutions or ideas?
PS: you can also ask questions if I didn't make it clear enough. Best regards.
This sounds like a good situation for User Controls. If all you're doing is toggling child-control visibility, then creating a user control with toggleable visibility properties should meet your needs. You can still use your backend to toggle visibility, but you'll only need to pull yes/no flags from the db instead of entire page schemas.
From an architectural standpoint, User Controls are great because they encourage modularity, code reuse, and lend themselves well to version control (UsercontrolV1.cs, UserControlsV2.cs, etc). The point on version control is especially great in cases where change requests require logic updates, or simply need to revert to a build that existed x iterations ago.
Now that is what i call a Flexible web-Application.
the controls shown on the web page need to be changed all the time
Who will change the controls? The client? Can you not just update the .aspx file and publish it to the server every time a control is requested to be changed?
but any way, its an interesting question. There is nothing else really that can be done except using a XML file.
My application uses MVVM architecture and needs to occaisonally call some outside asp pages to interact with a few other systems. The problem is I that I really don't want the user to see these pages because they don't have a UI, they really just need to open in the background, perform their function, then close, all without ever being seen. I can not use windowless mode. The URL that I need the frame pointing to is generated in the viewmodel so I also need to know how to get that info to the frame. I'm really lost on this issue as there isn't much online related to doing this without windowless mode. Any help would be much appreicated.
See these two for references in how I pieced the code together for this.
Silverlight, can I access DOM elements in Webbrowser control?
http://www.davidezordan.net/blog/?p=700
Note that the only thing you can do is set the value of the url for that frame if it is in a different domain because of security reasons. That may be fine for you. So try something like:
var element = HtmlPage.Document.GetElementById("yourIframe");
element.SetAttribute("src", yourUrl);
Using ASP.NET MVC: I am caught in the middle between rendering my views on the server vs in the client (say jquery templates). I do not like the idea of mixing the two as I hear some people say. For example, some have said they will render the initial page (say a list of a bunch of comments) server side, and then when a new comment is added they use client side templating. The requirement to have the same rendering logic in two different areas of your code makes me wonder how people convince themselves it is worth it.
What are the reasons you use to decide which to use where?
How does your argument change when using ASP.NET Web Forms?
One reason that people do that is because they want their sites to get indexed by search engines but also want to have the best user experience, so are writing client code for that. You have to decide what makes sense given the constraints and goals you have. Unfortunately, what makes the most business sense won't always seem to make the most sense from a technical perspective.
One advantage to server-side rendering is that your clients don't have to use javascript in order for your pages to be functional. If you're relying on JQuery templates, you pretty much have to assume that your page won't have any content when rendered without javascript. For some people this is important.
As you say, I would prefer not to use the same rendering logic twice, since you run the risk of letting it get out of sync.
I generally prefer to just leverage partial views to generate most content server-side. Pages with straight HTML tend to render a bit faster than pages that have to be "built" after they've loaded, making the initial load a little speedier.
We've developed an event-based AJAX architecture for our application which allows us to generate a piece of content in response to the result of an action, and essentially send back any number of commands to the client-side code to say "Use the results of this rendered partial view to replace the element with ID 'X'", or "Open a new modal popup dialog with this as the content." This is beneficial because the server-side code can have a lot more control over the results of an AJAX request, without having to write client-side code to handle every contingency for every action.
On the other hand, putting the server in control like this means that the request has to return before the client-side knows what to do. If your view rendering was largely client-based, you could make something "happen" in the UI (like inserting the new comment where it goes) immediately, thereby improving the "perceived speed" of your site. Also, the internet connection is generally the real speed bottleneck of most websites, so just having less data (JSON) to send over the wire can often make things more speedy. So for elements that I want to respond very smoothly to user interaction, I often use client-side rendering.
In the past, search-engine optimization was a big issue here as well, as Jarrett Widman says. But my understanding is that most modern search engines are smart enough to evaluate the initial javascript for pages they visit, and figure out what the page would actually look like after it loads. Google even recommends the use of the "shebang" in your URLs to help them know how to index pages that are dynamically loaded by AJAX.
Got a question: how far can we go without a form being implemented around the master page in a .net project?
I hate that form tag it stops us from having multiple smaller forms and thus we cannot use an "edit-in-place" feature properly, where i dont want to send all fields, just a few of them, and an ajax solutions is all good until we hit the wall of uploading a file, DAMN uploads, DAMN .net, DAMN HTML, does anyone know a way out of this ditch?
Question on the side, how on God's earth is posting a file thru the iframe regarded MORE SECURE than sending the file in an HTTPXML object? aren't they both an HTTP request?
thank you for bearing with my temper today
There's so many places to start it's hard to pick a point.
First off, although the single form issue is enforced by regular .net web forms there are other options such as MVC. This would give you more control to emit multiple forms on the page. Just don't nest them as a number of browsers can't deal with nested forms very well.
As far as ajax, you don't have to make an ajax call back to the web form that served the page. It is pretty common to instead make several generic handlers (.ashx files) which your ajax controls post to. As an example, you might have one .ashx handler which deals simply with file uploads.
Besides separating out the functionality, generic handlers don't have to go through the entire page lifecycle to handle what amounts to a single action.
Regarding an iframe upload versus a regular upload, I've never seen anyone claim one is more secure than another. It's not. Further, some browsers (safari, I'm looking at you) have interesting issues regarding iframes so I tend to stay away from them anyway.
I got over this problem finally, i first used nested forms which is pretty ugle, it worked fine tho until i tried it on IE9 the look was broken (the behavior tho wasnt), one little small tweak and i was over it, i inserted the form tags on runtime, and IE9 didnt complain ;)
I am working on some sort of CRM application which has huge sales data with all the customer leads etc (ASP.NET 2.0/Ajax)
I want to create a dashboard which will have four separate data containers each container will have different sort of data and each container has to update it self after some configured time interval. so I want to update only that part of page not whole page
What should I used in the above scenario asp.net updatePanel or jQuery implementation (which technique and why)
Because performance is also important here.
Both ASP.NET UpdatePanel or jQuery (or a mix of both) would serve you fine on this scenario; if you don't have experience with neither, I would recommend the UpdatePanel way because it is closer to the regular ASP.NET code you're used to.
This article will get you 90% there, all you have to do at the end is to put some simple javascript in place to fire the updates every X seconds; something like window.setTimeout("Button1.click()",5000) if you want to refresh a panel every 5 seconds. If you don't want the button to be available for the users, just make it hidden via CSS.
There are more elegant approaches (using JSON, webservices, client-side templating etc) but that's an easy way to get the job done.
ASP.NET UpdatePanel is easy to set up, but in my experience terrible to debug.
Doing it yourself with jQuery (or some other JS framework) and an .NET AJAX library is more work upfront, but much easier to improve and maintain later.
UpdatePanel's traffic is a lot bigger than the JSON you'd use with your own solution, if that's a concern.
Also you can use dynamic dashboard framework and convert update panels to drag-drop widgets.
It's a browser independent web part framework for Asp.Net.