Ken Brubaker

The ClavèCoder

<January 2009>
SuMoTuWeThFrSa
28293031123
45678910
11121314151617
18192021222324
25262728293031
1234567


Navigation

Subscriptions

News

Kenneth Brubaker
Senior Application Architect

Locations of visitors to this page

Post Categories



Thursday, September 02, 2004 - Posts

ASP.NET: Posting back dynamic data

One of the benefits I have now that I'm a “Corporate Architect” is that I don't just deal with the technology I'm currently working on. Now I have to know everything all at once. Whether that means I'll be rust free or just worn out remains to be seen. :-)

A colleague was working on a custom ASP.NET control that was accepting DHTML drop information. He wanted to be a good citizen and use the Page.GetPostBackEventReference method. This method produces a string that is called from the client side, usually as a control event handler.

However, in his case, he needed to get the drop text dynamically, so his event handler called a function to get that. He also passed the result of GetPostBackEventReference, and called eval on its value to do the post back.

Well, that's fine. However he wanted to pass back the value of the dropped text. Since this is determined dynamically by the user GetPostBackEventReference is useless. It's output is:

"__doPostBack(<Mangled CtrlID>, <static string text>)"

The whole idea being that the identifier of the post back routine and the server-side identifier of the control should be hidden to the script writer. This works great as long as the information you want to post back is static.

He asked the “Right Way” to do this.

It's interesting that Dino suggests to just set the hidden post back variables yourself and avoid __doPostBack entirely. (See Handling the Server-Side Event) Not exactly great tasting from the encapsulation point of view.

I'm guessing there is really no good way to do this. If you look at the function's output, we've got three four bits of data:

  • The function identifier
  • The function signature
  • The control id
  • The data argument placement

You would really need to have an abstraction method that would output a function that would take the data argument and embed the call to __doPostBack. That doesn't taste good either. It appears to me that if you want to be a good citizen the control should manage a hidden field and pick that up when the RaisePostBackEvent method is called. Look here for more info on how to do that.

Rats. The RaisePostBackEvent argument is useless for dynamic data.

 

posted Thursday, September 02, 2004 7:59 AM by kenbrubaker with 0 Comments




Powered by Dot Net Junkies, by Telligent Systems