I have an ASP.NET page with one control (.ascx) on it. The page (.aspx) onload assigns some text to a couple labels and passes a product ID to the .ascx control. The .ascx control, onload, takes that product ID from the .aspx page and hits the database several times, does several calculations, etc - basically takes a long time to load.
So when I'm clicking a link to this .aspx page, it is taking 7-10 seconds for the page to load. I've narrowed it down to the calculations on the .ascx control being the culprit and I've optimized the code as much as I can ... but it's still taking too long.
Is there a way to load the .aspx page BEFORE the control loads? (Maybe display a "Loading..." animation? Like used in an UpdateProgress?)
You could do this with an UpdatePanel. It will take a little trickery, but try something like this:
1) Put the UserControl in an UpdatePanel.
2) Put a public property on your usercontrol like IsEnabled that it will use to conditionally do nothing or render a "please wait." Set it false from your main page.
3) Add some code in OnInit to your main page:
if (MyScriptManager.IsInAsyncPostback) {
MyUserControl.IsEnabled=true;
}
4) Add a client script along these lines:
finished=false;
Sys.WebForms.PageRequestManager.pageLoaded(function(sender,args) {
if (!finished) {
finished=true;
__doPostBack('','');
// you can include the uniqueID of your updatepanel as the first arg
// otherwise it will refresh all update panels
}
});
or with jquery..
finished=false;
$(document).ready(function() {
if (!finished) {...
}
});
What this should do is cause an async postback to be initiated immediately after the page is done loading, which will in turn cause the update panel to be refreshed. Since you set it to be enabled when it's in an async postback, it will render itself the 2nd time.
The only possible way to achieve this is by setting it up as a separate HTTP resource. At the moment .NET is integrating the control into the page so that it is waiting unti it has everything it needs to respond.
You could do this a multitude of different ways:
Web Service that gets called via javascript
Seperate page which contains the control (and is hosted within an iFrame to appear to be on the same page)
The best way to do this would be to use an iFrame (or something similar) which will instruct the browser to request the control after the main page has been sent).
Personally, I would never use an iFrame to load content on a page - that's more like a hack than anything and plus, iframe == "bad".
But they are right, you won't be able to do anything like what you're looking for.
If the user control DOES NOT have any web controls that cause a postback (or have any form controls that you need to access during a postback), then I would use AJAX to request the data on the server after the page has already loaded and use javascript to display the content on the page.
Related
I am working on a legacy service that has 30 aspx pages with years of business logic
There is a parent aspx page which acts as a base page that the above aspx pages inherit from.
I need to add a Response header and I am having trouble finding the right place to add it to the ParentPage.aspx.cs so that it gets applied to all aspx pages.
Ideally I would want to add after PageLoad() is done for the the data to be available to add to the header.
I tried using the onPreRender() and onLoadComplete() stages to add the header. But it is not guaranteed that this would get called because the aspx pages have logic that do Response.Redirect() Because of the redirect onPreRender() and onLoadComplete() do not get called. I would not be able to change the logic on redirects
However UnLoad() does get called all the time. But response cannot be altered in the UnLoad() stage
Are there any suggestions where the header to the response could be added in the ParentPage.aspx.cs ?
Do you have a master page?
Just drop in the code to add a header in the page load event.
I mean, code can fill out text boxes, change things, and then you can toss in a new header - the order of such events don't matter.
So, if you have a master page that all pages use?
Then do this in site master:
protected void Page_Load(object sender, EventArgs e)
{
Response.AddHeader("Test", "My Test Value");
}
So, it not clear if you have a master page, but page load triggers in site master each time any navigate to any page occurs. And also the above runs each time any post-back or button click occurs on any page.
So, just add the header in the page load in master.
The above thus results in this:
So, it don't matter if you add the header at the start of code, or end of code say in a page. The other code behind can run, make changes to the "DOM" via code behind, but everything WAITS 100% until ALL of the code behind is done running, and THEN and only THEN does the WHOLE page make the trip back down to the client side, the client side re-loads the page, re-starts any JavaScript code (and re-sets, all JavaScript values and variable to fresh start), and then the page life cycle is complete, ready to start again on the next button click etc. And on the server side, the page class is disposed, and all its variables etc. also goes out of scope (hence the term state-less). So, both ends, including client side js code variables are re-set in this process.
So, in fact the "order" or what event you use to inject/add that header? it really don't matter when it runs, only as long as it runs at "some point" in time during that whole page life cycle on the server.
In fact, what I am saying, it is REALLY hard to mess this up, since just about any event can add the header - but page load looks to be as good as any event here.
Edit: The page load event
You thus should see/be able to add the event to page master like this:
I have the following case:
Page1.aspx this page has the master page master.aspx.
I have some code in the master page :
if (!Page.IsPostBack)
{
adjustServiceBar();
}
when i click any button in the Page1.aspxit enters the !Page.IsPostBack and execute the method !!
i want this method in the !Page.IsPostBack) only
One way to do this is to set a session variable and then check that variable to ensure your code will fire only once.
Another way is to set a hidden control on your form and play with its text or value property.
According to each scenario the solution may be very complex such as custom derived masterpages and pages that extend the current events functionality to suit your needs.
I believe it is more consistent to check for IsPostBack in content page. You can move this condition to Page1.aspx and expose adjustServiceBar() method in your master page, so that content pages can call it, like Master.adjustServiceBar().
The Scenario: I have an asp.net website where I show a div popup on page load for taking a few user details. When a user inputs the details, or closes the popup, I set up a flag cookie so that the popup is not displayed again for the user. The div is in the MasterPage so that it is displayed no matter on which page a user lands first time. The div contains an UpdatePanel which has all the controls required for taking the details. This whole functionality is working fine.
The Problem: Now this div popup is not showing(by setting display:none) on subsequent postbacks(which I want), but the html markup is still loading with the page unnecessarily adding to the page size. What I would idealy want to do is: Check if flag cookie is set. If no, show the popup, else remove the popup's markup from the page.
Now since the div is not a server control, I cannot possibly remove it and the all the controls inside it. So, I thought of removing the UpdatePanel from the page:
protected void Page_Load(object sender, EventArgs e)
{
if (Request.Cookies["flag"] != null)
{
if (Page.Controls.Contains(updpnl_contact))
{
Page.Controls.Remove(updpnl_contact);
updpnl_contact.Dispose();
}
}
}
But I guess this tends to work with dynamically added controls only, and since the control is added at Design Time, it is not being removed.
Is there any way I can achieve this?
If you add a runat="server" attribute to your <div> element, it will be available in the code-behind. You'll need an id on it as well. Then you can just toggle the Visible property. If this property is false, the control won't be rendered to the client (i.e. no HTML markup).
What you're trying to do is not at all the usual workflow. I tend to think that it will not work as it would mess up control tree, maybe even corrupt the viewstate and so on.
As a possible solution, you can put it's visibility to hidden in the code behind. This, in the contrary to the usual 'gut feeling', doesn't work like the css propery 'display:none' for example - instead the control will not even be rendered into the page when it's not visible. This may be the workaround for you.
Happy coding.
A more efficient approach would be to create the panel as a UserControl and load it dynamically in codebehind when it's needed, then add it to your page. E.g, in code:
MyPopupControl popup = (MyPopupControl)Page.LoadControl("/path/to/usercontrol.ascx");
PopupPanel.Controls.Add(popup);
Where PopupPanel is an empty <asp:Panel>. Then, not even the markup will need to be loaded/processed except when its needed.
There is no reason that all the code you use to display and process this panel couldn't also be in the usercontrol, isolating it from the master page.
Can you build the panel dynamically, based on the cookie setting?
I have a menu usercontrol called LeftMenu that has a bulletedlist of linkitems. It's on the ascx page as such:
<asp:BulletedList ID="PublisherList" DisplayMode="LinkButton" OnClick="PublisherList_Click" cssClass="Menu" runat="server"></asp:BulletedList>
I databind the list in the page_load under if(!isPostBack)
I'm having an issue on a page that loads the control. When the page first loads, the event handler fires. However, when the page posts back it no longer fires and in IE8, when I'm debugging, I get "Microsoft JScript runtime error: Object expected" in Visual Studio pointing at "__doPostBack('LeftMenu$PublisherList','0')." In FF I don't get the error, but nothing happens. I'm not loading the control dynamically, it's loaded on the aspx page using:
<%# Register TagPrefix="Standards" TagName="LeftMenu" Src="LeftMenu.ascx" %>
<Standards:LeftMenu ID="LeftMenu" runat="server"/>
Any ideas of where I'm losing the event handler?
I just realized this is happening on another user control I have as well. A text box and a button and I'm using the default button to make sure pressing the enter key uses that button. .Net converts that in the html to:
<div id="SearchBarInclude_SearchBar" onkeypress="javascript:return WebForm_FireDefaultButton(event, 'SearchBarInclude_QuickSearchButton')">
so as soon as i enter a key in the box I get a javascript error at the line saying "object expected." It seems like the two issues are related.
Edit Again: I think I need to clarify. It's not that I'm clicking on the menu item and it can't find the selected item on postback. I have this search page with the left navigation on it and then the main content of the page is something that causes a postback. Everything is fine with this postback. Once that page has been posted back, now if I click on the bulleted list in the left navigation I get a javascript error and it fails. The page_init for the LeftMenu control is never called.
It sounds like you might be losing the click because you are not DataBinding the list on PostBack. Therefore, the post back is trying to refer to a control (a specific bulleted list item) that does not exist.
You should try binding the list again on PostBack just to see if that fixes your issue. BUT, what should REALLY happen is that the LeftMenu and the BulletedList should store their information into ViewState so that you can ensure that the data that was shown to the user on their initial page load is the same data that the PostBack is processing and working with.
If you have EnableViewState=true for your UserControl and all controls within it, everything should work fine. With ViewState enabled, ASP will reinflate your controls from ViewState after Init has fired. This means that the postback event arg (which points to an index in your control list) will still find the control in that list position. Otherwise the list is empty on postback.
However, ViewState is the work of the devil and was designed simply to foster the illusion that you are working in a stateful environment. It is okay to use it for small amounts of data but typically not advisable for templated controls like repeaters and lists because you have no idea how much data is going to be created in ViewState.
If you are dealing with static, or relatively static data, store it in the application cache and rebind your lists in Page.Init every time (note that it has to be in Init because post-init is when ASP rebinds from ViewState; if you get in there first, your data will be used instead).
If you are dealing with volatile data, you have a problem because the data you rebind must be exactly the same as the original page request, otherwise the postback events will be firing against the wrong rows. In that case you need to either store your initial data in Session or you simply store the list of rows ids (in a hidden variable or Session) and you recreate the data to bind against from the ids each time.
An even better solution is to not use postback events at all. Try to turn all your events into GETs that have an ID on the query string. You can still create the list using binding the first time through the page (as you are currently doing), and you can even GET the same page with a new ID.
If you need to keep state on the same page but need to respond to the user changing a radio button selection (or something else), think about using Ajax calls to update the screen. You also do that with an ID that you pass to the Ajax call.
In general, the more you move from using stateful ASP, the lighter and more responsive your pages will become. You will also be in a better position to move to stateless MVC if necessary. You will also save lots of time lost to debugging obscure problems because ViewState is not available when you need it to be.
The best analysis of ViewState I've read is in the link below. If you fully understand how it works, you can continue to use it without necessarily incurring the costs.
http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/truly-understanding-viewstate.aspx
It's possible that this might be javascript related, and that a script that is loading earlier in the page is throwing an error and causing the page to not be loaded properly.
Are your usercontrols loading any javascript onto the page? Can you check for javascript errors on the initial load of the page?
I moved the code into an existing project we have and for some strange reason, I stopped getting the javascript errors and instead got:
"Invalid postback or callback argument. Event validation is enabled using <pages enableEventValidation="true"/> in configuration or <%# Page EnableEventValidation="true" %> in a page.
For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation."
I haven't quite figured out where I'm supposed to put the register event validation with a user control, but in the mean time I just set enableeventvalidation=false and it seems to work now.
It looks like the doPostBack function is missing since its arguments are literals so they couldn't be the cause. Is that one of your own functions or did you mean to call the ASP __doPostBack function?
Have a look at the Firefox error console or allow script debugging in IE and see exactly what object can't be found. Even better, download Firebug and debug it.
I had a similar issue. It turned out that Akamai was modifying the user-agent string because an setting was being applied that was not needed.
This meant that some .NET controls did not render __doPostBack code properly. This issue has been blogged here.
I am using jQuery to simulate a popup, where the user will select a series of filters, which I hope to use to rebind a ListView in the original window.
The "popup" is opened via an ajax request and the content is actually a diferent aspx file (the rendered output is injected into a div that acts as the popup).
I have another ListView in this popup, and it has pagination.
My problem is that since the popup is in reality html content inside a div in the same page, when I try to paginate, the whole page postbacks and is replaced with the aspx that has the filters.
How can I fix this?
I tried using an update panel to contain the ListView but it didn't work.
$("div.yourthingie").hide();
Will hide the part you want to show :) Instead of generating the popup on the fly, leave a small part already made, and hide it in the begining, when you need to show, unhide and add the information you need to.
Hope it helps
Either get rid of the HTML "crust" and just produce the <div> with its contents, or use an IFRAME.
First, let's think through what is happening. When you submit the original page, you are taking a "normal" Request/Response trip to get the code. On the page is a JQuery AJAX bit that fires off what is essentially a modal dialog. The desired effect is the user plays with the new page until they have figured out their filters and submits back. The problem is this "modal page" loses information when someone paginates.
The solution to this is fairly simple, in theory. You have to store the "filters" in the popped up page so they can be resent, along with pagination information. OR you have to cache the result set while the user paginates.
What I would do to solve this is create a static page that has the "filters" in place and work out the AJAX kinks separate from having the page post back to a parent page. Once you have all of the AJAX bits working properly, I would then link it into the popup routine and make sure the pagination is still non-problematic. THe final problem is creating a JavaScript routine that sends back to the parent page and allows the parent page to send its JQuery bits back to the server.
I am not sure about the HTML DIV part of the equation and I think you can solve the problem without this solution. In fact, I believe you can make the "modal popup" page without invoking AJAX, if it is possible to either a) submit the filters to apply via the querystring or b) fake a form submit to the second page. The query string is an easier option, but it exposes some info. Faking a form submit is not that difficult, overall, but could be problematic with a popup.
I am just firing off some ideas, but I hope it spurs something for you.