Tuesday, May 23, 2006

IPostBackDataHandler, Web controls that keep their data together

Making a Web Control is not complicated. but things get weird when they need to postback values. Well, how does a Web Control postback? It implements the Interface IPostBackDataHandler which exposes two methods:

public bool LoadPostData(string postDataKey, NameValueCollection postCollection)
public void RaisePostDataChangedEvent()

RaisePostDataChangedEvent should be called by LoadPostData, so you can just ignore it if you don't need it.
LoadPostData will not be called unless the WebControl is registered with the page for postback. I do this in the override of OnInit:
if (Page != null) Page.RegisterRequiresPostBack(this);
postDataKey is the "identifier" of the control, meaning that weird UniqueID with ":" instead of "_" separating the parent control ids from the children. You can use it or not.
postCollection is the Request.Form collection, The collection of all incoming name values.

example, a Label that also adds a hidden input field and handles the postback of that field value. Try changing the value from javascript and the text value will also change on postback.

public class UselessLabelPostback:Label,IPostBackDataHandler
{
private bool changed;
public bool Changed
{get { return changed; }}

protected override void OnInit(EventArgs e)
{
base.OnInit (e);
if (Page != null) Page.RegisterRequiresPostBack(this);
changed=false;
}

protected override void Render(HtmlTextWriter writer)
{
base.Render (writer);
HtmlInputHidden hih=new HtmlInputHidden();
hih.ID=this.ClientID+"_hiddenField";
hih.Value=this.Text;
hih.RenderControl(writer);
}

public bool LoadPostData(string postDataKey, NameValueCollection postCollection)
{
string s=postCollection[this.ClientID+"_hiddenField"]; //not using postDataKey
if (s!=null)
{
s=HttpContext.Current.Server.HtmlDecode(s);
if (s!=Text) RaisePostDataChangedEvent();
this.Text=s;
return true;
}
return false;
}

public void RaisePostDataChangedEvent()
{
this.changed=true;
}
}

Important:
This is a control inherited from a Label, that's why I chose to render the hidden input manually. This has a few side effects. For example, the id of the label will be ucIPostBackTest1_UselessLabelPostback1 if the control is inside a User Control called ucIPostBackTest1. The id of the hidden field will be ucIPostBackTest1_UselessLabelPostback1_hiddenField only because I used the ClientID of the label when I manually set the field ID. For the same reason the name (the name attribute of a html item is the one that gives the postback identifier, not the id) will be the same.

The way to do it when starting from scratch is to add extra controls in the CreateChildControls() overriden method, use EnsureChildControls() in the PreRender or Render methods and the web control will render them all. Here the names and ids of the rendered child controls will differ and this is where the postDataKey comes in. But that's another story.

1 comments:

Anonymous said...

many thanks for your post.

it's clear that MS missed an important line of code:
"
LoadPostData will not be called unless the WebControl is registered with the page for postback. I do this in the override of OnInit:
if (Page != null) Page.RegisterRequiresPostBack(this);
"

http://msdn.microsoft.com/en-us/library/bkhywh0b(v=VS.100).aspx