... until the collector arrives ...

This "blog" is really just a scratchpad of mine. There is not much of general interest here. Most of the content is scribbled down "live" as I discover things I want to remember. I rarely go back to correct mistakes in older entries. You have been warned :)



What I was trying to do was create a DOM object that contains all of the ASP request variables, and feed that into an XSL program that computes the page.  It was a bit tricky:

<%@ Language = "JScript" %>
var xslDoc = Server.createObject("Msxml2.FreeThreadedDOMDocument.3.0");

var xmlDoc = Server.CreateObject("Msxml2.DOMDocument.3.0");

var parametersDoc = Server.CreateObject("Msxml2.DOMDocument.3.0");
var parameters = parametersDoc.createElement("parameters");
for (var k = new Enumerator(Request.queryString); !k.atEnd(); k.moveNext()) {
    var key = k.item();
    for (var v = 1; v <= Request.queryString(key).count; ++v) {
        var p = parametersDoc.createElement(key);

var xslt = Server.createObject("Msxml2.XSLTemplate.3.0");
xslt.stylesheet = xslDoc;
var xslProc = xslt.createProcessor();
xslProc.input = xmlDoc;
xslProc.addParameter("parameters", parameters);
Response.contentType = "text/html";

The trickiness lies in the bolded code.  Note the use of an Enumerator object, that collections use one-based indices, and that collections are indexed using function-call notation instead of array-index notation.

The next step would be to persist state in a session variable, passing that state in as a document to the XSLt and storing back the updated state returned by the XSLt (hiding it, say, in the <HEAD> tag of the HTML).  Alternatively, there could be two XSLt programs involved:  one to compute the new state and one to render the output.

Blog Archive