Introduction:
Last week, I spent a long time unpacking in a (hopefully) logical way that you can leverage the IE Default Behavior, userData to be a super cookie. Hopefully you found it useful or at least well written...maybe you just liked the font. Either way it represented the world "as I knew it". So being the proud papa that I am, I showed my latest effort to a co-worker here (Keith Pelletier, all around web and UI dude..that's really his title). Keith takes one look at it and says, "no, that's not true. I think..." And in the nicest possible way, systematically unravels my entire concept, in a good way of course. So this week's episode is a sequel to last week, kind of a Special Enhanced Edition, if you will, with all new special effects! While you read this, I'll be sitting down having a huge serving of Humble Pie..along with a cuppa Yorkshire (Gold preferred, splash of milk and a sugar).
No You Can't:
Last week I presented as FACT the following: userData's XML structure is fixed. You are forever stuck with the
<ROOTSTUB theValue="whatever" theValue2="whatever2" />
You need 1000 attributes? No problem. You need hierarchy? Problem - unless you jam that hierarchy into the attribute (XMLEncoding first..). It works, it works well but by my own admission - a bit of a hack. My knowledge of the "facts" was not based upon something Microsoft produced (scant amount of information out there on Behaviors...), nor based upon exhaustive research. My knowledge was based solely on the fact that this didn't work:
function Save()
{
var sXML = "<stuff><node1/><node2/></stuff>";
var oUD = theDoc.getElementById("theBody");
oUD.loadXML(sXML); //<======THIS DOESN'T WORK!!!!!!!!!
oUD.save("Episode4v1");
}
So with limited time (deadlines, deadlines..) I resorted to my personal nature...let's hack! I can save attribute values, and I can escape XML strings, so BOOM, my solution becomes THE SOLUTION. Let's save it as a string, recoding it before using..... Oh how pleased I was...I think I'll write about this, since I'm so smart and all.
Oh Yes You Can:
So up comes Keith, takes one look at it and says "woooaaaaahhhhh slow down, let's down shift here and try this again" (this is an actual quote). It's actually very simple...and that's probably why I didn't think of it. Not that I'm so smart but because I immediately jump to the complex, without looking for the simple alternative. Here's the idea:
You can append a child into the userData's document Element.
That's it. So simple I didn't see it. I immediately built this test page to demo. Here's how it works:
On the test page I've added a big content editable DIV that loads up a stupid example XML, but one with hierarchy, so I guess I should be nicer here. If you'd like to change the XML to something more pleasing, go for it. Then click the Save button. Function Save() does this:
var oUD = theDoc.getElementById("theBody");
oUD.load("Episode5v2");
First I go get the userData, loading it up with Episode5v2. Then I load up an MSXML DOM object, stuffing it with the XMLDiv's innerText. I then XPath to the <test> node and .selectSingleNode. As I note on the page, be sure to leave in the root node of <test>. I've hard coded it into the XPath, normally a bad thing, but this is just a demo.
oXML.loadXML(theDoc.getElementById("XMLDiv").innerText);
...
var oRUD = oUD.xmlDocument.selectSingleNode("//test");
oUD.xmlDocument.documentElement.removeChild(oRUD);
Then I made a conscious decision to destroy the XML inside the userData. Might seem a little heavy handed, but it makes sense. If you don't, your userData will just load up with all kinds of scum and that's no good. A clever person could be a little lighter handed, but again, it's just a demo.
Now I just grab the .documentElement of our newly created and loaded MSXML DOM object, .appendChild it to the userData (freshly cleaned out by the previous step and .save.
var oDI = oXML.documentElement;
oUD.xmlDocument.documentElement.appendChild(oDI);
oUD.save("Episode5v2");
To view the whole userData hit the "Show Me the XML"...and there it is: fresh XML, with hierarchy. No XML escaping hacks, exactly like you want it. I've added the "ShowMe" button so you can see just the XML that you've saved. It's not to far of a stretch to imagine using this XML for all sorts of interesting things.
You can still put attributes on the Root, just like before: <ROOTSTUB theValue="whatever" />. It's exactly the same.
var what = theDoc.getElementById("txtWhat").value;
var oUD = theDoc.getElementById("theBody");
oUD.setAttribute("theValue",what);
oUD.save("Episode5v2");
This creates/saves an attribute called "theValue" onto the ROOTSTUB which is unaffected by the comings and goings of the previous events. Pretty slick, eh?
To Conclude...
I haven't gone back into the "Monster" to address this. I like this solution because it feels like you are using the XML more precisely. I once worked on a project where we stored complete "off-line" versions of the HTML pages, so when you weren't connected to the Internet (like on a plane) you could still use our application. userData would've been pretty slick for this. Ahhh, this pie is very tasty, very tasty indeed.
An Aside:
I usually try to save this section to briefly discuss something interesting but not exactly on topic, like the try{}catch(e){} blocks that I'm using here. While gripping, I'm going to pass. Instead, this will be my little rant about learning new stuff, or more to the point, how important it is to admit your way is less right and something else is more right. Far too often, the developer begins to believe in his/her own infallibility. I've been doing this for "6 months/20 years" so how could I be wrong? But as I stated it earlier is the real point: It's not that your way is wrong, it's (usually for me) that somebody else's is more right. What you've written is code, electrons spinning around something, stored in ether. Absolutely ready for change and very pliable. This is not a granite block that you are toiling away at for years with a chisel and a toothbrush. I always try to be willing to change my code at the drop of the hat, if the schedule allows. Far too often I've seen and worked with developers who were unable to realize that their way might not be absolute and that changing their code is not like changing Abraham Lincoln into Pee Wee Herman on Mount Rushmore.....
The Finish Line:
Now I hope that I'm done with userData for at least a couple of weeks...I'm still planning on DHTML or Attached Behaviors for next week. Unless I have to change something, but hey, I like pie...
If anyone has any comments or questions, email me at ms_@_mybluecoat.com (remove the underlines first...) or use the nifty comment deal that Foo has added to AlphaFilter...and keep those cards and letters coming.