I noticed in some code that [WebMethod] attribute is used in the code-behind file of an aspx page.
But as I remember it, this attribute is used to expose Web Service and it is often seen in asmx file.
So what's the difference between these 2 usages?
Thanks.
If that method is also static, you can call that method via javascript/ajax, without a full page postback.
Note that your ScriptManager needs to have the EnablePageMethods property set to true.
Webmethods in code behind are used for AJAX calls. If you are using jquery or similar and you need to implement an ajax functionality on your page then you will have to define you method with WebMethod attribute and have to make it public static. Then only it will work.
WebMethod's concept I feel has been taken from web services. Since asp.net didn't have any defined way of handling ajax requests to method of page behind, they have extended this feature to be used for code behind methods.
Keep a watch that being public static methods you may not be able to use your page class' internal properties here. so, you will need to deal with that.
Related
I'm currently having trouble finding a way to call ResolveClientUrl within the context of a static web method inside of a ASP.Net Web Forms page.
I'm using jQuery Ajax calls to interact with WebForms as documented here: http://encosia.com/using-jquery-to-directly-call-aspnet-ajax-page-methods/ which is the reason why the WebMethod needs to be static. Problem is that within the WebMethod I need to generate an URL and append a query string to it, and I would like to play it safe and pass it through ResolveClientUrl before appending the query string.
Is there any way I can work around this, or does .Net provide an alternate static method that does more or less the same thing?
from...
ASP.Net C# ResolveClientUrl inside Class
Instead of calling ResolveClientUrl on the Page object (or any controls), you can also use Web.VirtualPathUtility.ToAbsolute("~/home.aspx"); which will give you the same result as calling ResolveUrl("~/home.aspx");
It is possible if called from a web page using:
public static void DoThis()
{
Page page = HttpContext.Current.Handler as Page;
}
However, if you are in a web method, it's not going to be the page as the handler; its a handler for the web request. I used this approach from JavaScript, and it did work:
http://iridescence.no/post/Resolving-relative-URLe28099s-from-JavaScript.aspx
HTH.
Can we call a Method that exist on a aspx page through Web Services.
It is like Reflection that method exists in dll form , but is it possible to call method from Aspx page if yes then please tell me how is it?:confused:
The code-behind class in an ASPX page is just a class, so technically there is nothing stopping you from doing that. However, it strikes me as a really bad idea from code design point of view.
The code in an ASPX page class should be related only to that page. If you need the same functionality elsewhere, move the code for that functionality to some other place (such as a class library that can be called from both places).
You should extract common functionality to a class of its own - this way you can call the code from both the web page and the web service and keep them decoupled from each other.
I'm working on customizing BlogEngine.Net to be able to return some HTML from an AJAX call. Basically I'd like to render a UserControl server-side and then return the resulting HTML to a client-side call.
I've done this many times in other applications using static PageMethods marked with the [WebMethod] attribute. But any time I try this with BlogEngine.Net, I get the full HTML of the page returned. It doesn't even look like the WebMethod is getting touched.
I've also tried to implement this as an HttpHandler, but I have the same result. As soon as I include a page (vanilla Page class) and use it to render the control, I get the full HTML of the page I am calling from instead of the generated code, leading me to assuming something is hijacking my code to render a Page.
Any ideas or alternate solutions to be able to render a user control server-side and return the HTML using the BlogEngine.Net framework?
If you look at the code of CommentView.ascx, they do the same thing using ICallbackEventHandler. That basically renders the comment preview and also the comment itself.
However, it should be possible to do it like you said too, with [WebMethod]. I have actually customized my own setup to change CommentView to use a [WebMethod] and it works fine.
For an example of their own [WebMethod] implementation, have a look at AjaxHelper under admin folder, it's a dummy page whose purpose is to serve these web methods.
The above are for BlogEngine.NET 2.6.
I have a custom class library that performs validation. I want to open up this class for use within Javascript. I understand that I can easily achieve this by utilizing WebServices/WCF or by creating a function on my page with the WebMethod attribute, but it'd be nice not to have to set all that up for every project.
Ideally I'd like to just add the WebMethod attribute to my class library methods and then call them using Javascript.
Unfortunately, you will have to expose an endpoint that your Javascript function can see. In ASP.NET this is most easily done with the web method attribute that you have encountered. However, this method requires two parts the endpoint and the actual code. If you think about it, it makes sense. Javascript has no way of talking directly to a compiled .NET assembly. It must go through a type agnostic interface. One thing that you can do, and you may be doing this, is generate the .asmx file with the web method and then have that call your class library method. This will not prevent you from having the .asmx endpoint, but will prevent any duplication of the actual code. I don't have a lot of experience with WCF, but I believe that you will still need an endpoint of some sort to interface between Javascript and C#.
The WebMethod attribute has to be used from a page level method. It's not too much of a hassle though if you set your library up correctly. A WebMethod is just a static method, but if you plan to use it in multiple pages, then you most definately want to make it a WCF service. Neither of these should be difficult and the overhead is minimal.
Alternatively you could use a base Page class that all your other pages inherit from and define your WebMethod there. This class could live in class library somewhere and be used across multiple projects.
I have a relatively simple page that will do most of its operations on the client side using Javascript or JQuery. However, initially I do need to retrieve some data from the DB server based on QueryString parameters.
I plan on passing this data in the form of a JSON string to the script by an old-fashioned ASP manner ( var severData = <%=MyPublicData %>) block where MyPublicData is defined in CodeBehind as:
Public string MyPublicData;
The question is, which event in the ASP.NET page lifecycle is the best for this? Page_Init ? Page_Load? Also, is it worth the effort to do this in ASP.NET MVC. I did look at this possiblity but it seemed a little too much for a simple page like this where I do more 90% of the work on the client. Any thoughts on this?
Page_Load is more appropriate, but either will work.
It's very difficult to say if MVC is more appropriate for you application than webforms without knowing more about the application. However, if you don't want to abstract away the traditional web model then I'd go with MVC.
This kind of simple property or field assignment can go anywhere in the lifecycle. For lack of any other reason, you might as well stick it in Page_Load, since that method is usually waiting for you in the code-behind anyway.
well, on the contrary, if it uses mostly javascript with jQuery, I would recommend you to use MVC. you will not have any problem with the ids for instance.
There are workaround to use jQuery with webforms, but it is never perfectly clean regarding selecting the DOM.
MVC : a single action method where you will retrieve your data (preferably from a small repository) and 1 view where you display your data with total control over your html elements.
and jQuery will just fit perfectly for your clientside work.
You can get either to work; you can write public variables/fields to the client in ASP.NET web forms, although MVC has an edge due to the way it renders the UI.
So for MyPublicData, you could assign it a value at any part of the lifecycle; you can assign it in code-behind to a label or something like that, or if it's JS markup you can write it out using Page.ClientScript.RegisterStartupScript or RegisterClientScriptBlock... so you have multiple options.
In MVC, you would assign the value in the controller and render it in the UI, or with JQuery you can do controller requests real easy with $.ajax.