DTML reformulated as XML (was RE: [Zope] <% ... %> ?)
[reasons snipped for brevity]
Proposal --------
_If_ these were the requirements, then I think a reasonable proposal is XHTML:
http://wdvl.com/Authoring/Languages/XML/XHTML/
http://www.w3.org/MarkUp/#future
XHTML reworks HTML as an XML-compliant language. Most imporantly, you can extend it with new namespaces (like Zope instructions) without breaking the DTD, as is the case with ColdFusion et al.
I'll start by saying, this is *absolutely* the right thing to do. I've been mulling over this exact idea, but haven't had the time to post something to the list. (Not that I've been playing with Zope overly long.) I do want to point one thing out, though: adding namespaces does break the DTD. Currently there is no way to validate a document that uses namespaces. This will be fixed, eventually. Until then, you just have to live with well-formed but not valid documents. (Well, you can define a special DTD that defines the namespace prefix as well, but then that defeats the ability to change the namespace prefix.)
Why?
1) Alledgely it is the future of HTML.
2) Becoming well-formed means the authors can be given hints before saving changes, and Zope can do smarter things with structured data on the server.
Why Not?
1) A number of differences with HTML might drive people off.
Purely syntactic: <br> becomes <br/> and you can't leave out end tags (</p>) it's not so bad. Well, okay, I imagine there will be a lot of griping over the decision of enforce lowercase element names. :)
2) It isn't here yet.
Simple transformation makes XHTML into HTML, again for old clients. Probably so simple, it's not worth involving XSL.
3) Zope syntax might not be mappable into XML.
Close, but not quite. I'm sure it's possible to create an XML syntax that has all the functionality of DTML... however, it might very well end up being an ugly unwieldy syntax.
At any rate, I'd love for someone in the Zope community to march off and take a look at this, then make a proposal for how things should be changed. As always, patches are accepted. :^)
I've been meaning to do something like this. I might just spend some time thinking about it this weekend. Any actual coding probably won't happen, though. :) The simple stuff is easy: <?xml version='1.0'?> <xdtml:xdtml xmlns:xdtml="http://www.zope.org/xdtml" xmlns="http://www.w3.org/TR/xhtml1"> <xdtml:var name='standard_html_header'/> <h1><xdtml:var name='title'/></h1> <p>This is a paragraph.</p> <xdtml:if expr='age > 18'> <p>Text not everyone should read.</p> </xdtml:if> <xdtml:var name='standard_html_footer'/> </xtml:xdtml> The if gets really strange when you start adding 'elif' and 'else' clauses. I'll have to think about that one. The containing xdtml element is just there as a place to hang the namespace declarations off of. Also, it's there to make the DTML object a full-fledged self-contained XML document, needed to make any kind of editor useful. -Otto. (Please CC any replies to me, or I won't see it until the next digest goes out. :)
Otto Hammersmith wrote:
I'll start by saying, this is *absolutely* the right thing to do. I've
Hmm, I don't get that reaction often these days. :^)
been mulling over this exact idea, but haven't had the time to post something to the list. (Not that I've been playing with Zope overly long.)
I'd like to make sure everyone agrees on the goals, though. Just like the idea of "Python Methods" aka script objects, I think everyone wants a change, but perhaps for different reasons.
I do want to point one thing out, though: adding namespaces does break the DTD. Currently there is no way to validate a document that uses
Hmm, didn't realize that.
namespaces. This will be fixed, eventually. Until then, you just have to live with well-formed but not valid documents. (Well, you can define a special DTD that defines the namespace prefix as well, but then that defeats the ability to change the namespace prefix.)
Right.
Why?
1) Alledgely it is the future of HTML.
2) Becoming well-formed means the authors can be given hints before saving changes, and Zope can do smarter things with structured data on the server.
Why Not?
1) A number of differences with HTML might drive people off.
Purely syntactic: <br> becomes <br/> and you can't leave out end tags (</p>) it's not so bad. Well, okay, I imagine there will be a lot of griping over the decision of enforce lowercase element names. :)
The bit about: <select name="foo"> <option selected>Splat </select> ...not working, as attributes (selected) can't be minimed is, erm, weird.
2) It isn't here yet.
Simple transformation makes XHTML into HTML, again for old clients. Probably so simple, it's not worth involving XSL.
Hopefully there wouldn't be much transformation, right? That is, people could just write stuff that was readable by clients.
3) Zope syntax might not be mappable into XML.
Close, but not quite. I'm sure it's possible to create an XML syntax that has all the functionality of DTML... however, it might very well end up being an ugly unwieldy syntax.
Here's one thing in DTML that would be awfully obscure in XML: <a href="<!--#var BASE1-->"> That is, putting a tag inside an attribute. Chris Petrilli and Jim talked about this today, perhaps as as entity references.
At any rate, I'd love for someone in the Zope community to march off and take a look at this, then make a proposal for how things should be changed. As always, patches are accepted. :^)
I've been meaning to do something like this. I might just spend some time thinking about it this weekend. Any actual coding probably won't happen, though. :)
Understood. If you produced a clear definition of the goals, some samples for the syntax, and a list of things that are good and bad about it, then that would be a major win.
The simple stuff is easy:
<?xml version='1.0'?> <xdtml:xdtml xmlns:xdtml="http://www.zope.org/xdtml" xmlns="http://www.w3.org/TR/xhtml1">
<xdtml:var name='standard_html_header'/> <h1><xdtml:var name='title'/></h1> <p>This is a paragraph.</p>
<xdtml:if expr='age > 18'> <p>Text not everyone should read.</p> </xdtml:if>
<xdtml:var name='standard_html_footer'/>
</xtml:xdtml>
I'd love to do a straw vote from the "I hate SSI" crowd: is the above better?
The if gets really strange when you start adding 'elif' and 'else' clauses. I'll have to think about that one.
The containing xdtml element is just there as a place to hang the namespace declarations off of. Also, it's there to make the DTML object a full-fledged self-contained XML document, needed to make any kind of editor useful.
Precisely. It comes from the namespace declaration at the top. One more thing to muse over is whether other things from XML land should surface. For instance, I've long wondered if the ubiquitous var tag should be broken apart. People ask: why can't you give me a list of the things that can go in the var tag? Why doesn't Zope check to see if my documents reference subdocuments that no longer exist? The answer of "it's too dynamic" feels like less than an answer. Instead, we could begin granularizing the tags, perhaps into things that describe better where they came from. For instance, instead of saying <!--#var standard_html_header-->, which means insert a subdocument, why not use the XLink syntax from XML? Just musing... --Paul
On Sat, Jun 12, 1999 at 05:51:27AM -0400, Paul Everitt wrote: |I'd like to make sure everyone agrees on the goals, though. Just like |the idea of "Python Methods" aka script objects, I think everyone wants |a change, but perhaps for different reasons. I've been a long time Python fan and only recently have I got to use it in order to help pay my mortgage. Of course I came to it via Perl and don't have the same bitter-sweet relationship with it as I do with The Camel. I can come back to something I wrote months before and instantly know what the code does even if I can't remember what I was thinking. It could be that I'm just a sloppy programmer any Python forces me to be more organized. Which is good. But hey, I don't think I need to sell you on Python. :-) Zope got my teeth itching as I suppose I came to it expecting and embedded Python/HTML love fest which isn't the case. DTML can be Python-ish sometimes but not at others. Unlearn, as Yoda might say. I'm having a hard time with DTML as I'm still not sure what I can do with it. Getting over the i-don't-think-in-perl-php-cold-fusion-or-asp hump is part of the process of course. All my personal breakthroughs in programming come from reading other people's code and that's really what prompted me to drop the original email. It is *hard* to read DTML! Partly because my eyes aren't used to it and partly because my editors (vim and Homesite) don't know about DTML. In an earlier email either you or somebody else made a comment about having to write a syntax highlighter for each editor and what a drag it would be. Sure, any decent html editor will deal with <!-- --> correctly but it's a bigger drag for the newbie who doesn't know the syntax of the language. In a round-about way, I'm freely admitting to being a wickedly lazy individual. I certainly don't want GUI tools to build DTML (GUI programming tools are almost as evil as the seeminly humble mouse, but that's another story) but I do want either an editor that will help me with the drudge work or a simpler way to write the language. Or even -- yum! -- both. One of the sexiest PHP features is the syntax highlighter. If a site allows it. It's not a very whizzy example but take a look at http://www.php.net/docs.php3 and then take a look at http://www.php.net/source.php3?page_url=/docs.php3 That takes newbie "look, how did they do that?" questions to a "look how they did that!" level. Nice. Is this already in Zope? And if it is, why couldn't I find it? (Hint: because you're a wickedly lazy individual, Jules) |> The simple stuff is easy: |> |> <?xml version='1.0'?> |> <xdtml:xdtml xmlns:xdtml="http://www.zope.org/xdtml" |> xmlns="http://www.w3.org/TR/xhtml1"> |> |> <xdtml:var name='standard_html_header'/> |> <h1><xdtml:var name='title'/></h1> |> <p>This is a paragraph.</p> |> |> <xdtml:if expr='age > 18'> |> <p>Text not everyone should read.</p> |> </xdtml:if> |> |> <xdtml:var name='standard_html_footer'/> |> |> </xtml:xdtml> | |I'd love to do a straw vote from the "I hate SSI" crowd: is the above |better? Tons better. An editor like HomeSite could be configured to handle this nicely. And it doesn't look like line noise :-) Cheers, Jules
Jules Allen wrote:
It is *hard* to read DTML! Partly because my eyes aren't used to it and partly because my editors (vim and Homesite) don't know about DTML. In an earlier email either you or somebody else made a comment about having to write a syntax highlighter for each editor and what a drag it would be. Sure, any decent html editor will deal with <!-- --> correctly but it's a bigger drag for the newbie who doesn't know the syntax of the language.
I think that allowing \ as a line continuation would enable us to write much cleaner DTML. There are many places where proper rendering requires no whitespace but readability would need proper indentation. so I want <textarea>\ <!--#in "[1,2,3]"-->\ <!--#var sequence-item html_quote-->,\ <!--#/in-->\ </textares> to be rendered as <textarea>1,2,3,</textarea> the current (ugly) way to do is <textarea><!--#in "[1,2,3]" --><!--#var sequence-item html_quote -->,<!--#/in --></textares> (btw, did I mention this is real ugly ;) I have done this using re.sub(r"\\[ \t]*\n[ \n]*", "") (or somthing similar, this is from memory) on my DTML source before passing it to DocumentTemplate.HTML the meaning is to remove the \ as the last non-whitespace char on line together with the \n and all the indenting whitespace on the next line.
One of the sexiest PHP features is the syntax highlighter. If a site allows it. It's not a very whizzy example but take a look at
and then take a look at
http://www.php.net/source.php3?page_url=/docs.php3
That takes newbie "look, how did they do that?" questions to a "look how they did that!" level. Nice.
Is this already in Zope? And if it is, why couldn't I find it? (Hint: because you're a wickedly lazy individual, Jules)
Not syntax hilighting, but there is a "DTML source" link at the lower right of pages at www.zope.org ----------------- Hannu
Paul Everitt wrote:
(snip)
One more thing to muse over is whether other things from XML land should surface.
For instance, I've long wondered if the ubiquitous var tag should be broken apart. People ask: why can't you give me a list of the things that can go in the var tag? Why doesn't Zope check to see if my documents reference subdocuments that no longer exist? The answer of "it's too dynamic" feels like less than an answer.
Sorry. But that is the best answer I can give. Now, we probably, even almost certainly *could* do better.
Instead, we could begin granularizing the tags, perhaps into things that describe better where they came from.
For instance, instead of saying <!--#var standard_html_header-->, which means insert a subdocument, why not use the XLink syntax from XML?
I need to study the link syntax more. I don't think that this is mainly about syntax. The issue is that values come from a variety of places and the contents of the various name spaces *is* highly dynamic. Your comments have given me some things to think about. In particular, perhaps there could be specialized versions of the var tag that are more specific about where things come from. For example, there coulld be something like: <!--#var foo src="object"--> which means that foo must come from the object system and can be checked statically, when the document is created. Maybe some kind of link syntax could be interpreted this way. This needs to be usable in any tag, however, not just the var tag. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
The suggestion I make in my syntax proposal is to leave var as it is and add elements that do similar things, but better. For instance, I'd like to see a full-blown XLink support in Zope, so I can do the usual "trasclusion" and even things like annotation of documents without changing the original. I think Zope is perfectly structured to handle these kinds of things server side so support for any client is maintained. Which is, I believe, exactly what you're suggesting. :) -Otto. Jim Fulton wrote:
Paul Everitt wrote:
(snip)
One more thing to muse over is whether other things from XML land should surface.
For instance, I've long wondered if the ubiquitous var tag should be broken apart. People ask: why can't you give me a list of the things that can go in the var tag? Why doesn't Zope check to see if my documents reference subdocuments that no longer exist? The answer of "it's too dynamic" feels like less than an answer.
Sorry. But that is the best answer I can give. Now, we probably, even almost certainly *could* do better.
Instead, we could begin granularizing the tags, perhaps into things that describe better where they came from.
For instance, instead of saying <!--#var standard_html_header-->, which means insert a subdocument, why not use the XLink syntax from XML?
I need to study the link syntax more.
I don't think that this is mainly about syntax. The issue is that values come from a variety of places and the contents of the various name spaces *is* highly dynamic.
Your comments have given me some things to think about. In particular, perhaps there could be specialized versions of the var tag that are more specific about where things come from. For example, there coulld be something like:
<!--#var foo src="object"-->
which means that foo must come from the object system and can be checked statically, when the document is created. Maybe some kind of link syntax could be interpreted this way. This needs to be usable in any tag, however, not just the var tag.
Jim
-- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org
Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Otto Hammersmith wrote: (snip)
3) Zope syntax might not be mappable into XML.
Close, but not quite. I'm sure it's possible to create an XML syntax that has all the functionality of DTML...
Yup.
however, it might very well end up being an ugly unwieldy syntax.
If someone found the XML flavor of DTML unwieldy, then I'm quite sure that they would find XHTML unweildy too. (snip)
The if gets really strange when you start adding 'elif' and 'else' clauses.
Nah: <dtml:choose> <dtml:if expr="x==1"> .... </dtml:if> <dtml:if expr="x==2"> .... </dtml:if> <dtml:else> .... </dtml:else> </dtml:choose> Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
(First let me appologize for the junk I spewed to the list a couple days ago... it was late and I must've hit send when I meant to save as draft.) Jim Fulton wrote:
Otto Hammersmith wrote:
[snip]
however, it might very well end up being an ugly unwieldy syntax.
If someone found the XML flavor of DTML unwieldy, then I'm quite sure that they would find XHTML unweildy too.
That's a very good point.
(snip)
The if gets really strange when you start adding 'elif' and 'else' clauses.
Nah:
<dtml:choose> <dtml:if expr="x==1"> .... </dtml:if> <dtml:if expr="x==2"> .... </dtml:if> <dtml:else> .... </dtml:else> </dtml:choose>
I've written most of a proposal for a XDTML syntax, and I should be posting it tonight... this is the exact suggestion I made. Actually, split the if into an if and a choose, just as XSLT has it. The if doesn't allow for any else or elseif conditions, but the choose does. I think it's a rather clean solution, and I suspect the authors of the XSL draft agree with me. :) -Otto.
participants (5)
-
Hannu Krosing -
Jim Fulton -
Jules Allen -
Otto Hammersmith -
Paul Everitt