More MS Ajax Pain

October 22, 2006 @ 4:12 am- from Maui, Hawaii

Ok, here goes. I’ve had one hell of a frustrating day going through my code and moving it to Atlas Beta 1. I’ll get into specific issues in a minute, but my overall feeling is that this build is REALLY BUGGY. The previous ATLAS CTPs were reasonably stable and handled errors gracefully forwarding them to the client code. This build just crashes hard in many cases deep inside of client framework code. I’ve been at it for the better part of the day and while I managed to port all of the samples, just about all of them have one or two issues that I cannot seem to resolve completely without removing functionality. In fact, I've been doing that alot - skipping using framework features instead resorting to lower level JavaScript because it works.

Here’s more detail.

Script Framework Errors

With the code I have I have countless mysterious errors that are blowing up inside of the ATLAS client libraries which are throwing exceptions. If I step into these there with the VS JS Debugger there’s no call stack nothing to debug or check of.

Here’s an example. A call to creating a Sys.UI.Control is failing. I’m doing:

var lblStockname = new Sys.Preview.UI.Label($get('lblStockName'));

lblStockname.set_text(Result.Company + " (" + Result.Symbol + ")<hr>");

lblStockname.get_element().className = "errormessage";

lblStockname.get_element().style.fontSize = "8pt";

This code works the first call but will fail on a second call in the client library:

Sys.UI.Control = function Sys$UI$Control(element) {

/// <param name="element" type="Sys.UI.DomElement"></param>

var e = Function._validateParams(arguments, [

{name: "element", type: Sys.UI.DomElement}

]);

if (e) throw e;

if (typeof(element.control) != 'undefined') throw Error.invalidOperation(Sys.Res.controlAlreadyDefined);

Sys.UI.Control.initializeBase(this);

this._element = element;

element.control = this;

this._oldDisplayMode = this._element.style.display;

if (!this._oldDisplayMode || (this._oldDisplayMode == 'none')) {

this._oldDisplayMode = '';

}

The error is:

Error Sys.InvalidOperationException: Can’t create a control if the associated element already has a ‘control’ field.

The element in question is lblStockName. Even odder there’s no control property on it at least in the debugger or immediate window. I have NO IDEA why this is failing on the second pass through – certainly the objects passed in are being created new on every hit. I suspect there’s some glitch in the prototype logic that’s picking up a value somewhere in the prototype chain from another control…

I decided to bypass controls for this and just use plain DOM objects instead:

var lblStockname = $get('lblStockName');

lblStockname.innerHTML = Result.Company + " (" + Result.Symbol + ")<hr>";

lblStockname.className = "errormessage";

lblStockname.style.fontSize = "8pt";

The latter works reliably. The former fails on every second hit.

After some more investigation this seems to be happening ANYTIME a variable is assigned more than once with a new object assignment. This happens anywhere when I reassign the a variable name with a new object reference!

To duplicate all I have to do is assign an object twice in a row to the same variable like this:

var Progress = null;

function StartRequestProcessing()

{

Progress = new Westwind.UI.ProgressBar($get('ProgressBar'));

Progress.set_progress(0);

Progress = new Westwind.UI.ProgressBar($get('ProgressBar'));

Progress.set_progress(0);

}

This is of course not the real code, but in the application itself a new request creates a new instance of the control and the second time that happens it fails with the above error. Everytime. With my own custom control as above, or with built in controls like labels. This looks suspiciously like a problem in the prototype syntax and instance management. Somehow it appears that the instance is static even though a distinct separate local variable is used.

This is easy to fix on my end by simply making the control assignment globally which is more efficient anyway, but this seems like a pretty major and possibly fundamental bug in the framework.

This is only one of many other mysterious errors. I have another request on the same page that fires a simple timer that updates once a minute to display a small time timer display. This thing works once and on any subsequent calls it blows up with a generic null value exception. No callstack, no source, nothing… Where do I go from here?

There are a many null reference exceptions that pop up – they seem to be related to controls unloading in Dispose() calls which seems like a timing or circular reference issue.

This is one particular page I’m dealing with that mixes some Web Service callback functionality along with UpdatePanel functionality. I was actually able to convert the page and make it work relatively easily, but these mysterious client framework failures are not something that I seem to be able to fix.

DataSet/DataTable/DataRow results from Web Services don’t work

I use Web Services and PageMethods from client code quite a bit in my samples, because it's a nice lightweight way to get data from the server. One of the nicer features in ATLAS (and most other .NET based AJAX tools) is the ability to return ADO.NET objects like DataSet/DataTable/DataRow objects to the client.

Unfortunately in Beta 1 I can’t get Web services to return any data results anymore. The server framework throws serialization exceptions of varying messages from not being able to serialize the CultureInfo class to the Module class citing circular references.

I got a couple of messages in response to a post on the forums with others seeing the same thing.

I’m not sure if I’m missing some setting or configuration thing that needs to be done to make this work or what. Everything looks right in the proxy which includes reference to the right types. Other methods of the same service – including some methods that are returning IList based complex objects – are working just fine. But any attempt to return DataTable/DataSet results in these errors. Three out of my samples using separate services do this so it’s not something specific to one sample.

PageMethods Must be Static

PageMethods have changed. PageMethods are JSON based callbacks that go back to the current page. This functionality in the ATLAS CTPs varied from the Web Service functionality in that the callbacks to the page would passback full POST information of the form’s content so you could access controls on the client. Well, it turns out that this behavior has been changed. According to Shawn Burke’s blog PageMethods must be static now so you have no access to the page object.

Not only that but apparently due to a bug in this MS Ajax build the PageMethods must be defined in ASPX page, NOT IN THE CodeBeside:

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

<%@Register Src="~/ShowCode.ascx" TagPrefix="uc1" TagName="ShowCode" %>

<%@ Import Namespace="ScriptCallbacks.BusinessObjects" %>

<%@ Import Namespace="System.Threading" %>

<%@ Import Namespace="System.Web.Services" %>

// *** Due to a bug in the beta PageMethods must be defined

// *** inside of the ASPX page and CANNOT BE IN CodeBehind

[WebMethod]

[ScriptMethod]

public static string StartRequestProcessing()

{

…

}

</script>

WTF?

Seriously, why even bother to put this feature in if the methods have to be static? If that’s the case this feature should be removed and only Web Service access should be there since the functionality is pretty much identical. At least then you're making it clear you're calling a service and 'data layer'.

I think it really bites that the ability to call PageMethods with Postback data has been removed as that’s one VERY handy feature. It allows you to not have to construct very complex method signatures or pass complex objects that have to be properly passed on the client but rather let you do that kind of value parsing on the server more efficiently. But this is now no longer possible – you have to pass the values as direct parameters. It's often so much easier to deal with this stuff on the server rather than on the client especially since the client doesn't have any sort of automated databinding (oh wait, neither does stock ASP.NET <g>).

Honestly I can’t understand this decision by the Microsoft people. I believe the reason is for page cycle issues and worries about how these PageMethod calls can affect the page content. But why couldn’t the PageMethods at least have retrieved this content READ ONLY. IOW, you can read values out of the page, but you wouldn’t be able to change anything? Or even failing that at least provide an option to send the POST data from the client to the server!

There's nothing in the migration guide about this either.

Error Handling

One cool feature of the previous version of ATLAS was the page level Error handler you could set up. There was an ErrorTemplate on the script manager and it had the ability to capture all output and display the errors in a consistent interface including the rather cool shadowed background with the template content shown above it. According to the migration document this was making the script manager to complex… hmmm… what could be easier than to implement a template.

Instead you now have to implement an event and deal with some obscure client event code, the place to the UI content on your own the page somewhere. Yes, it’s true you have more control but this new mechanism isn’t exactly intuitive.

// *** Hook up an End Page EndRequest handler which allows us to check

// *** for callback hooking and errors

Sys.WebForms.PageRequestManager.getInstance().add_endRequest(OnEndRequest);

function OnEndRequest(sender,args)

{

// *** Check for errors

if (args.get_error() != undefined /* && args.get_error().httpStatusCode == '500' */)

{

//debugger;

var errorMessage = args.get_error().message

args.set_errorHandled(true);

//alert("Custom Error Handling:\r\n" + args.get_error().message);

var ErrorDisplay = $get("ErrorDisplay_Message");

ErrorDisplay.innerHTML = "Custom Error Handling:\r\n" + args.get_error().message;

}

This code applies to UpdatePanel operations specifically. It doesn’t handle other errors from script or callback code so it’s not exactly a unified error handler.

The PageRequest manager provides a bunch of new functionality BTW. It has beginRequest and endRequest methods which can be used to hook into UpdatePanel callback operations for example and determine when they start and stop which is handy.

Aarrgh

As you can probably tell I'm pretty frustrated by all of this. I was expecting the Beta to be a big improvement over previous versions instead it seems like we've taken several steps back. It's doubly frustrating to me because at this point i have little choice but to make do with this build since I have to do a presentation with it in a couple of weeks at ASP.NET Connections. That's going to be a lot of fun <s>...

I really am bummed that Microsoft apparently rushed this build out before it was ready. This was supposed to be a beta product, but several of these issues seem to indicate that some pretty major issues were simply overlooked (there's really no excuse to have PageMethods requiring running in ASPX code, or ADO.NET objects not working in Web Services). To top things off the documentation is horrible and covers only the Ajax 1.0 Beta, and not the value add Preview... Even all the old documentation links are gone and haven't been updated with new content.

Posted in ASP.NET AJAX Microsoft AJAX

Feedback for this Weblog Entry

DotNetSlackers: More MS Ajax Pain
by DotNetSlackers Latest ASP.NET News October 22, 2006 @ 9:18 am

re: More MS Ajax Pain
by re: More MS Ajax Pain October 22, 2006 @ 11:15 am

I understand your pain. Atlas is very far from being ready for production. This Beta release broke lots of things from past releases. It's like a new start.

I believe Anthem .NET is a much more mature framework for ASP.NET ajax.

re: More MS Ajax Pain
by Matt Gibbs October 22, 2006 @ 12:34 pm

Sorry you're having frustrations Rick. I agree that the naming is sort of confusing. Internally we refer to the CTP portion as the value-add. Maybe that would be better. The size of the scripts will be smaller in our next release. There are some more aggressive techniques for reducing script size, but we are still validating the results.

We took a hard look at the Page Methods before deciding to make them static. They should work in a code behind. We will investigate. There were some fundamental issues in page instance methods. Although they covered some scenarios, you could quickly get into conditions where the behavior would be incorrect and hard to debug. You are right, as it stands now you could just use a web service, but there was a fair amount of feedback that being able to package the code in the page would be convenient.

More and improved docs are in the works. For the other two issues you are seeing, we will take a look. Although there are some changes, I believe the platform is pretty stable overall. I don't expect a lot of churn in the core libraries going forward. We will primarily be addressing feedback and fixing bugs.

re: More MS Ajax Pain
by Rick Strahl October 22, 2006 @ 12:55 pm

Hi Matt, I understand of why you pulled the non-static page methods. I think there's been some discussion around that for a while at Microsoft <s>...

But I can't believe that there are issues that can't be worked around if you allow only reading of page control values. Wouldn't is just be a matter of hooking the remote method calls late enough in the call chain (at the end of OnLoad or OnPreRender) to make sure the page values has been set up? Sure it's going to be more expensive,but if you want light weight - use a Web Service (or a static method if that could be arranged for differentiation).

At the very least provide the option to pass form variables to the server so we could at least do a Request.Form on the post buffer. I really think this is a very important usage scenario that's overlooked as it allows picking up client side data without having to pass everything from explicitly from the client - it's just much easier to do on the server in many situations.

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

If you need to pass back data to save it means you'd have to read each of the values manually out of the control on the client and either pass the strings back as parameters, OR assign each of the values to an object and properly type them on the client, then pass that back to the server. Then on the server you get to parse the data one more time into an actual business object or DataRow or whatever. All you're doing is duplicating the work. Instead passing the POST buffer/values once you can use server side databinding or even plain values to read the values once instead of creating complex method signatures on the client.

re: More MS Ajax Pain
by Matt Gibbs October 22, 2006 @ 10:24 pm

The page lifecycle presents a bunch of challenges for page methods. It's just code, so certainly something more could be done < grin />. For the read-only scenario, why not use callbacks?

re: More MS Ajax Pain
by Rick Strahl October 22, 2006 @ 11:15 pm

Matt,

Callbacks are a pain in the ass to use and defeat the whole purpose of having an *easy* page callback mechanism with their multiple method interface based implementation and lack of support for call any context. More importantly though they don't address what I'm asking here, because they don't post back the CURRENT page state, but only the original page state.

I'm not quite sure what you mean by special considerations. Not trying to be a pain, but I've implemented this in my own libraries, and it's very painless as long as you don't update the page content or at the very least throw away any updates made if they are made. You can essentially run the page through the normal page cycle and then hook OnPreRender (or really anything after Page state has been restored) and at that point intercept and end the request. I don't see how this could cause any serious problems. Hooking OnPreLoad in particular might be the right place for this on the page level.

There could be issues with user code modifying values, but that's up to the page developer to handle by cecking whether the page is in a PageMethod callback (I have a IsMethodCallback property on my control I suppose that would have to be added or modified in ATLAS so there's a way to detect WHAT KIND of callback is happening). If that's the case the developer can bypass any code if necessary in OnInit or OnLoad.

There are ways to do this cleanly without much fanfare. I suspect your issues are that it's not 100% in that the page user or custom control can do things in unpredictable ways, but you know if the POST data comes back we can always get at the raw data that is unaffected by the page cycle. The key is not how it's accessed - it's the data coming back to the server from the client without passing everything through parameters or objects so you're double parsing the input.

re: More MS Ajax Pain
by Bertrand Le Roy October 23, 2006 @ 12:04 am

Errr. Rick: there can be only one control associated with any given element. When you instantiate two controls with the same element, you're breaking that, so you get an error message. You need to dispose of the first control before you attach the second one. If you need to attach more than one object to an element, it shouldn't be a control, it should be a behavior.
Also, in the other post, I think you looked at the size of the debug scripts. The release scripts are considerably smaller.

re: More MS Ajax Pain
by Steve October 23, 2006 @ 1:13 am

Hi Rick, long time reader - first time poster.

I agree with you...I have spent the best part of my weekend fighting with this AJAX release.

I have the issue where my page methods need to be in the aspx file instead of code behind ???? Madness.... I look forward to what Matt finds in looking at this.

I still have issues with intellisense....ScriptManager etc are not known; except in my master page. There are a couple of us on the forum with this issue (you were posting on the thread), hopefully we will get a resolution to this from MS today. Some pages render in the designer, some do not (the repeater seems to mess it up).

I may well leave the AJAX Beta until the next refresh and carry on with the CTP.

re: More MS Ajax Pain
by Rick Strahl October 23, 2006 @ 1:25 am

Bertrand, yes I can see that now <g>... not real obvious though is it? If I reassign a brand new variable I would expect to not step on an existing object, disposed or not. You're right it's real easy to fix (and it was a contrived example to demonstrate the point). The same thing happens if I assign a local variable in multiple functions and when that happens it gets real difficult to debug what's going on. So what you're saying is that each 'ATLAS Control' can be referenced exactly once per page, ie. it's in essence static? I suspect this is going to cause all sorts of weird issues if you're not careful...

I just double checked the script size: I have a page that's doing Web Service callbacks which should pull in only the base libraries. I get three WebResource files loaded at 16.8k, 7.3k and 4.3k. Files are Gzipped and if I uncompress them with Fiddler's transformer view they appear to be the stripped scripts (ie. spaces and breaks removed). This isn't bad, but nothing like the 9k that Scott mentioned in a previous comment.

I also notice that if I run an UpdatePanel page I get the same exact libraries, so there appears to be no difference betweeen what the page is actually doing.

re: More MS Ajax Pain
by Jon Henning October 23, 2006 @ 7:42 am

Rick,
I understand where you are coming from regarding the referencing of the contol only once and needing to maintain the global reference. However, looking at the code provided, it appears that you don't need to maintain the reference yourself. It appears you could do this instead.

var oCtl = $get('lblStockName');
var lblStockname = oCtl.control;
if (lblStockname == null)
lblStockname = new Sys.Preview.UI.Label($get('lblStockName'));

My point being is the framework is keeping the reference for you (which should be a little easier than maintaining these refs yourself).

Of course, if MS would offer some sort or wrapper for this logic it would be even better.

Note: I have not tried this yet (I haven't even downloaded the Beta yet)...

re: More MS Ajax Pain
by JP October 23, 2006 @ 8:50 am

Hello Rick,

For the WebMethods having to be static, it was convenient to be able to use the Page context in the WebMethod, but after thinking about it, does't it cause the Page instance to stay in scope and not be garbage collected since it has to wait for a call from the client (For how long?), ASP.NET does not know how long the client browser is open or how many times the method will be called, if you have a lot of requests for that page, you could end up wasting a lot of memory.
If I undersdtand, now if we want to pass a Page context value to a page method in the case of an AJAX server control, we have to first pass it as a property of the server control in our code, the server control will pass it to the client code which can use it as a parameter of the WebMethod.
More pain, but it seams this way, once the page has rendered, it can be disposed of.

re: More MS Ajax Pain
by Matt Gibbs October 23, 2006 @ 12:03 pm

The problem with page methods in a code behind is a bug. We'll have a fix for it soon.

re: More MS Ajax Pain
by Rick Strahl October 23, 2006 @ 12:06 pm

JP... no, the lifetime of the page is the same as any other postback - you make the call the page instantiates, the call executes and the page goes away. This is not like a desktop form - it's all a simulation <s>.

re: More MS Ajax Pain
by Bertrand Le Roy October 23, 2006 @ 3:03 pm

Rick, when you want to manipulate a server-side control from different points in your page, you don't create a new control every time, do you? You just create it once and get/keep references to it. Here, it's just exactly the same thing. There is just this one thing to take into account, which is the difference between the control and the DOM element. Don't confuse them. Actually, it's to reduce this confusion that we moved most of the stuff that used to be on the Control base class to Sys.UI.DomElement or we just left a single way to access the same functionality using myControl.element.

DotNetSlackers: ASP.NET AJAX Beta 1 from a telerik point of view
by DotNetSlackers Latest ASP.NET News October 23, 2006 @ 4:07 pm

re: More MS Ajax Pain
by Wally McClure October 24, 2006 @ 3:07 am

I'm glad to see that I am not the onlyone having problems returning datasets/datatables. I was afraid that I was the only one with this problem. I am also getting the serialization error.

re: More MS Ajax Pain
by Luis Abreu October 24, 2006 @ 4:55 am

hello,
to be honest, i just read the page methods section and, in my opinion, that's completly wrong. i still don't understand how it's best to have lots and lots of info being sent back to the server so that you can get the values of the controls on the server side instead of using javascript on the client side to get the values you need and then call the remote method (which is really the correct approach when we're talking about AJAX pages).

initially, i thought that the old paeg methos had a purpose: ensure that viewstate is updated, but guess what: it doesn't get updated when the server sends the info back to the client (at least i've run an example with a previous demo site and it just returned the result of the method call - if i'm wrong and you really get ViewState update on the client side, please let me know).

If this is true (ie, you can't update the viewstate during an old page method call), then page methods like they were are completly useless. The only thing they offered was being able to get the values of the controls on the server side (and, as I said, to do that, the request had to send all the form fields back to the server side). Is this really a good thing? Is it that hard to write document.getElementById("bla") to get a reference to a control in order to get its value?

I must say that i'm still amazed with the number of guys that want to build ajax pages withouth knowing any Javascript. that's completly wrong. Maybe someone has to invent AAX pages so that we can develop something similar to AJAX but without knowing Javascript.

re: More MS Ajax Pain
by Luis Abreu October 24, 2006 @ 5:10 am

It's me again...i just read the error section and i think you're being unfair.
the current release is a lot more flexible than the previous one. as you said, in the previous release you allways got that cool looking popup. but what if you didn't want that? nothing could be done since you had really to use it

currently, you can do several things, though you may need to use javascript:
1. you can define the message that is sent back to the browser by intercepting the error event generated to the panel and changing the default message which is sent back
2. you can handle the message as you want in the client side. that means that you can use the default alert msg or do anything you like (btw, you can use one of those cool atlas controls to show the message?)
3. you can even redirect the user to an error page defined on the web.config by setting the allowcustomerrors property to true (and not writing an aditional line of code!)

so, you can do the same things you had before (yes, you have to write some code) and now you have complete control over the way errors are handled. really can't see how this is worst than it was...

More MS Ajax Pain -compatibility compatibility compatibility
by haim October 24, 2006 @ 5:26 am

compatibility compatibility
did i mention that ???

rick u are so right - pain

here is a question,
u have a server control, the server control have "Page.ClientScript.RegisterStartupScript(..."
does the control works in updatapanel ??? No No No
why ??? compatibility
now u have to write "Microsoft.Web.UI.RegisterStartupScript(control,...")

let say i change that to Microsoft.Web.UI.RegisterStartupScript(control,...")
does my control works in non ajax(atlas) project ??? No No No

PageMethods Ha Ha Ha good jok - no more (viewstate or page reference there)

i go back to July CTP,
works pretty fine for me
i'll wait to next release

Ajax.NET Professional - AJAX and JSON made easy! : More MS Ajax Pain
by Ajax.NET Professional - AJAX and JSON made easy! October 24, 2006 @ 5:44 am

Rick Strahl is writingabout his experience about the new Atlasfiles:Ok, here goes. I’ve had one hell of a frustrating day going through my code and moving it to Atlas Beta 1. I’ll get into specific issues in a minute, but my overall feeling

re: More MS Ajax Pain
by Vikram October 24, 2006 @ 6:10 am

Hi

I have not still been to the number of problems you have listed and have got stuck at the very begining. Have a look at this

http://www.vikramlakhotia.com/New_Beta_version_of_the_ASPNET_AJAX_released.aspx

re: More MS Ajax Pain
by Garbin October 24, 2006 @ 6:59 am

Hi,

Luis, I see that now page methods are static and, honestly, this won't make much difference in my approach to ms ajax. On the other hand, I really can't understand why I should be so happy that they've become static.

Where is the "value-add" in having static page methods? With the old page methods, I could access the controls on a page, work with an updated viewstate (even if it wasn't sent back to the client) and even call my PageBase helpers or pass my 100 values without the need to write the js to get my textboxes located everywhere in the dom tree.

Ok,lots of data on the wire, but it was just another option for me (and maybe I could go and store viewstate in a db, just to save some bandwidth...) and I couldn't see the evil there.

Moreover, I wonder why you think that page methods are for guys who pretend to do ajax development without writing js... I've used page methods and I really like Javascript.

Now I have static methods and I'm not going to blame them, but really I don't uderstand why I should go and have a party :)

re: More MS Ajax Pain
by Luis Abreu October 24, 2006 @ 8:11 am

Hi Garbin.

well, i think you didn't get my point. as I've told you, static page methods calls won't give you the performance hit associated with the old instance page method call. the value-added for static method calls is simple: you no longer need to build a web service for making a remote method call as happened in the previous releases.

"Ok,lots of data on the wire, but it was just another option for me (and maybe I could go and store viewstate in a db, just to save some bandwidth...) and I couldn't see the evil there."

ok, agreed...maybe they should exist, though i'd really appreciate that the guys that really praise it would al least tell us the performance hit we're having when we use it.

regarding the Javascript thingy, what i meant was that since instance page methods are not really performant and since there aren't really much things that need it (I still haven't found one thing that needs it, but i'm sure that there is - maybe having a private field stored in viewstate is the only thing i can remember now), i do really think that a "real" ajax page should really make remote web service method calls (or static page method calls) when it needs server side processing. the only thing that prevents that is not knowing or not wanting to know Javascript since the only real advantage I see on those kind of method calls (instance method) is that you never leave the confort the server side coding (which is really a lot better than the client side)

Maybe we can have both things, ie, instance and static remote method calls and then everyone would be happy with it. at least, that's what i asked here: http://msmvps.com/blogs/luisabreu/archive/2006/10/24/Page-methods_3A00_-why-I-prefer-them-to-be-static_2E002E002E00_.aspx

please make no mistake: still think that instance page methods should be removed, but since there are so many guys out there that depend on it, maybe the team should bring it back.

re: More MS Ajax Pain
by Peter Bromberg October 24, 2006 @ 11:56 am

Rick,
Thanks for the heads-up on the issues. Right now my time is limited and I'll stick with Anthem.Net (which project I've contributed to, for the AutoSuggestTextBox control).

Once you trailblazers indicate that ATLAS (AJAX, MAP, whatsis anyway?) is ready for prime time, I'll be jumping on board all four feet first.

Pete

re: More MS Ajax Pain
by Rick Strahl October 24, 2006 @ 1:27 pm

Luis, frankly I think you're missing Garbins and my point. It's simple: There's no real value add here - this is DUPLICATED functionality from Web Services with the only difference being that you don't have to create an ASMX file. And you're telling me I should start whining? <g>

I feel pretty strongly about this because I think the old mechanism adds value where as the new one does not. Ideally I would like to see both supported (preferrably not with the unobvious static/non-static behavior but with attributes).

If you want to do things the 'proper' way separating your business layer you can already do that already with ASMX, so you're not losing anything by not having static page methods.

I understand and have always mentioned that page methods push a lot more data and run through the full page cycle - but that may very well be a worthwhile thing if you're dealing with lots of data. It's what has differentiated PageMethods from Web Service calls.

Heck I'd even settle for page data just being posted back without going through the page cycle. So you'd get your parameters passed AND a full POST buffer with all the current data. Again this could be controlled by an Attribute. Although this will get tricky given the UniqueId isn't available in the static method.

>> Is it that hard to write document.getElementById("bla") to get a reference to a control in order to get its value?

Not hard, but a) it's tedious on the client, b) error prone (transcription), c) no way to know if it fails until runtime, d) not portable if you decide to move your page into a master page or out of a master page and finally (client control naming) e) it's duplicated work (on the server you'll have to retrieve those method variables and stick them into a business object/datarow whatever). It's an extra step that might not be necesary.

None of this matters much if you pass one or two values to the server. It does matter a lot if you want to send a full form's worth of data to the server. Creating methods that have 20 parameters or special 'parameter objects' just so you can pass a bunch of variables to the server gets old REALLY quick!

re: More MS Ajax Pain
by Rick Strahl October 24, 2006 @ 1:37 pm

Bertrand,

>> when you want to manipulate a server-side control from different points in your page, you don't create a new control every time, do you? You just create it once and get/keep references to it.

Fair enough - but the big difference is that the server side sets up the permanent reference for you. On the client there's no such thing. Once you know I suppose this makes some sense to just define your 'controls' in the startup code for the page and then reference them.

But where is the Control architecture documented? <s> This is one of those things that is non-obvious until you fail and then start looking at the script source for the framework. I also think that the script library should be smart enough to detect that the control already exists and exit and just return the existing object. Why the failure?

The reason I think this might be required is that the way I tend to think about JavaScript is not at the 'page' level but at the function level because that's the way things have worked in the past. I realize ATLAS is changing some of those concepts, but without the framework taking full hold and designer support I suspect most people will utilize bits and pieces of the framework and not opt in to the whole framework as a full page cycle controller. Conceptually this will have an effect on things like instancing and how one expects to use functionality.

I think you guys at Microsoft are like 3 steps ahead of everybody else because you have a vision in your head of how all of this is supposed to work in the end. I on the other hand don't have that vision yet because you haven't exactly outlined it yet <s>... so I have to struggle with my existing understanding of JavaScript and combining it with the server ASP.NET model efficiently.

re: More MS Ajax Pain
by Steve from Pleasant Hill October 24, 2006 @ 4:15 pm

I applaud you Rick, and others, who have the stomach for this. Some people need to grind away at the cutting edge, regardless of the pain factor, because it is part of their 'job description'. Others will wait for the framework to settle down.

One of the attractions for me of ASP.NET was that the .NET framework simplified and streamlined much of the web development process, Javascript included. I, personally, do not like keeping track of large amounts of Javascript. The whole ATLAS project seems to be looking for the right balance -- until then one should expect to have to rip out a lot of old code. It would be nice if a 'damage control assessment guide' was published with each release, as this could probably save people some debugging time!

DotNetSlackers: MS AJAX Beta1 - ClientScript is dead, long live ScriptManager
by DotNetSlackers Latest ASP.NET News October 25, 2006 @ 1:51 am

re: More MS Ajax Pain
by Rick Strahl October 29, 2006 @ 2:55 am

Steve, actually Microsoft has published a rather large 50 or so document with changes. But it doesn't cover nearly all the things that have changed. <s>

Remember this spring you were a bit disappointed at ASP.NET connections that I didn't do a lot on ATLAS (because I started running out of time really)? But think about it from the perspective of presentation: Whatever I would have shown back then is completely obsolete by now in specific syntax and even in broad terms.

So much has changed. Now imagine this beta making even more changes and confusing matters even more by the marketing madness of Red and Green pills - eh, bits, RTM and Value-Add versions and a proposed release version that will be missing a lot of the features that were part of the allure of ATLAS in the first place.

It really bugs me because it keeps us going on the beta treadmill even past the V1.0 release, while everybody's holding their breath and waiting for a final ATLAS release that won't be here until sometime next year or maybe not until Orcas (2008?).

In the meantime third party goodness has been stifled by the 'promise' of ATLAS... I'm just glad people like Jason Diamond (Anthem .NET) and Michael Schwarz (Ajax.NET) as well as third party vendors didn't get discouraged and kept improving their products in the meantime.

Agile Ajax: Even Microsoft Needs a New Development Approach with Ajax
by Agile Ajax October 29, 2006 @ 3:12 pm

RichardSoeteman.NET - October, 2006
by RichardSoeteman.NET November 01, 2006 @ 6:04 am

RichardSoeteman.NET - October, 2006 Weblog

re: More MS Ajax Pain
by Ego November 09, 2006 @ 5:05 am

I completely agree to Rick. What is an add value from static methods? I'm migrating from anthem.net to atlas beta 2 now and everything was fine, before I found this "feature". It a nightmare to use such methods! For example I have a TreeView with checkboxes. Checkbox checked on parent node means that all childs are checked too. This is 1000 times easier to calculate checked nodes on server, not on client side!

I'm have 2 ways now. Again use anthem.net only for those methods call (I hate this way), or use ICallbackEventHandler (I don't like this too).

RichardSoeteman.NET - Van ATLAS CTP naar ASP.NET Ajax 1.0 Beta
by RichardSoeteman.NET November 12, 2006 @ 6:13 pm

RichardSoeteman.NET - Van ATLAS CTP naar ASP.NET Ajax 1.0 Beta Weblog

Atlas to ASP.net AJAX: Cascading Drop Down
by Steve Clements July 05, 2007 @ 6:59 am

Page methods: why I prefer them to be static... - LA.NET [EN]
by LA.NET [EN] July 05, 2007 @ 12:17 pm

MVP's worldwide

SlideShowExtender and database integration, c# newbie - ASP.NET Forums
by ASP.NET Forums July 12, 2007 @ 6:21 am

Bilal Haidar [MVP] : Create Client Controls in ASP.NET 2.0 AJAX 1.0 Extensions
by Bilal Haidar [MVP] July 12, 2007 @ 5:55 pm

I kindly invite you to check my latest article on the www.aspalliance.com : Create Client Controls in ASP.NET 2.0 AJAX 1.0 Extensions In this article Bilal Haidar demonstrates how to create a basic client control Grid with Edit/Delete/Create functionalities

re: More MS Ajax Pain
by John July 23, 2007 @ 7:53 pm

Have any of the releases on codeplex or the rtm fixed this static requirement for pagemethods? I'm still searching Google, but not finding that this has been fixed yet. Oh how I miss Anthem.net.

re: More MS Ajax Pain
by Sorin Serban January 10, 2008 @ 2:28 am

I had something like that with 2 controls and the infamous "invalidOperation". It involved two pages one nested in the other in an Iframe and both containing an updateprogress control. The fix was to remove the updateprogress from the page contained within the iframe.

See here: http://sorin.sese.ro/blog/?p=40

Grats Rick on your blogs. Always a pleasure to read them.

re: More MS Ajax Pain
by sohpet May 09, 2008 @ 8:01 am

thanks