ASP.NET AJAX UI

Re: PageMethods - wait for the ext version

kiruba.sankars — Thu, 21 Feb 2008 12:11:40 GMT

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>

<title>Untitled Page</title>

[System.Web.Services.WebMethod]

[System.Web.Script.Services.ScriptMethod]

public static string MyMethod()

{

return "MyMethod Called";

}

</script>

function preview()

{

PageMethods.MyMethod(onComplete);

}

function onComplete(res)

{

alert(res);

}

</script>

</head>

<body>

<div>

 <asp:ScriptManager ID="ScriptManager1" runat="server" EnablePageMethods="True" >

</asp:ScriptManager>

</form>

</body>

</html>

Re: PageMethods

oliver0303 — Sat, 15 Sep 2007 20:24:52 GMT

Hi Murali,

Im experiencing the same problem. Did you ever solve that ?

When using PageMethods the localized versions of my strings are not loaded. I hope someone have a solution for this.

Best regards,

Martin

Re: PageMethods - wait for the ext version

blbirajdar — Wed, 05 Sep 2007 11:02:14 GMT

Hi Friend

You are making simple mistake.

Every AJAX enabled site has a Script Manager on the Page by default. Or either you can put it on your master page.

<asp:ScriptManager ID="MCScriptManager" runat="server" EnablePartialRendering="true" EnablePageMethods="true">

</asp:ScriptManager>

Just put the tag EnablePageMethods="true"

and click...Go....................

Cheers.........And Happy coding...........

Re: PageMethods

MURARAMAPS — Thu, 02 Nov 2006 13:04:45 GMT

Hi, I have a weird problem with PageMethods. I managed to declare a method static and decorated it with script and webservice attributes and put it in ASPX instead of code. Now I can call it from JS. The pagemethod executes and returns a string from a resource file on successful completion.

For some reason this string is always from en-US even though i have other localized versions of the resource file containing the string. The page culture and uiculture is set to "auto" and i kept one of my localized language as the my first language in my internet explorer followed by en-US.

The other page controls are loaded from the resource file correctly, only the AJAX callbacks seem to return only en-US strings. I debugged to find system.threading.thread.currentthread.currentculture and uiculture always set to en-US on pagemethods callback. Would this mean that Atlas would not recognize any of the localization features of ASP.net or am i missing some thing here?

Murali

Re: PageMethods - wait for the ext version

mnn888 — Tue, 24 Oct 2006 18:45:37 GMT

I have a question,

If I just stick with the Atlas July ctp , is there a timer in it? Like does it stop working at a future date ?

Re: PageMethods - wait for the ext version

MrTea — Tue, 24 Oct 2006 10:11:32 GMT

haimMag:
insted of breaking ypur head and program again and again
it is better to wait to next version or final version
i will stick in july ctp until a better version will come
my program need page.clientscript.registerStartupscript and PageMethod
and both of them not working in ajax beta 1
so why go ther from july ctp???

Well the only problem with that logic is that you would imagine each version that comes out in Beta or RC form would be a step nearer to the final release, implying that the BETA is closer to the final implementation than the July CTP.

That said, I equally wouldn't be that surprised if things did change quite drastically before the final release.

I guess the thing to remember here is that if we choose to work with pre-release software then we have to expect it to change.

Re: PageMethods - wait for the ext version

haimMag — Tue, 24 Oct 2006 09:59:38 GMT

insted of breaking ypur head and program again and again

it is better to wait to next version or final version

i will stick in july ctp until a better version will come

my program need page.clientscript.registerStartupscript and PageMethod

and both of them not working in ajax beta 1

so why go ther from july ctp???

Re: PageMethods

Fredrik K — Tue, 24 Oct 2006 09:21:55 GMT

I think ScriptMethods (PageMethods) are part of the UI layer; consider where they are declared - no business logic should be residing in the Page class. I hope they change it so that they'll go back to being state-aware and part of the Page lifecycle again. The way it's implemented in the new beta, there's really not much distinction between a ScriptMethod and a WebMethod (web service) any more.

Re: PageMethods

MrTea — Tue, 24 Oct 2006 09:02:05 GMT

As something of an ASP.NET AJAX Novice I find this thread very interesting.

For me it touches a wider issue which is that for the newbie there is a vast array of possible approaches to building an ASP.NET AJAX app and the best path is not always clear.

My very first app simply used an UpdatePanel and seemed to work fine but then I decided I wanted a bit more control over what was happening.

Consequently my next app used PageMethods to call functions in the ASP.NET Codebehind. Again this seemed to work fine for such things as retrieving Strings etc.

Then I looked at Web Services and devised a couple of those which I then referenced from my ASPX pages (using the ScriptManager)

Now though I'm not really very clear where to go next.

I guess it's like anything else, you just need to give it time and try lots of different things before you can make a judgement call on the best way forward. The danger is that for those of us who have never used much javascript, we may be tempted to try and avoid it (using the UpdatePanels etc) but then come unstuck when we want a bit more control over our app's behaviour.

I hope the documentation will help with this though once the framework goes RTM.

Re: PageMethods

rstrahl — Tue, 24 Oct 2006 08:58:31 GMT

I agree as well - in most cases I use Web Services to abstract the logic, because it's just cleaner. But I would very much like to have the option to be able to get at the data in an easier way in the page.

As to the form with 50 fields: Well there's lots of ways to represent data <s>. Yeah you're probably right but I have a couple of forms that have this much data in various pages of a tabbed interface that's driven through AJAX. In fact in a properly architected AJAX application values are probably updated more frequently than one giant form submit.

But even so even if you have a smallish form like this:

http://www.west-wind.com/atlas/CustomerList/AtlasCustomerList.aspx

You then have code like this to retrieve the data to send to the server:

   // *** Cheating: This object contains only strings!
    //               If other types exist conversion
    //               must be done here.
    Customer.Companyname = GetValue('txtCompany');
    Customer.Contactname = GetValue('txtContactName');
    Customer.Address = GetValue('txtAddress');
    Customer.City = GetValue('txtCity');
    Customer.Postalcode = GetValue('txtPostalCode');
    Customer.Region = GetValue('txtRegion');
    Customer.Country = GetValue('txtCountry');

// *** Pass back the customer object to the server
CustomerService.SaveCustomer(Customer,SaveCustomerCallback,ErrorCallback,ErrorCallback);

It gets worse if the object your setting values on has typed values - then you have to do type conversion in JavaScript which is no fun... Then on the server you do that parsing again out of the object so you're just duplicating the work.

When I meant 'parsing on the server' I didn't mean parse the object. You do get the object back on teh server. But it's a proxy at best and from there you have to move the data out into a real object that actually does the data logic - an Entity that can save or a DataRow or whatever it may be. For most types a type converter isn't even required as the JSON proxy creates the required proxy objects on the client for you. That is very cool, but it's still more work than it has to be - you're still 'reading' the data twice - once on the client, then again on the server. Instead you could do it once and be done with it.

Re: PageMethods

jlchereau — Tue, 24 Oct 2006 07:58:10 GMT

Rick,

Convincing point of view, although a form with 50 input fields seems theoretical to me because it is not very user friendly. I should not have said "it does not makes sense" but I still do not like it.

Despite the fact that you definitely have a point, I prefer the more stateless approach of parsing the fields on the client and feeding a Javascript object that is passed to the web service or page method as you describe. Contrary to what you say, it is not needed to parse the object again on the server, the ASP.NET Ajax layer does that automatically for you, although you may have to write a couple of converters. Note that my business objects are very light data structures which are effectively persisted by business brokers.

By the way, thank you for your valuable web site, which I often consult.

Re: PageMethods

Fredrik K — Tue, 24 Oct 2006 06:43:09 GMT

Page.User is merely a convenience property that wraps System.Threading.Thread.CurrentPrincipal, which is static, so just access that instead :)

Re: PageMethods

rstrahl — Tue, 24 Oct 2006 03:25:47 GMT

>> I may be wrong, but IMO it does not make sense to access controls in PageMethods. PageMethods are part of the business layer.

Yes and no. But the point is you can already achieve teh 'business layer' effect by calling a Web Service and now with PageMethods being forced to be static you're doing nothing but duplicating that functionality. All this does give you another place to store your 'service methods'.

Allowing access to the page is very valuable IMHO because it allows you to read values set on the client without having to pass every damn field value as a parameter or as part of an object you first populate on the client.

Consider this: You have a form with 50 input fields on it and the user fills that out. Now you want to use AJAX to save those values. If you use PageMethods or Web Service you have to pass 50 parameters or create a client object that first parses the values out of the fields, possibly converts to the proper types etc. Then you send the data to the server, and you get the parse the values AGAIN on the server - out of the parameters or object into a business object or a DataRow or whatever.

Instead not passing parameters but receiving the values from the client directly on the server in the POST buffer lets you deal with the input values once and store it directly into your object.

I can be a huge timesaver and reduces boatloads of error prone $get() statements on the client.

If all that PageMethods does is duplicate Web/SCript Service behavior but in a page I say cut the whole thing and take the overhead out of the Page class.

Re: PageMethods

mnn888 — Tue, 24 Oct 2006 03:05:49 GMT

In the Atlas July CTP, Im using the Page.User.Identity.Name as a security verification inside the PageMethods , How would I do this in the new version without passing parameters in javascript, as this would reveal the values.

Re: PageMethods

jlchereau — Mon, 23 Oct 2006 21:27:48 GMT

See: http://blogs.msdn.com/sburke/archive/2006/10/21/hint-components-that-use-web-services-with-asp-net-ajax-v1-0-beta.aspx. PageMethods are broken in Beta1 and do not work in code behind.

Dimitrod, you say: "But if PageMethods are static how do we access page control values within such a method?".
I may be wrong, but IMO it does not make sense to access controls in PageMethods. PageMethods are part of the business layer. You should read control values using client-side code, pass these values to the method as parameters and read the returned data in the form of a basic type or a complex serialized object. I personally think it is a good thing that PageMethods are now static.