|
|
Re: Which Part of "No XML" Don't You Understand?
|
Posted: Jan 31, 2006 11:48 PM
|
|
I hate to be the lone dissenter here, but I kind of agree with the use of XML for web templating. I don't think that, using XML to generate XML is in anyway seeing XML a solution to an unrelated problem. It's seeing XML as a solution to a very related problem.
If I'm generating XHTML (which everyone should eventually be doing) it is XML. It makes sense to me that it is a better match to generate it from other XML. Especially due to the fact that XML is MADE to be transformed and proper namespacing completely separates the templating language elements/attributes from the content.
Note that it also has a few things intrinsicly solved. It's easy to move the template from program to program. It's in Unicode so it is by nature easily internationalizable (IMHO, this is the most overlooked value of proper XML handling).
As for being "confusing" when the templating instructions and template are being mixed (both in XML), that's what namespaces are for. Not that Zope Page Templates are my favorite thing, but it's obvious that everything that either has a tal: or metal: in front of it is templating.
Now, I think that most of the XML stuff that gets into processing directives, odd entities, and other stuff is a waste of time. I think XPATH goes a bit overboard with its more involved syntax. I think that XPointer should be simpler. I think XSLT is completely unusable for templating (although it's made for transforming, which isn't the same thing). I think no one has properly handled schemas and DTDs in a way that I can stomach.
However, XML for generating XHTML is simply a good match for 95% of templating. Bottom line, to know enough to properly generate XHTML, I can properly generate namespaced-templated XML. I certainly am not a fan anything like Nevow's Stan. I like Twisted a bunch. I've used it for unspeakably cool and horrible things. However, the abuse of syntax in Stan makes me angry deep inside.
I do not dispute that editing XML by hand slows down programmers that really have better things to do. However, I don't believe that programmers should be writing the XML directly anyways.
This is my issue with Stan--it is programmer shorthand for XHTML. I prefer to hand generate the XML document and then transform it with clean Python code. I think that this has yet to have a good general-purpose implementation, but I firmly believe that generating the XML template entirely in code roots us in a world where you can't delegate content development because the template is tied to strongly to the code for people to specialize in the content (not in coding). Having other people generate and contribute to my sites saves me more time than abusing __getitem__ saves me keystrokes.
For the record, I'd go further to even suggesting that XML SHOULD be strongly considered for configuration files. This is not ideal right now, but it's simply a matter of having the right editing tools. Look at the configuration interfaces generated by Microsoft's Policy tools (or the older, better schema driven Novell NDS Administration tools). They're all generated from simple text files that could be easily expressed in XML. It could also be implemented on the console in a manner similar to Linux's "make config" and "make menuconfig". It's crying for an implementation, in fact, I'll go do that now...
My approach is that XML should be used for templating and configuration but that the programmer should not have to touch it directly either. It's not as easy, yet, but I don't think that anyone can deny that its not a acceptable to use, say, QT Designer as a tool to generate a GUI interface (or the base for an GUI interface). We simply need some standard languages with good tools to write them. XML fills this need as well as anything else right now.
|
|
Previous Topic
