What is page object in terms of asp.net?
Please give me some information:
How can we use it in asp.net?
and
Why we are using it?
I tried to search on the internet but couldn't find a proper answer that I could easily understand.
ASP.Net WebForms, like other web platforms, is still in the business of generating responses to http requests.
When a user visits a page on your site, the web server (IIS) receives the request. Because your site has a handler set up in a certain way (by default this is done for you automatically), IIS determines that this request will be processed by the ASP.Net runtime. The ASP.Net runtime then looks up what page you requested, and uses that information to create a new page object for this request.
It's worth noting at this point that you get a new page object even if the request is just a postback to the same page the user just visited. This page object only lasts for the life of this one request, and will be discarded when the request is complete, even though the user might still be interacting with the page on their browser. A new postback will generate a new page object. A lot of people have trouble wrapping their heads around this.
Once the page object is created, the ASP.Net runtime goes through a process called the Page Lifecycle. This involves steps like loading View State, loading the Session, binding to data sources, and raising user events. Between each of the stages, an event (such as Page Load) is raised that allows you to run any custom code you want to run at this particular point in the life cycle.
At the end of the life cycle, the html result for this page is transmitted to the browser, so it can be shown to the user. At this point the page object is destroyed, and the worker thread in IIS is free to handle another request.
Related
I have inherited textbox and dropdownlist controls in C# and added some custom logic to them for setting background and all in C#
I am adding them to my user control(ascx) and using this usercontrol in aspx page. But On postback I lose values for all textboxes dropdown etc.
Can anyone help.
That's just the way it works, and it's worse than you think. It's not that your control is losing it's data. It's that it's not even same instance of the control any more.
In ASP.Net, you work with a completely new instance of your page class, including any controls in the class, on every postback. There is a page lifecycle you need to understand before you'll be able to do much, but the summary goes like this:
User sends an http request for a page via the browser
ASP.Net runtime in IIS creates an instance of the page and calls methods like Pre_Init, Load, Render, etc in a specific order.
The result of this process is then used to send an http response to the user's browser with the rendered html.
Once the response is sent, the page class instance is disposed and destroyed. It no longer exists.
The browser receives the http response and renders the page for the user.
If the user does anything that causes a postback, the entire process starts again. It's a whole new http request, a whole new page class, and a whole new http response. Things like calling the page's Load method are repeated. Also note the order for steps 4 and 5. Due to latency between the browser and web server, it's common that the page class is already destroyed before the response even reaches the user. By the time the user sees a page, the class instance that produced the page is already long gone.
To get around this, you need to put data that should persist across requests into a storage location that will actually persist, such as ViewState or the Session.
Is it possible to have results from another page returned to a JavaScript method or a C# controller action?
I have a shared complex page that's used all over my website that's currently used to set a single variable on the user data in the C# back end. When the user has finished the shared complex page, I return to the referring page. The page that I've returned to contains the newly selected variable when the user returns as it's refreshed or alternatively passed as a url parameter to the returning page.
I have a new page where I'd like the variable from my shared complex page to be returned. However there will be multiple instances of this variable on the page and they're actually different data to the previously stored single variable on the user data in the C# back end. i.e. I'd like to have several buttons on the page that lead to my shared complex page and when the user returns the data for each button will be displayed next to the button.
Is there a way in JavaScript or C# to display another page and have the result returned to the method that instantiated the display of the page? If my back end was implemented in scheme I'd use a continuation to achieve this result. Is there any equivalent in C#? I've been looking at async tasks in C# but none of the examples show a user interacting with another page as part of the asynchronous operation. Is this possible?
If not I'll have to pass the value back to the new page via URL parameters. I would like to avoid this because of the amount of contextual data I'd need to pass between the two pages. I'd thought of using a redirect from the shared complex page to update the new data on the back end before returning to the new page to solve half the problem but this site works on mobile so the network latencies rule out redirects. Also having the complex shared page as a pop up dialog within the new page won't really work as it's a) complex b) the new page can be used a pop up on an existing page and having a pop up from a pop up is unsupported on Bootstrap.
The sharing of data between web pages, without an established continuation medium, requires the use of a shared state somewhere, like session variables or cookies. As each page changes the state, it can go back to the server, update that session, and when the process is done, you'd read that session via ajax and complete your process.
I understand that Server.Transfer doesn't make a round trip back to the requesting client.
What I haven't been able to learn is if control is simply passed directly to the new request handler you're transferring to or if or if the entire request life-cycle is executed again.
I assume the entire life-cycle is executed again using the transfer URL but wanted to verify this was the case.
Here is what I found through experimentation.
When using Server.Transfer the entire request life cycle is not ran again.
If you write your own Module, hook it into the request life cycle, and call Server.Transfer from that module the rest of the request life cycle will be skipped and the page life cycle will begin immediately.
After completing the transfer page life cycle the request life cycle picks back up with its tear-down events. Note, the HtppContext in for the tear-down events will be the original one you transferred from. That is, the URL and QueryString values will be the same as the original request and not be the URL and QueryString values for the page you transferred to.
Server.Transfer does modify the HttpContext.Request object to contain the new URL and QueryString information during the page life cycle for the page you transferred to.
If you transfer to a resource that is not a page but is text based (e.g. something.xml) the content of that page will be returned exactly as is with its encoding set to text/html.
If you transfer to a resource that is not a page and is not text based (e.g. something.pdf) then an HttpException error will be thrown. This happens even if you have defined a custom Handler for this resource.
It's just passed along, with its state intact. The request lifecycle does not get run again, although the page lifecycle will run for the page you're transferring to.
http://msdn.microsoft.com/en-us/library/ms525800(v=vs.90).aspx
Server.Transfer acts as an efficient replacement for the Response.Redirect method. Response.Redirect specifies to the browser to request a different page. Because a redirect forces a new page request, the browser makes two requests to the Web server, so the Web server handles an extra request. IIS 5.0 introduced a new function, Server.Transfer, which transfers execution to a different ASP page on the server. This avoids the extra request, resulting in better overall system performance, as well as a better user experience.
This link is also helpful -
http://www.developer.com/net/asp/article.php/3299641/ServerTransfer-Vs-ResponseRedirect.htm
I’m building an asp.net web application; I’m using an http handler as a filter, because I want the user to be redirected to a certain page if a condition is true. Problem is if the condition is false the page doesn’t load because the http handlers kill the life cycle of the page itself…so, is there any way to avoid this and to load the page properly or am I supposed to use another object to filter?
A handler, as its name suggests, must completely handle the request. If you want every request to be examined and filtered, you want to use an HttpModule.
A good 'getting started' guide can be found here.
I've the following doubt. I've a page "MyPage" and i've declared few dictionary objects in the page class.
My doubt is
If i declare the dictionary as a private non-static object i'm not able to use it across the functions in that page class (the object is getting nulled)
But if i declare the dictionary to be static i'm able to across the object across the functions. But will that object be same across all the users who have opened the page right now (guessing that each user will have an instance of the page in turn has an instance for the page class and static variables of a class are invariable across all the instances of the class)
Is my understanding right? How to declare the object to be available across all the functions within the page class and unique for each instance of the page (user).
Update1
Okie, i find that the initialization of the dictionary object in the page class is done in a different thread (WCF Duplex callback). But in the main page thread the dictionary object is still remaining as null (uninitialized). Any ideas?
Update2
Marshalling - useful by any chance?
Update3
In reply to John-
Thanks for your reply. The problem i'm facing now is to pass the data from the WCF callback class at the client side(which will be invoked in a separate thread) to the asp.net page. So how can i do that? View state may help me to persist the data across requests. But when the callback is invoked by the server notifying for a change how should i pass the changes (data) to the UI thread (asp.net page)?
Don't do things like this.
If you need to maintain data between pages, use Session state. That's what it's for. You should remember that you get a new instance of your page class on every request. Do not use statics to keep changing data around for subsequent requests. You will probably get into trouble with multiple requests updating the data at the same time.
You can't do things like this with ASP.NET!
You seem to be treating this as though it were a desktop program - as though your class instance and all state will still be there for you next time you execute a method on the page. That's not true - when the request is complete, your page will be Disposed. Nothing about the page will remain valid.
In particular, if the callback doesn't happen before the request ends, then the callback method had better not reference anything having to do with the request, like your page. That's because the callback might fire after the request is already over! The state is corrupt or worse.
Unless you are going to have the page wait for the callback, you'd really better not use them in your pages. Instead, create a separate Windows Service or something and have it issue the requests and await the callback. The page can then use Ajax or something to ask if the request is complete, and to get the response once complete.
If you think you heard me say to call back to an ASP.NET page, then you misunderstood.
Create a Windows Service. Your Windows Service will host a WCF service that the ASP.NET application will talk to. The WCF Service will keep track of things like who's joined a chat, who's typing, etc.
The web application cannot be notified when something interesting happens. Instead, the web application will have to poll the WCF service, asking if anything interesting has happened. When something happens, the WCF service will pass the "something" back to the ASP.NET application (or possibly, back to the page, called by AJAX).
I misspoke earlier. You simply cannot use a callback contract at all in this situation. It's not like the web pages are like a desktop application, one per user, waiting to be notified. They're more like a desktop application where, when the user makes a request, you take his PC and give him a new one just like it, before the response arrives.
You are right in the second case. In your first case I'm guessing you mean that if a user clicks multiple controls on your page then the event handlers are seeing that the dictionary is null (instead of having the result from the previous event handler).
Remember that every request on a page (even from the same user) creates a new instance of your page class. That means that each time a request starts, your dictionary will be null. The only way for a variable to maintain its value between subsequent requests is to persist it server-side (for example, in user-specific session information on the server) or to push it to the client with the page content so that it can be part of the subsequent request data (so it's stored in ViewState or other storage at the client's browser between requests).
Rereading this question, there are three seperate state machines, and none of them are being coupled together - hence the problem :)
State of the "user state" - these are the key/value pairs in the dictionary, their lifetime spans multiple page requests and callbacks
State of a "page", which needs to consume the data from "user state". Pages are destroyed after each and every page request.
State of the "service call" which needs to populate the data in "user state" Service calls are generally destroyed after each invocation.
There are a few strategies that could enable you to couple the systems:
ViewState such that the state machine for "user state" is sent down as part of the state of the page, and sent back on postbacks. This may constrain how you perform service callbacks
Session such that the state machine for "user state" is stored server side, and can be accessed by key.
Static dictionary of user states, where the key for the outer dictionary would be the identity of the "user state", where the 1st page request would create the "user state" entry, and you'd need to manage teardown. (v.similar to session - though works without ASP.NET).
There are lots of nuances to each solution - I'd advise light reading :)
you are right that a static member will be the same for all instances of the page, and thus all individual users. You need to make it a non-static member if you want to access it from every method in the class. You should look into why the object is null. Are you properly instantiating it at the proper time?