Weblogs Forum - Which Part of "No XML" Don't You Understand?

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Which Part of "No XML" Don't You Understand?

59 replies on 4 pages. Most recent reply: Mar 7, 2006 6:39 PM by Robin Parmar

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 59 replies on 4 pages [ « | 1 2 3 4 | » ]

Tim Parkin

Posts: 3
Nickname: timparkin
Registered: Jan, 2006

Re: Which Part of "No XML" Don't You Understand?

Posted: Feb 1, 2006 1:28 AM

"HTLM is much more forgiving than XML. Do you ever type ? Or or <hr/>? Do you always add quotes around argument values? Etc."

Ahh... I can see your point about xml not making as much sense now. I was presuming that you were using (x)html for your web pages and as such they would be valid xml documents.

If you are generating html (which can be non valid xml) then the use of xml for the templating doesn't make as much sense at all (html in this sense is just a bad *xml based* content markup language).

We only work with valid xhtml1 and using xml in the templates makes sense as we can validate templates on import, ensuring that our end documents always validate.

It seems that your (the) requirement is a more general *anything* templating language - a string substitiution language with the possibilty of embedded python.

David Guaraglia

Posts: 1
Nickname: dguaraglia
Registered: Feb, 2006

Re: Which Part of "No XML" Don't You Understand?

Posted: Feb 1, 2006 5:36 AM

Well, in fact I think that most template system developers like XML because of the simple fact that it's easily parseable. Another fact to recognize, is that XML is usable in a lot of cases, so doing a template engine based on XML renders you a template engine that works in lots of cases, not just webpages.

Sometimes you just want to use some "not so clean" HTML 4, or even something else. That is when XML parsers break down. There are lots of engines that take care of this cases (Cheetah, for example) and some of them are usable inside bigger frameworks (e.g: Turbogears has support for Cheetah).

So you must either choose one and integrate it into your framework of choice, or build one, all depends on your needs. May I ask what do you need? :)

JOhn Mudd

Posts: 5
Nickname: johnmudd
Registered: Dec, 2005

Re: Which Part of "No XML" Don't You Understand?

Posted: Feb 1, 2006 6:11 AM

It seems ironic to me that your upset about having to use XML in a template. After all, what is a template but Python code embedded in HTML. So you've already decided you want(?) to hand code HTML but you can't stand the thought of hand coding a little XML?!?! I'm confused.

Nobody likes XML being misapplied more then me so I have no complaint with you turning up your nose to XML. But, unlike you, I have a similar distaste for hand coding HTML. So... skip both! Use Stan with Nevow and you can generate all

Kevin Marks

Posts: 6
Nickname: kevinmarks
Registered: Jan, 2006

Re: Which Part of "No XML" Don't You Understand?

Posted: Feb 1, 2006 3:09 PM

> HTLM is much more forgiving than XML. Do you ever type
> ? Or or <hr/>? Do you always add quotes around
> argument values? Etc.

Well, I do, but generally I do it once in the template. If you are generating HTML automatically, it's worth the little extra effort to make it validate, as that makes life much easier when you are styling it with CSS.

The underlying point about HTML being forgiving is well-made, and fits in with the microformats philosophy of making things easier for authors even if it makes it a bit harder for parser writers.

http://microformats.org/about/

has

Posts: 15
Nickname: has
Registered: Nov, 2004

Re: Which Part of "No XML" Don't You Understand?

Posted: Feb 1, 2006 5:21 PM

Guido wrote:
> Anyway, I don't want a DOM manipulation tool either, because it will end up creating a pretty tight coupling between the HTML and the Python code manipulating it -- probably tighter than for Cheetah/Django/etc. style templates.

You misunderstand the intentions of DOM-style templating (or one of them anyway). The point is to separate presentation code from presentation markup, whereas with macro-style engines presentation code is embedded in presentation markup. The level of coupling, however, is unchanged: it's tight in either case.

Now, what DOM-style systems do *not* do is *enforce* loose coupling between presentation code and model code; they leave that choice entirely at the *developer's* discretion. Whereas most macro-style templating systems enforce loose coupling between presentation code and model code simply because each is created in a completely separate context - in many cases they're not even written in the same language - with only limited connectivity provided between the two.

This is where the confusion arises, as casual onlookers forget that the distinction between presentation and model logic is a *conceptual*, not physical, one. Now, you can argue the virtues of bondage-and-discipline vs. do-as-you-like environments all day (in which case the respective Java and Lisp camps are that-a-way...), but ultimately a bad programmer will manage to write badly structured code in any environment, while a good programmer is completely capable of writing well structured code in either.

To quote myself from the previous comment thread:

"""A good comparison is to the View and Controller layers in Apple-style MVC.

In Apple MVC, the View layer consists solely of graphical widget objects, assembled live and stored in serialized form (.nib) using Interface Builder, and the Controller layer contains the glue code that pulls data from the Model layer and inserts it into the View objects.

With DOM-style templating engines, the tagged HTML file is analogous to the .nib file, the templating engine = the AppKit framework that turns this data back into live objects, and the Python code that manipulates these objects = the Controller layer."""

I think that sums it up the architecture pretty well, and given the frequent praise that developers heap on 'the Cocoa way', who am I to argue? :) (In fact, back when I designed HTMLTemplate, this is where I stole most of my influences from.)

Personally speaking, I've done Cocoa GUI programming for a number of months and DOM-style templating for the last few years and in both cases I have absolutely no problem maintaining loose coupling between my presentation and model logic whenever I want to. The whole "X causes tight coupling" is an absolute canard in every case where X != "early Fortrans", "early BASICs" or "crap programmers"; and since nobody still uses the first two that kinda narrows it down a bit. ;p

HTH

Jim D

Posts: 7
Nickname: bogtha
Registered: Feb, 2006

Re: Which Part of "No XML" Don't You Understand?

Posted: Feb 1, 2006 5:37 PM

> HTLM is much more forgiving than XML. Do you ever type ? Or or <hr/>? Do you always add quotes around argument values? Etc.

I think it's quite bizarre that the creator of *Python* is advocating that a more flexible syntax is better. It seems like the complete opposite of Python's enforced indentation rules, forbidden "while foo = 'bar':", etc.

Would Python be better if it were more "forgiving"? Or does a stricter, clearer syntax with one way to do things have benefits?

It's true that on average, you have to type a little less when writing SGML-based languages than XML-based languages. But in return you get a more regular syntax, less bizarre exceptions to the rule, simpler parsers, etc.

For instance, why is <a href=foo.html> okay but <a href=http://www.example.com/foo.html> not okay unless you add the quotes? Only people familiar with the depths of SGML understand why.

Is it better to force people to memorise exceptions to the rule, or is it better to merely enforce the common case that works in all circumstances? I was under the impression that the latter choice was one of Python's principles and strengths, and yet you seem to be arguing against it here. Why?

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: Which Part of "No XML" Don't You Understand?

Posted: Feb 1, 2006 5:44 PM

Because "productivity > theoric gains". For instance, if you can only edit a file using special editors, then you burn the possibility to use less specific editors when you need to. Would you be happier with a Python version that was XML based? What if GUI is not always available for edition of XML? By the way, why not enforce indentation of XML just like Python's? :-)

Christopher Hunter

Posts: 4
Nickname: chunter
Registered: Nov, 2005

Re: Which Part of "No XML" Don't You Understand?

Posted: Feb 1, 2006 7:52 PM

I'm glad someone's willing to 'stick it' to a big lemming standard.

I like XML as a concept for storing data in an easy-to-fix, human-readable way.

I like XML as a universal way to share data between programs.

I despise the notion that XML should be any more than that to anyone, but I know it happened anyway. What can you do?

XML makes uncomfortable, unreadable configuration files.

XML libaries that automate the creation and editing of such files simply serve as pairs of rubber gloves, for folks that don't want to touch the offending file.

Unfortunately, van Rossum is not specific about the problem that he's not choosing XML to solve, but from my point of view, if I can parse my hypothetical template with a few regex lines, I'd much prefer that to messing with SAX and DOM.

Best wishes

Marc-Antoine Parent

Posts: 1
Nickname: maparent
Registered: Feb, 2006

Re: Which Part of "No XML" Don't You Understand?

Posted: Feb 2, 2006 1:51 AM

Dear Guido.

I am not a Python luminary like some of the writers here, but I am a serious python user nonetheless, even sometimes getting paid for python work I do.
I am also someone who uses XML-based technologies a lot. So, in response to your post, I have two things to say:

a) You are in a position to standardize templating mechanisms. I understand you may not be fond of XML-based templates, but I hope that you will not standardize on a solution that excludes them. Your comments about wanting a generic templating API reassure me, but I would like to emphasize that some Python users have become python users because of XML templating mechanisms, believe it or not. (In my case, the first python program I got paid for used Nevow. Off topic, one of the things that got me excited about Python was Philip's "scary" dispatch mechanisms!) Anyway, please do not standardize on something that locks us out.

b) At the risk of sounding like I insist too much... I beg to differ on your opinion that XML is appropriate to be edited by human. Quite the opposite: With a schema-aware editor (I personally use nxml in Emacs) XML is actually easier for a human to get right than most other formats, since checking happens as you edit, not in a later stage (even such a simple later stage as a browser reload.) In other words, XML allows for your code (whether it's templates, configurations, or structured data: It's designed to be machine readable, so it's code, and has to be valid) to be checked instantly as opposed to in batch, which reminds me of the distinction between an interpreter and a compiler. Would you not prefer the former? ;-)

Also, XML looks verbose, but a schema-aware editor will do at least half of the typing for you; when editing some well-constrained data format, I have experienced typeahead of up to 75% of my XML code. Granted, templates do not reach that level of internal constraints; esp. because most schema-aware editors do not handle multiple namespaces very well yet. But that is certainly something that is slowly being solved in the XML world.

Anyway, my 2 cents on XML templates...

Marc-Antoine Parent

Danny Ayers

Posts: 4
Nickname: danja
Registered: Oct, 2005

Re: Which Part of "No XML" Don't You Understand?

Posted: Feb 2, 2006 3:52 AM

The most intuitive templating I've played with have been the simple-insert stuff, macros or whatever embedded in the shell of a target page. Basically PHP before you start coding.

The point about mixing XML's angle brackets with (X)HTML's is well made. XSLT has a relatively straightforward programming model (elegant, even), yet the syntax makes it pain.

So assuming a mix of (X)HTML and some kind of simple insertions, where the latter has a syntax clearly distinct from XML, what are the options?

Invent something new? Bleeugh, already to many templating languages about. Existing candidates? Here's two:

=== Wiki-like Syntax ===
Pro: easy syntax
Con: designed for pure presentation, probably get messy if anything sophisticated was tried

(((s-expressions)))
Pro: easy syntax, clearly distinct from (X)HTML, could be simple for simple stuff, can extend into whatever level of complexity needed (via Lisp)
Con: different from Python syntax (but doesn't that apply to any templating?)

has

Posts: 15
Nickname: has
Registered: Nov, 2004

Re: Which Part of "No XML" Don't You Understand?

Posted: Feb 2, 2006 6:06 AM

> Is it better to force people to memorise exceptions to the
> rule, or is it better to merely enforce the common case
> that works in all circumstances? I was under the
> impression that the latter choice was one of Python's
> principles and strengths, and yet you seem to be arguing
> against it here. Why?

Marketing 101. The BDFL's goal is to sell *Python*, not XML. More people write HTML than write XHTML, therefore a system that works with either will appeal to a larger audience than a system that works with the latter. Conceptual purity and elegant theory are all well and good, but clearly those are not the #1 priority for the majority of developers otherwise we'd all be using Lisp by now.

To persuade Guido to go with an XHTML-only system, you'll have to show it provides other significant practical advantages that'll more than outweigh the cost of its antagonism towards HTML users: for example, it runs 10x faster or is 10x easier to learn or is 10x more powerful than all of the HTML-friendly alternatives. Otherwise you're just wasting your time - "practicality beats purity", as the Zen of Python says.

HTH

Peter Masiar

Posts: 2
Nickname: pmasiar1
Registered: Feb, 2006

YAML is to XLM what is python to [programming language here]

Posted: Feb 2, 2006 7:51 AM

YAML was designed to be read by humans. Structure is shown through indentation. White space is meaningful.

http://www.yaml.org/start.html

Not as templating language mind you - but for config files. Has python bindings too.

Jim D

Posts: 7
Nickname: bogtha
Registered: Feb, 2006

Re: Which Part of "No XML" Don't You Understand?

Posted: Feb 2, 2006 12:12 PM

> if you can only edit a file using special editors

XML doesn't require special editors.

> Would you be happier with a Python version that was XML based?

No, and I didn't bring anything remotely like that up. There's a difference between identifying common design strategies and wanting two syntaxes to be identical.

> What if GUI is not always available for edition of XML?

Have you ever edited XML? You don't need a GUI, you don't need special editors, you can edit with vi if you want.

> By the way, why not enforce indentation of XML just like Python's? :-)

Because XML doesn't distinguish between element types that are meant to be used inline and element types that are meant to be used as blocks. Both are common uses for elements in XML, and indentation is only useful for the latter.

Jim D

Posts: 7
Nickname: bogtha
Registered: Feb, 2006

Re: Which Part of "No XML" Don't You Understand?

Posted: Feb 2, 2006 12:16 PM

> To persuade Guido to go with an XHTML-only system

I wouldn't do that. I am currently happy with Kid. You write the templates in XHTML+Kid, and you can output HTML instead of XHTML by changing one line.

The *source* remains XHTML, but what everybody else sees is HTML. I consider that to fulfill your criteria for "a system that works well with either".

Eugene Lazutkin

Posts: 15
Nickname: elazutkin
Registered: Jan, 2006

Re: Which Part of "No XML" Don't You Understand?

Posted: Feb 2, 2006 12:29 PM

> The *source* remains XHTML, but what everybody else sees
> is HTML. I consider that to fulfill your criteria for "a
> system that works well with either".

What about generating other non-XML-based web-related stuff? Some examples from my experience: e-mails, CSV files, JavaScript stubs, PDFs, and so on. They are all text-based and can be easily templated.

Flat View: This topic has 59 replies on 4 pages [ « | 1 2 3 4 | » ]

Previous Topic

Next Topic