Wednesday, March 28, 2012

PageMethods and NON-Static methods

OK, after 4 days of trying every possible combination of everything... I *finally* figured out how to get PageMethods to work. The myth of "it can't be in the code behind" is completely wrong, however I'm starting to see that "the method but be static" is NOT a myth.

How in the world am I supposed to update the GridView then?

Your first response should be ...

<asp:UpdatePanel ID="upComparisonData" runat="server">
<asp:AsyncPostBackTrigger ControlID="btnComparisonNavigate" EventName="Click" />

That's beautiful... works great... BUT... I need to do more than merely update. I can't just update, there's some purely client-side custom validation I *MUST* do. There are many components on this application which were created in purely client-side XHTML and ECMAScript DOM. The above code will NOT work for me because I have to set all kinds of status bars, check other services (non-Atlas), and do validation as well as flip the status of quite a few objects around (turn DIVs on, turn DIVs off... etc...)... I mean there's a bunch of stuff going on in this app.

So... how in the WORLD do I access a GridView in my page from a static method? I have no problem with writing this entire thing custom... that's childs play, but I would much rather do this in Atlas so other developers don't have to try to decode my ninja Ajax code.

"The myth of "it can't be in the code behind" is completely wrong"

it wasn't a myth on earlier versions (beta 1 i believe) and probably has been fixed in the two releases since then, hence the "myth" is no more

Good deal..

Anyone know if THIS *critical* design flaw has been fixed?

If everything you're doing is purely client-side, then instead of trying to use PageMethods to update your panel, just put a display:none button in your UpdatePanel and call it's .click() from the clientside:



That causes a postback, even in the UpdatePanel (which obviously defeats the entire purpose of the UpdatePanel). This entire application has absolutely NO postbacks. I'm not about to add one now.

I worked around that situation by rewriting a TON... now I have another situation which a rewrite is simply not possible.


var prm = Sys.WebForms.PageRequestManager.getInstance();
function PageLoadedEventHandler() {
// custom script

this will be execute after updatePanel... ;-)


well, if you're chaging UI during a partial request, you do really need to use an updatepanel. if you only need to check for values, why not pass them from the client to server as method parameters?
That's obvious... of course you need an UpdatePanel, but I'm not going to use triggers... that is completely useless.

What? I'm confused... how does that update a GridView on a whim?

I simply want to update a control from ECMAScript. There are many things that our library does to the application, so giving ALL the control to Atlas would be pointless. I need something that will allow a control to be updates via a simple client-side call, not a trigger which doesn't allow your own manipulations, or the useless PageMethods which in no way allows for updating of controls.

For now I'm just going to do this manually... have an ASPX page with the GridView and have an XmlHttp call to the page and do a screenscrape of the control, do a simple DOM parse, and DOM child. Not that difficult... I was just hoping Atlas did this for you as not everyone who works on this application knows Ajax programming as well as I do.

No comments:

Post a Comment