Based on my understanding, both of them essentially do the same thing (lets us execute a server side method from JS). Are there any differences?
Also, Ajax Page Methods can be implemented either using JQuery or using ScriptManager. Which one is preferred and why??
**BOUNTY: Adding a bounty to get clear explanation of the question. Thanks **
Fundamentally, Client Callbacks and Ajax Page Methods are doing the same thing. They use an XMLHttpRequest object to send a request (usually asynchronous) to some URL, get the results of that request, then execute a callback method you've provided (callback with a lowercase c), passing the results of the request to your method.
Having said that, there is one big difference between the two approaches:
Page Methods are implemented as static methods on your page. Your page class is just a convenient container for these methods, which could really be hosted anywhere (a web service, a custom HttpHandler, etc.). Since no instance is ever going to be constructed, the client doesn't have to send ViewState data and Asp.Net doesn't have to run through the Page's lifecycle. The flip side is that you don't have access to to your Page class's instance methods and properties. However, in many cases you can work around this by refactoring instance methods into static methods. (See this article for more information.)
Client Callbacks are implemented as instance methods on your page.
They have access to other instance methods on your page, including stuff stored in ViewState. This is convenient, but comes at a price: in order to build the Page instance, the client has to send a relatively large amount of data to the server and has to run through a fair chunk of the page lifecycle. (This article has a nice diagram showing which parts.)
Apart from that, the cost of setting them up varies quite a bit and clients use them differently:
Client Callbacks require a fair amount of idiosyncratic scaffolding
code that is intimately coupled to Asp.Net (as shown in the link above). Given
the much easier alternatives we have now, I'm tempted to say that this technology is obsolete (for new development).
Calling page methods using
ScriptManager requires less setup than Client Callbacks: you just have
to pop a ScriptManager onto your
page, set EnablePageMethods = true,
then access your page methods through the proxy the PageMethods proxy.
Calling page methods using jQuery only requires you to link the jQuery library (and familiarity with jQuery, of course).
I prefer to use jQuery to access page methods because it's independent of the server framework and exposes just the right amount of implementation details, but it's really just a matter of taste. If you go with ScriptManager, its proxy makes the page method calls a little easier on the eyes, which some might consider more important.
I would say there are differences, but would tend to say do it the way you feel more comfortable with.
I have used both approaches, and having jQuery calls from the page is generally faster. I write an ashx handler that does the job the jquery call needs (query the database, process something, etc.) and call it from the page. I wouldn't use an aspx page for a jQuery call, because you're sending a lot of info that you won't need at all. The difference/ benefit of using an Ajax.Net call is that you don't need to build another page to process things, you can use the same page events to do it.
For example, if you need to fill a second drop down list using the selected value on a first one, you could use Ajax.Net to call the SelectedIndexChanged in the page code behind and when it fires go Page_Load, SelectedIndexChanged, Page_PreRender and so on. In the event method you'd query the db and fill the second ddl.
With jQuery that could be a bit different. You make your call to an ashx handler, the handler is just a server method that do the magic and return data in the form you want to have (json, array of strings, xml, etc) and fill the second ddl using javascript.
As I told you before, some people doesn't feel too mcuh comfortable with Client code and tend to do it in the server, but I always say that you need to use the correct tool for the right job, so know your tools and apply them wisely.
If you want to know more about ASP.Net, ASHX handlers and jQuery, you can read a post that I wrote about it.
Hope it helps.-
They are essentially the same. Both:
Setup a webservice for you that the javascript for the control can call.
Provide asynchronous response without involving the page lifecycle.
They are different:
Page Methods simply require that you decorate a static method with an attribute and you are done. The rest of the magic is handled by HTTP Handlers and Modules. Callbacks require you implement a few interfaces and handle the async event handlers yourself. I find them to be a little more of a pain.
Callbacks only work with certain controls. Calling page methods allows you to affect any control through custom javascript. Callbacks have a slight advantage here in that the client-side behavior is already written and fixed. With page methods you have more flexibility, though (the behavior on the client side is determined by you).
There are a few other differences, but these are the basics. My understanding is that client callbacks tend to perform as well as Page methods, but are not used as much becuase they are only available in certain situations, whereas a Page Method is always a valid avenue.
As for the ScriptManager vs. JQuery question, my feeling here is it's about taste more than anything. I like JQuery's syntax and I feel like it performs better, but in the grand scheme of things the most expensive thing is the XmlHttpRequest... after that the execution of the javascript is likely to be insignificant in difference next to that.
Related
I have a few questions regarding PageMethods. I am learning the use of PageMethod.
Why can't PageMethods be called from user controls?
If server-side controls and viewstate can not be access from PageMethods, what is the use of PageMethods? If I need to update the UI with javascript after response back from a PageMethod, then we have to write lots of script all the time when we work with PageMethod.
So please tell me in what kind of situation we should use PageMethod.
Here is a simple example of the benefit of a PageMethod, inspired by functionality stackoverflow.com has.
When you type in the Tags textbox, tags that match some of the text you started to enter begin to appear. This could be handled in a PageMethod (although, in SO's case, it would not be, as they use this functionality in multiple places on the site, so it is very likely its very own web service). No extra scripting is needed: you simply call the PageMethod in your jQuery AJAX call like you would any other web service, except the URL for the service is the same as the page (plus the method name).
For an example of this, see http://dotnetslackers.com/articles/ajax/Using-jQuery-with-ASP-NET.aspx
I'm dipping my toes into web development. Based on various bits of advice, I'm going to start by getting a handle on html, css and javascript.
I'm interested in Ajax, I've had a look at the client side code and that looks straight forward enough, I'm slightly confused about what I do on the server side.
I'm using IIS and ASP.NET. I've had a google but I can't find anything that is either simple or current. There's a lot of talk about the Ajax toolkit, which I believe are controls which use Ajax (and may be retired??) Everything else seems to be based on old versions which I don't trust.
So, in really simple terms, what do I have to do in IIS to respond to an AJAX call?
Quick aside, I believe we can use JSON for object serialisation?? I assume I don't need to in the interests of getting a simple sample running?
So I have an Ajax call which will have one parameter, and I want to return "something" based on the parameter. What is the simplest code to achieve that with IIS and ASP.NET?
Thanks
An AJAX call is basically just a regular call to your website. The only difference is how the browser handles it - AJAX calls are done in the background with Javascript (the J in AJAX) and then does something with the data. You could take the URL that you're doing an AJAX call with and put it in your address bar and it'll return the exact same data. So, basically, what you do on the server side is exactly what you would do as if it were a form being submitted, for example.
As far as object serialization, yes, JSON can do that.
First of all, doing ajax has nothing to do with IIS; it has to do with ASP.NET.
There are essentially 2 ways to do AJAX in .net
1) Heavy use of the framework. You can put your asp controls (such as literals, gridviews, listbox...) in a control called an updatepanel. For this to work, you need to add a script manager to the aspx page. Then, when the user raises an event (for example, paging and sorting of a table), the request is handled by the framework and only the part of the page that's in the updatepanel is refreshed. The other way to raise events is by using the __doPostback function that comes with the asp.net framework. The downside of this method is that a lot of data needs to go back and forth between the user and the server so it can be slow. The upside is that you don't have to worry about generating the HTML since the asp controls handle it for you.
2) Heavy use of Json. With this method, you can use jQuery to call a page method or a web service. You send a json object to the server and you get a json object back. With jQuery, this is really easy. The downside of this method is that you're getting just the json data back: no formatted HTML. So, if you're looking to have a table updated, this method would be tedious because you'd have to recreate the entire HTML. However, the upside of the method is that it's very fast because only the raw data is transmitted. If you implement a web service, you don't even need to create an entire page.
What do you need to get from the server?
If you want to return "something" from the server that's "simple" (just data), I'd recommend a web service with jquery to trigger the call. If the return data is "complex" (html code for controls) then I'd recommend using MS ajax with the update panel.
Don't use the AJAX Control Toolkit, ASP.NET AJAX library, updatepanels or the scriptmanager control. Microsoft have pretty much ditched the lot in favour of jQuery and its Plugins (sensibly).
Here are just some of the ways you can use AJAX with jQuery in ASP.NET: Many ways to communicate with your database using jQuery AJAX and ASP.NET
We've been using IScriptControl to tie javascript objects to our UserControls and ServerControls, and it's worked fine.
The problem is that ASP.NET seems to provide no method to tie a javascript object to a Page. Up to now, we've been putting plain functions in the global namespace, but I am developing a serious allergy to that practice.
It'd be easy enough to wrap our functions into a javascript class, and to include the javascript file on the page, but how to instantiate the object, how to reference it from callback events, and how to pass data to it from the code-behind, I haven't figured out.
Or rather, the methods we've been using up to now (hidden fields, emitted javascript strings, etc.), really bug me.
Anyone have better ideas?
There isn't any association between the JS file and the page, unless you build it. With script controls, the common practice to store state is hidden fields (the ACT uses this approach). The only other ways to communicate with the server is through a web service call, form posted data, or by invoking a __doPostBack (but that isn't AJAX).
You can create some base architecture to link the two together. With script controls, the server renders a $create statement to pass properties and event handlers from the server to the client; data being posted back to the server is stored in hidden variables and processed on the client (with most script libraries), so script controls and ACT hide a lot of this for you, and you would have to build some of this if you wanted to automate this. It may help to study the client-server interaction to give you ideas of what to do if you wanted to customize this.
Funny, I was thinking of the same thing for my Nucleo project (a third party library of mine) on codeplex, but I haven't yet gotten around to it.
Let's consider that I have an asp.net page which will go to the server after a client-side event and will do "some stuff" and show a return value of this process on the UI afterwords.
My question is, if I am working in the same domain, how should I decide between creating a web-service and calling that AND simply raising a post-back and handle this "some stuff" on the aspx page itself?
Under what conditions creating a web-service becomes meaningful to overcome some processes while working in the same domain?
There are no hard-and-fast rules. However, I can offer a few high-level guidelines:
Prefer an .aspx page if the result includes a significant amount of markup (HTML, JS, etc), or where generating the results is simplified by having access to control state from the original page. Keep in mind that the Page object carries a significant amount of overhead with it.
Prefer a web service for queries that can be parameterized and that return structured data
Prefer an HttpHandler for queries with simple parameters that return either simple, full-custom text or binary (such as an image)
I would look at how fast it takes for the post and reload action to occur. It depends on the user's expectations. Most people, if they know they are using a browser, will find that up to two seconds is just about acceptable for the action to occur, and the screen to be reloaded. On the other hand, in one of my jobs, I was using ASP.NET to drive a touchscreen, and this just looked totally wrong, so I refactored the code to use a static web page plus a WebService component.
You also need to take into account the capabilities of the browser. In the example above, I knew that I was only using IE6, so I could afford to write my Javascript code to take advantage of that browser. You may not be so lucky. If you are to use a web service which has client update, you should ensure that you target a version of Javascript and DOM that is supported by all your target browsers.
I have to integrate an existing, simple asp.net web forms app including postbacks etc. into another external site with a jQuery load() call., an app that was intended to be integrated through an iframe. I doubt that's possible without a rewrite of the app.
The app is a basic questionnaire that leads the user to a product suggestion at the end.
Does anyone have any pointers to how I could solve this? I guess I will probably have to rewrite the app with web services and dynamic calls to RenderUserControls, I will also need access to the page that calls the load() and write additional jQuery methods to handle the user input... I will probably have to remove all of asp.net's postback calls and rewrite the handling of the user input?
First of all you should note that the load() function, like all ajax, can only work on the same domain. So if the 'external site' is on another domain ajax is the wrong choice.
It does sounds like a lot of hard work, depending on the complexity of the page. Postbacks can occur in many places - image clicks, combo selects, etc. Also, there are hidden fields to worry about, like the View State and Event handler - those have the same names on both pages. You'll have an easier time if the external site has no state and postbacks.
If the pages are relatively simple this can probably be done. It's been my experience that forms don't work well in other forms, so you'll have to remove one of them (probably the loaded page's form), or place them one after the other. As you've mentioned, you'll have to rewrite postbacks, you'll want to serialize the data. You may be able to change this string to fit the names on the original page (if you've changed the name of the viewstate, etc, it's easier to change it back on the serialized string than to mess with IDs), post it to the original page, and load again.
Personally, as much as I like jQuery, and as much as this project sounds interesting (and it is), I'd probably go for a server-side solution. It sounds much easier to create a user control (that may use ajax itself), or to the expose the page's functionality using web services or better, generic handlers.