Posted by: Jon Henning
4/13/2008 

While sitting at the airport waiting for my plane to depart to the MVP Summit, I decided to spend a little time optimizing the new ClientAPI (codenamed Caspian) for the Cambrian release.  One of the new features for this release was to allow the output of the ClientAPI and Webcontrols to emit compliant markup (more detail mentioned in this blog).  There was two areas that this affected my code.

1.  The ClientAPI allows for state to be passed to and from the server via a hidden control on the page (ClientState).  This is similar to ViewState, except that it can be read and written to on the client.  This used to be serialized as a delimited string.  The question has always been, what delimiter can you use that is safe?  Originally the ClientAPI used custom escape characters for this, but as the community strongly stated, these characters were not compliant.  Ironically enough, the MacIE version of the browser choked on these characters, so the original implementation allowed for the single-character delimiters to be swapped out with 3 character delimiters via the ClientAPICaps.config file.  Community members caring about compliance simply switched their config file to emit these three characters for all browsers.

2. The other area at issue with compliance was the use of expando properties in the webcontrol's main markup.  For example, the properties for a control would use markup similar to this

<div id="menu" MouseOutDelay="100" MenuBarCss="menubar" ....

This made things very convenient for both the control developer and people troubleshooting their controls, as the properties were right next to their respective markup.  The negative being that the use of custom expando properties was not complient.  For the Caspian/DawnTreader release these expandos were moved to the ClientState feature and serialized as JSON.

One of the negatives to serializing this to JSON is that it still needs to be encoded.  JSON's use of the " character for strings proved to be a major drawback as it gets encoded into &quot;. 

nodes[{txt:"Home",id:"0"

becomes

nodes:[{txt:\&quot;Home\&quot;,id:\&quot;0\&quot;

Some people in the community have also suggested to simply use base64 encoding.  However, this also ends up with a payload much larger than desired.  The solution that I just added will detect if a compliant character is contained within the json already and if not send down a substitution character for the ".  If the character is already contained within the json, the default &quot; will be used. 

{nodes:[{txt:\`Home\`,id:\`0\`

Thats all for now, gotta catch my flight...  Hopefully I will have more time on the flight to catch up on more blogs I've been meaning to do.

Trackback Print

Tags:

Categories:

Location: Blogs Jon Henning Core :: ClientAPI