I have the following use case:
A user can filter on my asp.net web project for some data and request the result as PDF. The PDF is generated per request new and returned to the user. I got already everything to run.
But: the processing can take up to two minutes and the user should be able to continue to use the page.
I tried to use a second tab, but both tabs are blocked. Even when I use the PageAsyncTask class and the async attribute. When I use a thread to perform the request, I am truly parallel, but I have no clue, how to interact with the user from inside the thread when the work is done.
How can I send an async request to the server and just get the result on the page, in whatever form, when its finished?
Dave Encosia does a great job explaining how you can do this:
Using jQuery to directly call ASP.NET AJAX page
methods
Using jQuery to Consume ASP.NET JSON Web
Services
3 mistakes to avoid when using jQuery with ASP.NET
AJAX
Related
I need to check some stuff (Cookies) for each request coming to my application.
In ASP.NET we've used HttpModule for this task , the question what should be used in MVC ? Some Global Filter , or I can Use HttpModuler as well, is there Any difference in Request PipeLine between MVC and regular ASP.NET ?
MVC is an abstraction over ASP.NET and therefore their "hooks" really depend at which level you want to inject your logic. An action filter will allow you to hook into MVC specific events:
OnActionExecuting – This method is called before a controller action is executed.
OnActionExecuted – This method is called after a controller action is executed.
OnResultExecuting – This method is called before a controller action result is executed.
OnResultExecuted – This method is called after a controller action result is executed.
Whereas an HttpModule only allows you to hook into ASP.NET (upon which MVC is built) specific events:
BeginRequest - Request has been started. If you need to do something at the beginning of a request (for example, display advertisement banners at the top of each page), synchronize this event.
AuthenticateRequest - If you want to plug in your own custom authentication scheme (for example, look up a user against a database to validate the password), build a module that synchronizes this event and authenticates the user in a way that you want to.
AuthorizeRequest - This event is used internally to implement authorization mechanisms (for example, to store your access control lists (ACLs) in a database rather than in the file system). Although you can override this event, there are not many good reasons to do so.
PreRequestHandlerExecute - This event occurs before the HTTP handler is executed.
PostRequestHandlerExecute - This event occurs after the HTTP handler is executed.
EndRequest - Request has been completed. You may want to build a debugging module that gathers information throughout the request and then writes the information to the page.
So it really depends on when you need to hook in your event and which events you need.
If the HttpModule worked well for you before then it will continue to with Mvc.
The other parts of your question are quite broad in scope and think you'd be as well reading a good article on asp.net-mvc pipeline and extensibility.
I've done similar things using a global action filter. It works quite well, and keeps your code integrated within your application.
An HTTP module works as well, of course, but this will mean seperating the code from your main application and maintaining it seperately. Unless your code spans multiple sites or is used in multiple applications, or needs to work with web forms sites, then I would use a global filter.
The knowledge I have about UpdatePanel is
They use Ajax requests to work asynchronously.
They perform a partial postback.
Now recently I was working on Ajax requests too using $.ajax() method of jQuery when I found some difference about Ajax requests made by me and Ajax requests made by UpdatePanel which are
UpdatePanel's Ajax request perform full page life cycle but my Ajax request calls only that particular method which I have supplied to be called.
Methods called by UpdatePanel doesn't need to be tagged as WebMethod but methods called by my Ajax request has to be WebMethod.
I searched web to get details about these differences but doesn't found any resource, Can someone tell me whats the difference between Ajax calls made by me and by UpdatePanel or more specifically hows those differences made and what special tricks are played by UpdatePanel to achieve that functionality ?
I liked this question mate +1
Basically the evil UpdatePanel is the root of all evil. Sadly it is =(. The update panel behind the scenes raises async postbacks to the server, but to fully understand what happens, you need to understand the UpdatePanel goal
The UpdatePanel was designed to work with the ASP.Net web forms, these controls have to go through the whoooole ASP.Net page life-cycle in order to work correctly, therefore, they need the whoooole page ViewState. So every time you perform a post back using an UpdatePanel the whole page viewstate will be sent to the server back and forth even when you only want to partial render a small part of your page.... sucks. Why did Microsoft created this monster? I think it was because back 5-6 years ago (or more) AJAX was not so popular as it is today. Another reason is that Microsoft wanted to provide a framework to write AJAX calls in a simple way, but without losing the power of the web controls.
So with this in mind, the difference between an UpdatePanel and an AJAX call, is simply:
The AJAX call sends only the data needed by the server method and it returns just the required data. The performance of using pure AJAX calls is impressive.
but methods called by my Ajax request has to be WebMethod.
That's partially true, I mean there are different ways to expose methods from the server:
Using traditional Web Services - Script services (ASMX)
Using PageMethods (static methods on your ASPX pages)
Exposing WCF services
Exposing WCF REST services
Using WEB API
Using MVC controller's actions
Using custom HttpHandlers returning a specific content type like JSON
etc
At the end the result is the same, no matter what approach you use to expose server methods when consuming them with pure AJAX calls you will have to face the following if you are using web forms:
If you want to use pure AJAX calls, then you should consider moving to MVC because in web forms you will lose the power of the web controls, in other words your development would be more difficult
They perform a partial postback.
No, update panels perform a full postback, they just perform a partial update on the page.
UpdatePanel's Ajax request perform full page life cycle but my Ajax request calls only that particular method which I have supplied to be called.
Precisely, the Update panel performs a full postback. Highly inefficient.
I am building a search page in asp.net 3.5. Search takes a bit of time (few seconds to few minutes). Current I use AsyncMethodCaller to call Search method. AsyncMethodCaller method stores search results in Session. I user Ajax timer to check if Search method finished and then display results.
What would be the best way to implement this scenario?
I would use a Page Method from the ASP.NET Ajax Framework. It's easy to call them async and you have a callback when it's done.
Have a look here. (Async is explained at the commens of the post)
You could try the reactive extensions for .NET . I haven't tried them yet, but looks promising.
That seems perfectly fine to me, or have I missed the point of the question?
I did a similar thing recently in a PHP front-end with a search that takes about 30 seconds.
I implemented the actual search logic as a console application. The web service calls the console application to carry out the search and records the process ID of the application handling the search in the session.
An AJAX timer in the front-end polls the server every second, which checks if that process ID is still running. If it's finished, it looks in the database (where the application writes the results) and sends those back to the front-end.
If Javascript is disabled, a simple meta refresh does the same thing.
I'm an experienced web developer in several different web technology stacks. I currently work in .Net and I've become curious about the Partial Postback.
I understand what the Partial Postback's function is and how to work with it programatically, but I don't like using technology that I don't understand, how is a Partial Postback implemented.
I understand HTTP Requests and Asynchronous Requests, the thing that bugs me about the Partial Postback is that it seems to be both.
Maybe I'm just missing something but it appears to me that the Partial Request does both, first firing off an Asynchronous POST Request but the Browser seems to be aware and the activity indicator starts to spin, which normally only occurs during an HTTP Request Page Render.
So can anyone shed some light on how Microsoft implemented, at the HTTP Request level, the Partial Postback?
I know this question has already been answered, but I disagree with the answer...
In my humble opinion, the term 'partial postback' is being misused in the above-mentioned article "How to write your own partial postback in ASP.NET 2.0". In this article, the author shows you how to make an AJAX call to an HttpHandler. This is a very different process than making PartialPostback calls in ASP.NET.
I beleive this 'difference' is eluded to in the (above answers) after-thought comment which states:
"An UpdatePanel not only refreshes the controls which it contains, it also updates the ViewState value with the one obtained from the server, after processing."
While this final comment somewhat elusively-illustrates the definition of a 'Partial Postback' using an ASP.NET UpdatePanel...it doesn't explain what a partial-postback is (which, once again, is a very different process than that of a normal AJAX call).
To elaborate...
MICROSOFT ASP.NET AJAX Using UpdatePanel's:
At a basic level, Microsoft AJAX supports asynchronous requests via a partial-page-postback. Partial postbacks iterate through the same page lifecycle as a synchronous full page postback, but only specific regions or controls on the page are refreshed - thus achieving partial page rendering. MICROSOFT ASP.NET AJAX is dependent on the interceptor pattern to generate and handle a partial-postback. Upon initialization, MICROSOFT ASP.NET AJAX JavaScript libraries add a set of client event handlers to intercept calls that would normally initiate a full page postback. The handler functions intercept postback calls from registered controls, generate a partial postback, process the response content and then update page content asynchronously. Since MICROSOFT ASP.NET AJAX is built on the existing ASP.NET postback architecture it utilizes event-validation and maintains the view state throughout the partial-postback process. Your standard 'normal' AJAX call doesn't do these things!
To put it shortly...
MICROSOFT ASP.NET AJAX uses 'normal' AJAX to 'ajax-ify' it's pages and achieve partial-updates...and in doing so, it trades & manages view-state MULTIPLE times throughout a single call. This is WHY it is called a 'partial-postback'. Subsequently, this is also why they originally described the UpdatePanel as a means to make your pages 'ajaxy' (because it is not the same thing as using AJAX).
NORMAL AJAX Calls:
Asynchronous requests initiated using JavaScript in the browser creates a new connection to a server. Yes...this may include stateful postbacks to a page, but also stateless requests to resources apart from the current page. However, in the case of an asynchronous postback , only the information that needs to be processed by the current page on the server is passed INTO the request (and you can control this). Meaning, the contents of the entire page do not need to be submitted, no view-state needs to be managed & the (native) overhead embedded into the page-lifecycle can be bypassed. Meanwhile, an asynchronous postback only calls server-events associated with processing the CURRENT REQUEST. This is why normal AJAX is so much faster than PARTIAL POSTBACKS!
These Points Illustrate...
Not only WHAT a 'partial postback' is...but WHY there is a difference between a 'partial postback' and an 'ajax' call. Which is why this is a better answer.
From How to write your own partial postback in ASP.NET 2.0:
At the heart of the partial post back construction is the XMLHttpRequest, a DOM API. It can be used inside a web browser scripting language, such as JavaScript, to send an HTTP request directly to a web server without having to reload the entire page and handling the response from the server again within the scripting language. This data, in the form of XML, can then be used to manipulate the page elements on the client side.
When the button on the ASPX page has been clicked, a client side HTTP request is made using the XMLHttpRequest API. This request is handled by an HttpHandler on the web server. The HttpHandler receives the request, processes it, and sends back the response to the XMLHttp object on the ASPX page. The XMLHttp object in turn consumes the response and renders the appropriate UI changes without the browser having to do a full refresh of the page.
An UpdatePanel not only refreshes the controls which it contains, it also updates the ViewState value with the one obtained from the server, after processing.
Take a look at:
http://www.codeproject.com/KB/aspnet/PartialPostback.aspx
I'm using a separate class and unique method for sending mail.All my web pages, will call the method to send the mail. But, I'm using Client.SendAsync() to send the mail. The following error occurs while sending the mail asynchronously.
"Asynchronous operations are not allowed in this context. Page starting an asynchronous operation has to have the Async attribute set to true and an asynchronous operation can only be started on a page prior to PreRenderComplete event"
I set Async=true in #page directive, but, as I'm using separate class, so no use of it. Is there any other way to overcome this problem?
Seems you just need to start your async task before PreRenderComplete event; do you mind to post some relevant ASP.NET code?
Also, read this: Running an asynchronous operation triggered by an ASP.NET web page request
This article may be of some help to you:
Fire and Forget Email, Webservices and More in ASP.NET
Setting Async to true is OK if that separated class is declared, instantiated and within the context of the page request.
However you probably need to handle SendCompleted event.
See the sample codes in this MSDN Reference.