Wednesday, September 12, 2007
Attributes Lost
All ASP.NET 2.0 controls accept an arbitrary collection of string-named and string-valued attributes in an Attributes property, populated with server-side C# statements such as:
ofCheckBox.Attributes["oDatum2"] = "23a";
string sDatum2 = ofCheckBox.Attributes["oDatum2"];
This example assigns the value "23a" to an attribute named "oDatum2" for a control with ID="ofCheckBox" and then fetches the value assigned into a string. Undocumented by Microsoft is that assigning an attribute value quietly replaces any prior attribute value with the same name.
Sometimes Attributes items are used to add control-specific information sent to a browser, but they are also useful as memo fields and for communication with client-side JavaScript. Although not documented by Microsoft, values of Attributes items are maintained with control state. They do not depend on view state, and after a postback they can be retrieved from controls server-side even if using the Page EnableViewState="false" option.
Looked at client-side, controls may seem to lose attributes. Use the JavaScript debugger to examine one:
var oCheckBox =
document.getElementById('<~% = ofCheckBox.ClientID %~>');
When "ofCheckBox" is the ID for an ASP.NET 2.0 CheckBox, the JavaScript debugger will not show properties of oCheckBox corresponding to any Attributes assignments made server-side. The attributes are not lost, however. They are elsewhere.
Some ASP.NET 2.0 controls generate HTML composites; CheckBox is one of them. Following are the ways, undocumented by Microsoft, in which some of the common ASP.NET 2.0 controls are translated to HTML elements:
Label -- span
TextBox -- input
RequiredFieldValidator -- span
CheckBox -- span (label, input)
RadioButton -- span (input, label)
DropDownList -- select
Button -- input
A CheckBox is translated to a span that contains a label and an input. Attribute items assigned to a composite control will be encoded as properties of the outermost HTML element. For a CheckBox, they will appear on the corresponding span. The ID for an ASP.NET 2.0 composite control, however, does not necessarily go to the outermost element. In particular, undocumented by Microsoft, it becomes the ClientID property of the input element for a CheckBox or a RadioButton.
In order to get the client-side value of an Attributes item named "oDatum2" that was assigned server-side to a CheckBox with ID="ofCheckBox" as ahown above, use a JavaScript statement like the following:
var oDatum2 = oCheckBox.parentNode.oDatum2;
Communication using Attributes items is one-way. One can create attributes and assign values to attributes client-side, as JavaScript object properties, but new attributes and attribute values will not be transmitted to a server with postbacks.
[Note: because of display limitations, characters "< " and " >" here are shown with a tilde ~ after or before them.]
ofCheckBox.Attributes["oDatum2"] = "23a";
string sDatum2 = ofCheckBox.Attributes["oDatum2"];
This example assigns the value "23a" to an attribute named "oDatum2" for a control with ID="ofCheckBox" and then fetches the value assigned into a string. Undocumented by Microsoft is that assigning an attribute value quietly replaces any prior attribute value with the same name.
Sometimes Attributes items are used to add control-specific information sent to a browser, but they are also useful as memo fields and for communication with client-side JavaScript. Although not documented by Microsoft, values of Attributes items are maintained with control state. They do not depend on view state, and after a postback they can be retrieved from controls server-side even if using the Page EnableViewState="false" option.
Looked at client-side, controls may seem to lose attributes. Use the JavaScript debugger to examine one:
var oCheckBox =
document.getElementById('<~% = ofCheckBox.ClientID %~>');
When "ofCheckBox" is the ID for an ASP.NET 2.0 CheckBox, the JavaScript debugger will not show properties of oCheckBox corresponding to any Attributes assignments made server-side. The attributes are not lost, however. They are elsewhere.
Some ASP.NET 2.0 controls generate HTML composites; CheckBox is one of them. Following are the ways, undocumented by Microsoft, in which some of the common ASP.NET 2.0 controls are translated to HTML elements:
Label -- span
TextBox -- input
RequiredFieldValidator -- span
CheckBox -- span (label, input)
RadioButton -- span (input, label)
DropDownList -- select
Button -- input
A CheckBox is translated to a span that contains a label and an input. Attribute items assigned to a composite control will be encoded as properties of the outermost HTML element. For a CheckBox, they will appear on the corresponding span. The ID for an ASP.NET 2.0 composite control, however, does not necessarily go to the outermost element. In particular, undocumented by Microsoft, it becomes the ClientID property of the input element for a CheckBox or a RadioButton.
In order to get the client-side value of an Attributes item named "oDatum2" that was assigned server-side to a CheckBox with ID="ofCheckBox" as ahown above, use a JavaScript statement like the following:
var oDatum2 = oCheckBox.parentNode.oDatum2;
Communication using Attributes items is one-way. One can create attributes and assign values to attributes client-side, as JavaScript object properties, but new attributes and attribute values will not be transmitted to a server with postbacks.
[Note: because of display limitations, characters "< " and " >" here are shown with a tilde ~ after or before them.]
Comments:
<< Home
Fascinating. One possible design solution would be to derive a new class from the base MS classes and inject microformat style divs to hold data for the javascript client to read.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home
Subscribe to Posts [Atom]