The Artima Developer Community
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

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 59 replies on 4 pages [ « | 1 2 3 4 ]
Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: Which Part of "No XML" Don't You Understand? Posted: Feb 2, 2006 1:16 PM
Reply to this message Reply
Advertisement
" > if you can only edit a file using special editors

XML doesn't require special editors."

Do you think LISP requires special editors?

Jim D

Posts: 7
Nickname: bogtha
Registered: Feb, 2006

Re: Which Part of "No XML" Don't You Understand? Posted: Feb 2, 2006 1:22 PM
Reply to this message Reply
> 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.

Email, CSV and Javascript can easily be done with Kid's PlainSerializer. As far as I'm aware, nobody's implemented a PDF serialiser yet, but I don't see any reason why it would be difficult.

Jim D

Posts: 7
Nickname: bogtha
Registered: Feb, 2006

Re: Which Part of "No XML" Don't You Understand? Posted: Feb 2, 2006 1:28 PM
Reply to this message Reply
> Do you think LISP requires special editors?

What are you talking about? You seemed to be disagreeing with me by making a point that assumed you needed a special editor for XML. I pointed out that you don't need a special editor for XML. What does LISP have to do with that?

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: Which Part of "No XML" Don't You Understand? Posted: Feb 2, 2006 1:39 PM
Reply to this message Reply
"What are you talking about? You seemed to be disagreeing with me by making a point that assumed you needed a special editor for XML. I pointed out that you don't need a special editor for XML. What does LISP have to do with that?"

What do you commonly use to edit XML? Does it have any special feature to handle XML? Because for LISP many folks prefer to use Emacs, so it restricts oneself to it, even though it's a good editor to learn about. I know there are other kinds of editors for LISP, some of them commercial. So, my comparison of LISP to XML is that both are structured and a simple Notepad would not be enough to handle them, generally. I prefer to be able to handle files with any editor that I have available, and that may mean Notepad sometimes, or Vim, or any other.

For me, it's no wonder that some LISP folks get excited when people seem to be using XML all this much, because when it comes to structured programming LISP excels, and it's a breezy to generate XHTML, XML, etc, with LISP. All they need is only one programming languages, and no templates... hehe.

Keep up your work with XML, by the way. Maybe I should use it, and I will consider it in the future. Thanks for sharing your knowledge on it.

has

Posts: 15
Nickname: has
Registered: Nov, 2004

Re: Which Part of "No XML" Don't You Understand? Posted: Feb 2, 2006 2:17 PM
Reply to this message Reply
> 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".

Doesn't matter what you or I might consider agreeable: it's the many, many web designers who still write HTML that are the ones who need to be kept happy. Hard to sell a templating system to folk if they don't like it. And one of the influencing factors is likely to be: does the templating system adapt to their workflow, or do they have to adapt their workflow to the templating system?

Like I say, Guido's job is to sell Python, not markup systems. :)

Jim D

Posts: 7
Nickname: bogtha
Registered: Feb, 2006

Re: Which Part of "No XML" Don't You Understand? Posted: Feb 2, 2006 3:02 PM
Reply to this message Reply
> What do you commonly use to edit XML?

Kate, the text editor that comes with KDE.

> Does it have any special feature to handle XML?

The only feature I "use" is syntax highlighting, but I believe you can install plugins to get it to do more.

> Because for LISP many folks prefer to use Emacs, so it restricts oneself to it

This is where we disagree. Just because a particular tool has good support and offers useful features for editing a particular language, it doesn't mean that using that tool has locked you into it.

Take those LISP folks away from EMACS. They'll grumble, sure, but they'll have no problem writing LISP without it. Are they quicker with EMACS? Sure! Is it necessary? No way! Are they locked in? Nope.

It's just the same with XML. Sure, you can have a fancy validating editor that does a hundred different things with its special XML knowledge, but you can (and I do) get along just fine using a normal text editor all day long.

> I prefer to be able to handle files with any editor that I have available, and that may mean Notepad sometimes, or Vim, or any other.

Me too. Working with XML does not stop you from doing this. I have edited XML configuration files with vanilla vi (not even vim) over ssh quite a few times.

Jim D

Posts: 7
Nickname: bogtha
Registered: Feb, 2006

Re: Which Part of "No XML" Don't You Understand? Posted: Feb 2, 2006 3:08 PM
Reply to this message Reply
> Doesn't matter what you or I might consider agreeable: it's the many, many web designers who still write HTML that are the ones who need to be kept happy.

Well, in context, it's neither us nor them that needs to be kept happy, it's Guido, who's clearly stating that he doesn't want XML :).

> And one of the influencing factors is likely to be: does the templating system adapt to their workflow, or do they have to adapt their workflow to the templating system?

I can't think of anything in a common web developer's workflow that would cause problems with writing XHTML-based templates instead of HTML-based templates.

The one thing that comes to mind is developers that don't know to close elements explicitly, use lower-case element type names, etc, but those are completely trivial things, much less of a problem than, say, if they aren't familiar with Python, or if they can't find a host with Python support.

Jim Jewett

Posts: 11
Nickname: jimj
Registered: Apr, 2005

Re: Which Part of "No XML" Don't You Understand? Posted: Feb 2, 2006 3:32 PM
Reply to this message Reply
(Jim D wrote): XML doesn't require special editors.

Yes and no. You can write lightweight xml (or html), and edit it with any text editor. But if you're maintaining an existing document that a tool generated ... I often spend an embarassing amount of time just deleting garbage and reindenting the rest, so that I can even find the part I'm looking for.

has

Posts: 15
Nickname: has
Registered: Nov, 2004

Re: Which Part of "No XML" Don't You Understand? Posted: Feb 3, 2006 8:20 AM
Reply to this message Reply
> I can't think of anything in a common web developer's
> workflow that would cause problems with writing
> XHTML-based templates instead of HTML-based templates.

You overlook the human factor: a lot of folk just don't like change. "If HTML 2.0 wuz good enough for my daddy, my grandaddy and my great-grandaddy before him, etc..." Sure a lot of it's irrational, but what do you do? The argument isn't about technical merits, it's about marketability. The BDFL wants to sell Python to the widest possible audience, and getting into markup debates would only distract from that goal; therefore, avoid approaches where it's an issue.

Or, as the saying goes: "Choose your battles wisely."

HTH

Eric Brunson

Posts: 1
Nickname: brunson
Registered: Feb, 2006

Re: Which Part of "No XML" Don't You Understand? Posted: Feb 3, 2006 9:36 AM
Reply to this message Reply
So, I've been thinking about this for the past few days and before I launch into my comment, let me say a couple of things to lay foundation.

First, in general I hate XML and I avoid it whenever possible, I'd much rather write or maintain a Config file than an XML file. I've also found that there are way to many abominations that were built on XML and there are way to many programmers that see XML as the solution to everything.

Second, I'm not a particular fan of any single templating engine I've seen, but I've looked at most of the same ones Guido has mentioned in his weblog.

Finally, because of the extreme high regard in which I hold Guido, my first reaction to reading these weblog entries was, "Hmmmm... Guido says it, so it's probably right. I'd better take stock in what he's saying."

So, with that in mind, after a couple of days reflection, here are my thoughts:

WTF is with this "No XML" crap? XML is definitely not the right tool for every job, but it certainly has its place.

I hate hand editing XML, but then again, I hate hand editing HTML, but in each case I have two options: 1) Write something that does it for me, like a WYSIWYG HTML layout program, or 2) Suck it up. The fact is, I hate the HTML that every WYSIWYG editor I've every used generates, so I resort to option 2.

The only templating engine I've used extensively is Kid because I've been learning TurboGears and at first I resisted the XML syntax the way I originally resisted the required whitespace in Python.

However, just as the whitespace serves it's purpose in making code clean and readable, I like the fact that kid templates are directly renderable in a browser. This means I can more easily hand off the HTML generation to someone more artisticly gifted than I am (or to a lower paid programmer that has no choice but to deal with the tedium) and they (or I, or anyone else) can view their work by simply viewing the file in their browser.

In particular the implementations that Guido pointed out in Cheetah and Django are, to me, hideous and totally unpythonic. I switched to python to get away from the $#~*&@ line noise of Perlish languages, and these templates just throw it back in.

And the argument against XML/SGML not having a proper solution for if/then/else carries about as much weight with me as people complaining that Python doesn't have a 'case' statement. There are work arounds, use them because the benefits outweigh the detriments.

So, I wish could sit in an ivory tower using only the tools I deign to use (because it would almost always be python), but only the BDFL and a few others actually have that luxury. I am a lowly programmer and in order to continue putting food on my family's table I have to stoop to developing in PHP, Shell, XML and even (shudder) Perl at times. And when I do, I resort to option 2 above. In this case I feel that the benefits of an XML implementation are sufficient to outweigh the annoyance of writing it and I haven't seen a good alternative put forward. So, I think it's time to Get Over It(tm).

Of course that's just my opinion and I could be wrong.

hag na

Posts: 1
Nickname: hagna
Registered: Feb, 2006

Re: Which Part of "No XML" Don't You Understand? Posted: Feb 3, 2006 10:49 AM
Reply to this message Reply
Dear Guido,

Thanks for Python!

What *do* you want to use for making templates? Do you want to use html?

Is Nevow's stan not desirable because it generates xhtml?

The markup for leaving message on this weblog is annoying as well. I wish it would just read my mind.

has

Posts: 15
Nickname: has
Registered: Nov, 2004

Re: Which Part of "No XML" Don't You Understand? Posted: Feb 3, 2006 11:00 AM
Reply to this message Reply
> WTF is with this "No XML" crap? XML is definitely not the
> right tool for every job, but it certainly has its place.

It's a marketing concern. Given the choice between a system that accepts any old HTML and one that requires valid XHTML, which one will be an easier sell to the great unwashed ignorant masses?


> I like the fact that kid
> templates are directly renderable in a browser.

That's really orthogonal to whether XML is required. You can pull the same trick with macro-style engines by having all macro tags embedded in SGML comments. Embedding templating logic in existing tag attributes just makes the markup look cleaner.

The real reason these sort of engines usually require well-formed XML markup is because it greatly simplifies their implementation. The alternative is that they use a full-blown SGML parser that knows HTML's special rules and provides extensive error recovery for dealing with broken markup - in which case you might as well just hack up something like KHTML to do that.

(Though they could also take a chance and just build in a copy of HTMLTidy as a pre-parser, and hope users don't get too upset when the rendered output isn't the same garbage as they fed in.)


> This means I can more easily hand off the HTML generation
> to someone more artisticly gifted than I am

The DOM-style templating folk have been saying this is a major advantage for ages, and their systems provide way better programmer-designer insulation than anything else. And yet most of the world refuses to look past their stinky old PHP/ASP-style Big-Ball-O'Mud factories for even five seconds. Y'think XML-based systems get a tough rap, they're not half as feared or misunderstood as DOM-style templating. :p


> In particular the implementations that Guido pointed out
> in Cheetah and Django are, to me, hideous and totally
> unpythonic.

The obvious point to make about approaches like Cheetah's (and Kid's, for that matter) is that they require you to learn a second language in order to use them. It's a duplication of effort that can turn into a right make-work exercise for both implementors and users (see Greenspun's Tenth Rule). (BTW, the first templating system I ever wrote used this approach, so it's a lesson I learnt the hard way.) Systems like HTMLTemplate and Spyce have the advantage of using Python for all presentation logic, so I don't think you can get much more quote-pythonic-unquote than that.


> In this case I feel that the benefits of an XML
> implementation are sufficient to outweigh the annoyance of
> writing it and I haven't seen a good alternative put
> forward. So, I think it's time to Get Over It(tm).

Someone needs to sit down and do a full, detailed cost/benefit analysis that shows how, where and why the advantages of using a system with an unfortunate "XML-only" restriction on its input still make it a better choice over the "Garbage-in" alternatives. Extra marks for listing ways in which that pesky XML requirement could be ameliorated, e.g. by inserting an HTMLTidy-style preprocessor to convert scruffy HTML markup to shiny XHTML prior to parsing, thereby allowing marketing to pretend it isn't really an issue when flogging such an engine to the XML-shy.

Eugene Lazutkin

Posts: 15
Nickname: elazutkin
Registered: Jan, 2006

Re: Which Part of "No XML" Don't You Understand? Posted: Feb 3, 2006 6:49 PM
Reply to this message Reply
> > WTF is with this "No XML" crap? XML is definitely not
> the
> > right tool for every job, but it certainly has its
> place.
>
> It's a marketing concern. Given the choice between a
> system that accepts any old HTML and one that requires
> valid XHTML, which one will be an easier sell to the great
> unwashed ignorant masses?

I think that a simple point is missed by many fans of XML-based templating solutions. XML is a text-based standard and any general text-oriented templating solution can be used to generate XML. The opposite is not true: not every text file can be generated with XML. Yes, I know that some of XML-based templating systems have a way to generate pure text. But how convenient is it?

Of course, there are pros and cons to any generalization/specialization.

Text-based solution gives you ability to generate any conceivable text file. You don't need to learn new language to produce a form letter, if you need one. But if you do want to generate XML you are on your own enforcing required rules of XML and corresponding DTD/XSD specifications.

XML-based solution can take care of spec enforcement for you. Most probably it implements useful shortcuts to simplify XML coding. But as soon as you stray out of XML land, you are on your own. It may be possible but not as comfortable as a text-based solution.

While downsides of XML generation by general text-based templating are easy to understand and evaluate, downsides of general text generation by XML-specific tools are tool-specific and require research in each particular case. It looks easy to add XML-specific macros/tags/commands to generic text tools. It doesn't look so easy to extend XML-specific solutions for general text needs.

I can see why Guido is interested in more generic solution. In his position I would do the same. And only after that I will look at specialized tools. You may not believe me but many real-life projects are not web-based, and many of them are not web-related at all.

Ultimately it depends on your needs. If you have to generate valid XML, and don't work with anything else, specialized XML templating system is the way to go. If XML plays small role in your professional life, it makes sense to go for more general solution.

Thanks,

Eugene

has

Posts: 15
Nickname: has
Registered: Nov, 2004

Re: Which Part of "No XML" Don't You Understand? Posted: Feb 3, 2006 9:53 PM
Reply to this message Reply
> I think that a simple point is missed by many fans of
> XML-based templating solutions. XML is a text-based
> standard and any general text-oriented templating solution
> can be used to generate XML. The opposite is not true: not
> every text file can be generated with XML.

Actually, SGML-derived markup vs everything else is the one issue I don't think is that big a deal. Both are extremely large territories in themselves, and there's a good argument to be made for approaching each one separately with a tailor-fitted solution rather than trying to provide a single 'one-size-fits-all' umbrella solution; both markets are easily big enough to be worth providing dedicated versions for.

The 'everything else' engine can handle any kind of text at all (including markup if you want), while the 'markup' engine takes advantage of SGML-based markup's particular properties to provide a more efficient tool for working in that one particular domain.

If you play your cards right, you'll be able to recycle 90% of your codebase, API, documentation and conceptual model, minimising the extra effort required to develop and learn the second system. e.g. After I wrote HTMLTemplate [1] I forked it to create texttemplate [2] in just a few hours, and a user who learns one can pick up the other extremely quickly afterwards as while some of the details are different the general concept, behaviour and usage are still very similar [3].


Like I say, the real squabbles are within the XML/HTML/XHTML/your-brand-of-SGML-here camp. Outside of that things are a bit more measured.

HTH

--

[1] http://freespace.virgin.net/hamish.sanderson/htmltemplate.html
[2] http://freespace.virgin.net/hamish.sanderson/texttemplate.html
[3] In fact, the two APIs aren't quite as similar as they could be as texttemplate uses a modified API structure that didn't come up with till after HTMLTemplate's API was frozen for the 1.0 release. Still reasonably close though.

Robin Parmar

Posts: 3
Nickname: robin746
Registered: Mar, 2006

Re: Which Part of "No XML" Don't You Understand? Posted: Mar 7, 2006 6:39 PM
Reply to this message Reply
Why do people want all of these ugly codes in their HTML? Why do people want extra syntax, nasty characters, confusion and mayhem?

Many years ago I wrote a template system with five new tags, the syntax modelled on HTML tags, so it looks the same. One tag inserts another template, one expands a simple macro (defined elsewhere), one inserts the results of a Python routine, one calls a Python routine and uses the result as a conditional, and the last closes a conditional. Calls can take simple parameters.

And that's all you need. You don't need bizarre syntax.

Want more structure, flexibility? Write Python and generate output. Don't try to get yor HTML to program for you.

What's up with all these clever clever implementations? They are so toally wrong.

Flat View: This topic has 59 replies on 4 pages [ « | 1  2  3  4 ]
Topic: Web Framework Redux Previous Topic   Next Topic Topic: Java Posse Interview part 2

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use