[
Lists Home |
Date Index |
Thread Index
]
Miles Sabin wrote:
> Elliotte Rusty Harold wrote,
> > At 10:40 AM -0600 9/21/02, Aaron Skonnard wrote:
> > > Yes, both MSXML and the .NET implementation have supported this
> > > through the Inner/OuterXml properties.
> >
> > Now that you mention it, I have seen that. I had filed it away at the
> > back of my brain as "horrid, ugly, non-standard extensions to
> > JavaScript and DOM" and promptly forgotten it once I finished working
> > at the company that was using it.
>
> That's always been my reaction too.
>
> But on reflection (and playing devils advocate a bit) maybe it's not as
> unreasonable as it seems. [...]
> To illustrate, compare,
> [...]
> String s = "InnerXml";
> int i = 2;
> Element usability = new Element("usability");
> usability.add(new Attribute("factor", Integer.toString(i)));
> usability.appendChild(s);
>
> vs.
>
> String s = "InnerXml";
> int i = 2;
> parent.appendChild("<usability factor=\"+2+"\">"+s+"</usability>");
>
> Why do these string-template approaches support such dramatically more
> compact and readable code? I think it's simply because the syntax of
> the template-strings provides a domain-specific "little language" which
> is better tuned to the task at hand than the generic mechanisms
> provided by the host language. I guess things like embedded SQL, for
> all their ugliness, do much the same job.
With the right host language, it's often possible to embed
a domain-specific language using features of host language itself.
Tcl, Haskell, Scheme, Python, and Forth all have good
syntactic extensibility.
For example, here's how I'd write the above example in Tcl:
xml::element usability factor $i { xml::text $s }
and in Haskell:
mkElement "usability" (mkAtt "factor" (show i)) (mkText s)
Granted, neither of these look a *whole* lot better than the first form,
but that's mostly because the example is so short and the constructed
XML isn't very deeply nested. When it comes to even more slightly
complex output structures, though, I think they're both a clear win
over the explicit node-at-a-time DOM interface and the InnerXml/
document.write() approach:
xml::element HTML {
xml::element HEAD {
xml::element TITLE {
xml::text $Title
}
xml::element LINK type text/css href stylesheet.css
xml::element LINK rel next href [nextDocument]
xml::element LINK rel prev href [prevDocument]
}
xml::element BODY {
xml::element P {
xml::text "Hello world!"
}
}
}
> So maybe the answer would be to come up with a template string syntax
> that's more idiomatic for XML than printf style. How about something
> XPath-like? For example,
>
> String s = "XPath expansion";
> int i = 2;
> parent.appendChild("usability[@factor="+i+"]/text("+s+")");
>
> or if we waited for J2SE 1.5 which'll have auto-boxing and concise array
> literals, we could even have,
>
> parent.appendChild("usability[@factor=%i]/text(%s)", {i, s});
>
> Thoughts?
Well, if you insist on using a Java-like language to process XML,
that's probably the best way out :-)
--Joe English
jenglish@flightlab.com
|
