ASP.NET Page.User is null during AJAX request - asp.net

I'm using the MVC2 framework and one of my views has a bit of conditional logic that gets the Page.User.Identity object and does a comparison with other values to determine what to display.
That all works fine on the initial page load, but when I make an AJAX call to get partial page updates (I'm doing this all manually with YUI3, not the .NET AJAX stuff) the Page.User object is always null.
Anyone know why the Page context seems to be discarding the User object for asynchronous requests?
Thanks,
Chris

If your request-handling method is a static WebMethod, there won't be a page instance to work with and Page itself will be null (that is, you won't even be able to resolve Page.User).
If that is indeed the problem, use HttpContext.Current.User instead. (And be sure to read Why do ASP.NET AJAX page methods have to be static?)

Related

AJAX, IIS, ASP.NET

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

Easiest way to simply display confirmation that a webservice worked?

I'm calling an asp.net webservice from an ASP clasic page basically just with:
<a href='http://domain/webservice.asmx/command'>Command</a>
and when users hit that button it works but they're just shown an xml page. The function will either work or not so I was wondering if it'd be possible to just have a pop up box appear to tell them if it worked or not after they clicked it rather than redirecting them to an xml page.
I'd prefer to not have to use jQuery or another javascript library.
If that's not possible, is there any way to dress up the XML page? Currently it says 'This XML file does not appear to have any style information associated with it. The document tree is shown below.' at the top.
Also, the domain that the webservice is on is different to the domain that the website that's call the webservice is on. Not sure if that matters.
Thanks
Check out this MSDN Link on Calling A WebService From Javascript Using AJAX. No JQuery is required and it boils down to having to use the ScriptService attribute on your WebService method and adding a ServiceReference in a ScriptManager control. You can then easily call your WebService from Javascript and it will call another Javascript function when it finishes. It is in that response function where you can add your confirmation display.
be aware that this is a bad idea to let the user handle directly - web services are almost always called by your code rather than a client browser session. One reason is that raw error information would be hown to the client if there were a problem.
If you really want to do this, you can either:
Use AJAX (No framework required - just JS) or
You can make the webservice non-standard so it returns user-friendly content - perhaps by wrapping it in a website which calls the API behind the scenes and formats the response in a meaningful fashion.

Why Ajax pagemethods are static

Why Ajax pagemethods are static?
When they're called, you're no longer within the context of a page being returned by the server: there isn't any postback data, you're not creating controls on the page etc. The only information you have is what the AJAX call provides you with, which is presented in the method parameters. It wouldn't make sense for them to be instance methods on the page, as there's no logical instance of the page as far as the server is concerned.
They could be instance methods on an "AjaxRequestHandler" type or something like that - but I guess the designers felt it's simpler to keep them with the page as from the client's point of view they're associated with it.

Which ASP.NET Page event is the best place for this type of code?

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.

Calling a ASP Page thru it Class

Like in Windows Forms:
Dim myForm as New AForm(Constr-arg1, Constr-arg2)
myForm.Show
... is there a similar way to Load a Page in ASP.Net. I would like to overload the Page Constructor and instantiate the correct Page Contructor depending on the situation.
Can you just link to the page passing parameters in the QueryString (after the ? in the URL) and then use them in the constructor (more likely PageLoad)
I think the best approach here for ASP.NET is to write User Control (*.ascx file) that represents page content, and load different controls based on current situation using Page.LoadControl() method. This solution is flexible enough, because only reference to control is its name. And this approach is much more useful than page constructor overloading as soos as you're not related on strong types, only on controls' names.
This isn't really the "correct" way to redirect to a page in .Net web programming.
Instead, you should call either Request.Redirect("~/newpage.aspx") or Server.Transfer("~/newpage.aspx"). You should then handle the request in the new page's Page_Load handler.
You can pass state between the pages by adding to the query string of the redirected URL (i.e. ~/newpage.aspx?q1=test), or by assiging values to the Session store (i.e Session["q1"] = value).

Resources