i have an argument at work about the best way to implement ajax handling for forms. we build all our forms under asp.net platform (sharepoint to be exact) but since we talk about public sites we though to cut the time-costing postbacks and make all postback in ajax request.
in order to best implement the server side i took a bit deeper look into handlers and modules and i then thought that i can cut all that by implementing a module that in his beginRequest identifies if its an ajax request (say by a special element in the querystring), and if so call CompleteRequest() and then in this module's endRequest if it was our ajax (say i flagged it in beginRequest) handle it.
so i would like to hear your thoughts about the pro's and con's about it, and also how "dangerously" it can impact the entire website ect.
the other option is, o.c., a generic handler (ajaxHandler.ashx).
i am again stating we are talking about IIS7+ where they integrated the pipelines.
p.s.
another thought is to build a WCF that will have to "open" (create instances) of anything that i would already have in my handler/module (in sharepoint for example the SPContext)
regards
Bresleveloper
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.
We have a flex application that connects to a proxy server which handles authentication. If the authentication has timeout out the proxy server returns a json formatted error string. What I would like to do is inspect every URLRequest response and check if there's an error message and display it in the flex client then redirect back to login screen.
So I'm wondering if its possible to create an event listener to all URLRequests in a global fashion. Without having to search through the project and add some method to each URLRequest. Any ideas if this is possible?
Unless you're only using one service, there is no way to set a global URLRequest handler. If I were you, I'd think more about architecting your application properly by using a delegate and always checking the result through a particular service which is used throughout the app.
J_A_X has some good suggestions, but I'd take it a bit farther. Let me make some assumptions based on the limited information you've provided.
The services are scattered all over your application means that they're actually embedded in multiple Views.
If your services can all be handled by the same handler, you notionally have one service, copied many times.
Despite what you see in the Adobe examples showing their new Service generation code, it's incredibly bad practice to call services directly from Views, in part because of the very problem you are seeing--you can wind up with lots of copies of the same service code littered all over your application.
Depending on how tightly interwoven your application is (believe me, I've inherited some pretty nasty stuff, so I know this might be easier said than done), you may find that the easiest thing is to remove all of those various services and replace them by having all your Views dispatch a bubbling event that gets caught at the top level. At the top level, you respond to that event by calling one instance of your service, which is again handled in one place.
You may or may not choose to wrap that single service in a delegate, but once you have your application archtected in a way where the service is decoupled from your Views, you can make that choice at any time.
Would you be able to extend the class and add an event listener in the object's constructor? I don't like this approach but it could work.
You would just have to search/replace the whole project.
Is there any limitations on AJAX Calls with ScriptManager to Web Services?
I have an application and I need an AJAX enabled form in it. After every Insert or Delete, I have to get a list from database and show it on page. So I call two server methods from my JS.
Isn't too many AJAX calls gonna cause any errors(eg. timeouts, transfer errors etc.)?
Too many of any kind of request will give you the same things to worry about. An AJAX request is just like any other HTTP request, a ScriptManager control won't be imposing any constraints.
The only limitation is your hardware and your IIS settings (application pool connections, etc.).
Of course, you should always be smart about how you program your methods, utilize caching where appropriate, etc. to ensure that they will hold up under heavy load.
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