[
Lists Home |
Date Index |
Thread Index
]
Miles Sabin <miles@milessabin.com> wrote:
| Arjun Ray wrote,
| Using an XPath-derived string template syntax it ought to be possible
| to ensure well-formedness.
In the sense that the XPath-ish expression must "compile" (ie parse), yes.
It has the virtue of naming element types only once (many of the web's
ills, I sometimes like to think, stem from the fact that names have to be
duplicated in physically separate tags).
| InnerXml _is_ printf ... but that doesn't mean we couldn't have
| something analogous to printf which has its nice features (domain-
| specific little language) without the risk of non-well-formedness.
I suppose by "nice features" you mean variable substitution, which is the
value of a template. I also assume that there's protection against the
classic printf disaster of short arglists.
| And that's likely to be a win, even in comparison with,
|
| > hf.aHtml(
| > hf.aHead(
| > hf.aTitle( "Example 3" )).add(
| > hf.aLink( )
| > .wRel( "stylesheet" )
| > .wType( "text/css" )
| > .wHref( new Uri( "/ss/style.css" )))).add(
| > hf.aBody(
| > hf.aP( "Hello World!" ))).accept( printer ) ;
|
| because we don't have to fight with Java's syntax.
I'm not sure how much fighting is involved. The Perl code, which is how I
prototyped this kind of stuff, didn't look much different: '.' was '->'
and ').add(' was ','. Method-chaining is a natural idiom in Perl, but
perhaps not in Java - it needs methods with "setter" semantics to return
"this" rather than void - and it all sort of looks Lispish (or maybe
APL-ish), but you don't have to string stuff together like this if you
don't want to. My first example was almost a parody of the tutorials on
how to use AWT. :-)
The big gain is a uniform way to assemble pieces in any way or style you
want, where wellformedness is an invariant of every assembly method.
I think the bigger fight is not with Java syntax, but with GP expectation.
The default mindset first time in the door is probably one of "I gotta
write strings, why can't I write strings?" It's a *concept*, needing a
process of abstraction, that <element attribute="something"> isn't really
a string. Get them thinking about trees, and I'd argue that Java syntax
is no great barrier, even though it isn't usually concise.
| How about this mish-mash of XPath and s-exprs,
|
| Element e =
| new Element(
| "html/("+
| "head/("+
| "title/text(%0),"+
| "link[@rel='stylesheet',@type='text/css',@uri=%1]),"+
| "body/text(%2))",
| { "Example 3", "/ss/style.css", "Hello World" } );
1. &Deity; forbid that I should make a mistake in *xpath* syntax!
(who catches that, how, and when? Looks like runtime to me.)
2. How do I splice other stuff? Or do I have to put the entire
tree into a single expression?
3. What about adding more than one child to an element?
4. Do concise arrays allow a mixture of heterogenous objects? How
do substitute subtrees in?
(I'll ignore problems such as typos with taxonomic names ('titel'), by
assuming that constructors in the background could be checking this,
especially if there were a validation option of sorts enabled.)
I'm really not convinced this is a win. Not to mention that XPath reeks
too much of Obligatory HighTech. I have to write a xpath-expr parser too
just to support this? Aiyaiyai!
| (again assuming concise array literals).
|
| It's not clear to me that an HTML-specific library provides any great
| benfits in either safety or readability. And if it supports all of HTML
| 4.01 it's going to be large ... and obviously applicable only to HTML.
| Oh, and BTW: Hungarian notation is an abomination ;-)
I agree (it wasn't quite Hungarian notation, except perhaps for the 'e'
prefix on the locals). Hungarian notation is a decent idea taken to a
ridiculous extreme.
The 'a' prefix on element construction methods and 'w' (for "with") on
attribute methods were necessary in order to prevent clashes with Java
reserved words. They could have been 'e' and 'a' too (or my preference,
'e' and 'q'). I like short names, but I know of others who prefer nice
long names like makeTitleElement(), and for whom line wrap is only a
reason to get a bigger monitor.
|
