Jules wrote:
Has it been suggested that the SSI-type syntax of Zope isn't the most readable thing in the world? Is this even the right list to suggest this heresy or should I strap on the asbestos underwear and wander over to zopedev?
I'll comment first on the multiline statement. Let me reinforce the idea that The Zope Way is to separate presentation and logic. While we should have some kind of object that better deals with logic, I don't think there will be much sympathy for creating something that looks like ASP or PHP. Let me limit the conversation back to your subject line: <% vs. <!--# The latter was originally chosen to be like the dominant syntax at the time (SSI) and to be "legal HTML". I think the latter has proven to be total bunk, as almost no DTML Documents are valid (they get nearly everything from the fragments of standard header and footer). What are some reasons to consider changing from the SSI syntax? o It's hideous, cumbersome, and everybody hates it o No tools support editing it o It isn't conformant with the direction of HTML o Any others? Let's evaluate the situation in light of these. It's Hideous ------------ Yes. Tool Support ------------ The SSI syntax just happens to enjoy nearly zero support out there. Things like Netscape Composer, Dreamweaver, and Emacs HTML Mode just can't be convinced to handle it nicely. Does anyone view this issue as important? Future of HTML -------------- What role does SSI play in the future of HTML? Zero. Of course, neither do any of the alternative syntaxes mentioned previously. Thus, I'd like to list some requirements for a future syntax: 1) Within reach of "content managers". I won't budge on this one. I think XSL will have a role in Zope, but *NOT* as a DTML replacement. 2) Reasonably close to DTML. The current DTML accomplishes some level of functionality. While some small amount might not be permitted in some change, or might be permitted in a clumsy way, there should be a reasonable match. 3) Coherent with the HTML future. We have a choice: invent a syntax and, one by one, support every web authoring tool. Alternatively, we can stick to standards and wait for them to support it. 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. 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. 2) It isn't here yet. 3) Zope syntax might not be mappable into XML. 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. :^) --Paul Paul Everitt Digital Creations paul@digicool.com 540.371.6909 ----------------------------------------- The Open Source Zope application server http://www.zope.org/ -----------------------------------------
On Fri, Jun 11, 1999 at 01:54:34PM -0400, Paul Everitt wrote:
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.
The big problem: DTML commands aren't really tags. They're something you use to generate tags, and there's a lot of lossage lurking in between the two concepts. You'd never be able to translate the following fragment: <!--#if sequence-index-even--> <tr bgcolor="lightblue"> <!--#else--> <tr> <!--#/if--> Another possibility: XML processing instructions. These are used to hold "out-of-band" commands for processing tools. They look something like: <?dtml var ... ?> These aren't quite a perfect solution, either, but they're closer. Like tags, you shouldn't use them in attributes. They're invisible to the validator, which causes trouble. But at least they're a standard, mandatory part of the XML specification. Cheers, Eric
Paul Everitt wrote:
(snip)
Let me limit the conversation back to your subject line: <% vs. <!--#
The latter was originally chosen to be like the dominant syntax at the time (SSI) and to be "legal HTML".
It was also an attempt to avoid collisions with HTML tags. It was also chosen because DTML tags looked like comments, which was, at the time, considered an advantage. for example, you could view a DTML document as HTML without the DTML tags showing up. (snip)
What are some reasons to consider changing from the SSI syntax?
o It's hideous, cumbersome, and everybody hates it
o No tools support editing it
Some tools, such as Netscape Composer provide minimal support. You can actually select and edit DTML tags. In fact, DTML tags get as much support as FORM tags.
o It isn't conformant with the direction of HTML
o Any others?
It leads to invalid HTML when you need to insert a value into another tag: <a href="<!--#var URL1-->/manage_main">
Let's evaluate the situation in light of these.
It's Hideous ------------
Yes.
It would be helpful to make hideuosness a little more specific. What makes it hideous? Is it the noice characters? (!--#) Is it the number of shift characters? Is it the fact that DTML don't look like other tags? Is it the tag in an attribute problem mentioned above?
Tool Support ------------
The SSI syntax just happens to enjoy nearly zero support out there. Things like Netscape Composer, Dreamweaver, and Emacs HTML Mode just can't be convinced to handle it nicely.
Does anyone view this issue as important?
Yes. What would be needed to make HTML (not XML) editors happier?
Future of HTML --------------
What role does SSI play in the future of HTML? Zero. Of course, neither do any of the alternative syntaxes mentioned previously.
Thus, I'd like to list some requirements for a future syntax:
1) Within reach of "content managers". I won't budge on this one. I think XSL will have a role in Zope, but *NOT* as a DTML replacement.
I agree.
2) Reasonably close to DTML. The current DTML accomplishes some level of functionality. While some small amount might not be permitted in some change, or might be permitted in a clumsy way, there should be a reasonable match.
Cool. Of course, someone could write something totally different from DTML and make it useful in Zope, it just wouldn't be DTML.
3) Coherent with the HTML future. We have a choice: invent a syntax and, one by one, support every web authoring tool. Alternatively, we can stick to standards and wait for them to support it.
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.
Why?
1) Alledgely it is the future of HTML.
2) Becoming well-formed means the authors can be given hints before saving changes,
Good point.
and Zope can do smarter things with structured data on the server.
I'm not so sure about this one. Zope has alot of structured data now. For example, it would be pretty easy to find the var references in a parsed DTML object, but I'm not sure how much that gains you.
Why Not?
1) A number of differences with HTML might drive people off.
2) It isn't here yet.
3) Zope syntax might not be mappable into XML.
This isn't a problem. Here are some more why nots: 4) XML is wildly more verbose that HTML and, without tool support, people might find an XML variant of DTML or HTML to be a real pain. 5) DTML is used to generate a variety of text output. While it *is* used mostly to generate HTML, it is used to produce a variety of other formats as well. At any rate, I think that an XML variant of (or cousin of) DTML would be a great idea. I expect that DC will do this eventually, if no one else does. I'd expect am XML version of DTML to be able to work with any sort of XML data, including XHTML. I don't think, however, a plan to have an XML variant of DTML should prevent us from improving the non-XML version. 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.
Jim Fulton wrote:
Some tools, such as Netscape Composer provide minimal support. You can actually select and edit DTML tags. In fact, DTML tags get as much support as FORM tags.
Ironically, Composer doesn't do form tags. :^)
It would be helpful to make hideuosness a little more specific.
Good point.
What makes it hideous? Is it the noice characters? (!--#) Is it the number of shift characters? Is it the fact that DTML don't look like other tags? Is it the tag in an attribute problem mentioned above?
I'd say, in order: 1) It doesn't look like the competition. (which is largely <% or inventing their own tags). 2) Excessive noise. 3) When something interesting requires the expr machinery, you can only do one expression per line. (Note that this complaint isn't slated to be solved by a syntax change in DTML, just that it is a common complaint).
Tool Support ------------
The SSI syntax just happens to enjoy nearly zero support out there. Things like Netscape Composer, Dreamweaver, and Emacs HTML Mode just can't be convinced to handle it nicely.
Does anyone view this issue as important?
Yes. What would be needed to make HTML (not XML) editors happier?
This is the crux of the matter. It will be a LONNGGG time before XML editors saturate the market. Thus, we have two problems: a. Better syntax that is friendly to HTML authors and HTML editing tools. b. Different approach focused on future standards and tools (XML). This discussion is rightfully being geared back towards (a). Here's a chance for all of you folks out there with expertise in HTML tools (Dreamweaver, FrontPage, Cyberstudio, Alpha, Emacs, etc.) to weigh in.
2) Becoming well-formed means the authors can be given hints before saving changes,
Good point.
Jeffrey gave Jim and me a demo yesterday of how, with the syntax changed to <dtml-in>, the Alpha editor could be taught all the options for the in tag and present checkboxes.
and Zope can do smarter things with structured data on the server.
I'm not so sure about this one. Zope has alot of structured data now. For example, it would be pretty easy to find the var references in a parsed DTML object, but I'm not sure how much that gains you.
Let's say you rename a document. Nearly all the competition will update all the references to the document.
3) Zope syntax might not be mappable into XML.
This isn't a problem.
It was a problem for my XHTML proposal. It isn't a problem for goal (a) described above.
Here are some more why nots:
4) XML is wildly more verbose that HTML and, without tool support, people might find an XML variant of DTML or HTML to be a real pain.
I think we should rush blindly into implementing standards, as I proposed, then when everybody hates *that* as well, we come up with something sane. :^)
5) DTML is used to generate a variety of text output. While it *is* used mostly to generate HTML, it is used to produce a variety of other formats as well.
At any rate, I think that an XML variant of (or cousin of) DTML would be a great idea. I expect that DC will do this eventually, if no one else does. I'd expect am XML version of DTML to be able to work with any sort of XML data, including XHTML.
I don't think, however, a plan to have an XML variant of DTML should prevent us from improving the non-XML version.
Well stated. --Paul
At 08:36 AM 6/15/99 -0400, Paul Everitt wrote:
What makes it hideous? Is it the noice characters? (!--#) Is it the number of shift characters? Is it the fact that DTML don't look like other tags? Is it the tag in an attribute problem mentioned above?
I'd say, in order:
1) It doesn't look like the competition. (which is largely <% or inventing their own tags).
2) Excessive noise.
I'd swap those two around. Yes, PHP and ASP are similar but Cold Fusion is more like The Zope Way. I used CF before I used ASP, as Allaire obviously got there first, and my gut reaction to the <% %> delimiters after doing a couple of years of CF was "thank the Maker!" <cfThis> ... </cfThis> and <cfThat> ... </cfThat> is cumbersome to type, especially in the pre-HomeSite days. CF works exceptionally well for less technical end users as it's all a bunch of widgets. Learn or look up the syntax and Bob's your uncle: You're pulling stuff from databases and sending confirmation mails like a champion. Paul, you mentioned that the chasm between DTML and external methods is currently too great. I haven't had a chance to delve into externals yet but maybe this idea of that DTML is for Power Users is valid. I hate to suggest a Wizard but maybe some kind of DTML builder is necessary for those that need training wheels? I've already got a few test Zope/HomeSite definitions working. Maybe I'll get them finished up this weekend or next. Anybody know a good way to get permanent 4 day weekends? :-)
3) When something interesting requires the expr machinery, you can only do one expression per line. (Note that this complaint isn't slated to be solved by a syntax change in DTML, just that it is a common complaint).
I do understand your previous statement about separation of 'reporting' and 'logic' and I think it's a good one. However, from a user perspective, I only know how to clumsily use a hammer (DTML) right now so everything looks like a nail to me. Separation of Church and State is a lofty goal and both bleed into each other's turf.
[syntax/tool support observations snipped]
Here's a chance for all of you folks out there with expertise in HTML tools (Dreamweaver, FrontPage, Cyberstudio, Alpha, Emacs, etc.) to weigh in.
As I said, I've got sample HomeSite definitions on the go but I'd really like to get my head around doing a (vi|vim) definition style as it's a better editor for my needs. I've never done one but I'm sure it can't be that hard. Of course Emacs is a nice operating system but I prefer Linux at home so I can't comment on that ;-)
2) Becoming well-formed means the authors can be given hints before saving changes,
Good point.
Erm, #var seems kind of fluid and only a very, very smart editor would be able to offer hints effectively.
Let's say you rename a document. Nearly all the competition will update all the references to the document.
...and links, etc... I'd also like to say how refreshing and intelligent the comments from everybody are. So far I can't find one email where anybody's been called an a**hole. ;-) ZINU-(Zope-is-Not-USENET)-ly-yrs, baby! Jules -- "There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch." -- Tim <0.8 wink> Peters
Jules Allen wrote:
I do understand your previous statement about separation of 'reporting' and 'logic' and I think it's a good one. However, from a user perspective, I only know how to clumsily use a hammer (DTML) right now so everything looks like a nail to me. Separation of Church and State is a lofty goal and both bleed into each other's turf.
I think that part of the problem is that DTML needs to be a document building language that can create HTML, XML, or what have you, so trying to recreate DTML in a variant of XML seems problematic. There is currently no standard 'eXtensible Server Side Parsed Markup Language'(XSSPML) ;^) , and I think trying to shoehorn vanilla XML into this role would be a mistake. XHTML seems somewhat better, but not by much. When support grows for an extensible language for doing 'web server things', then DC should implement it, as an editor program that supports it should be able to get everything it needs from some form of DTD in order to understand the Zope specific tags. Such an editor would arguably need three basic views: a server-side source view, a client-side source view (after server-side parsing), and a client-side WYSIWYG view (after client-side parsing). Currently, no single editor provides this three way view (unless you add in a browser and view source), because currently no one is drawing a sharp distinction between languages parsed on the client (HTML, XML) and languages parsed on the server (DTML, etc.). Ideally, one would be able to make the appropriate kinds of changes in each view, and have the changes trickle up and down to the other views. Until that happy day arrives, simplifiying DTML syntax and using Python external methods should suffice. I would much rather DC focused on the Zope interface, object system, and underlying machinery. 01 (just my two bits), Michael Bernstein.
Paul Everitt wrote:
(snip)
It would be helpful to make hideuosness a little more specific.
Good point.
What makes it hideous? Is it the noice characters? (!--#) Is it the number of shift characters? Is it the fact that DTML don't look like other tags? Is it the tag in an attribute problem mentioned above?
I'd say, in order:
(snip)
3) When something interesting requires the expr machinery, you can only do one expression per line. (Note that this complaint isn't slated to be solved by a syntax change in DTML, just that it is a common complaint).
Do you mean only one line per expression? You can have multiple expressions per line *and* have multiple lines per expression:: <!--#var "x+1"--><!--#var "x+2"--><!--#var "x+ 2+ 3"--> 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.
Jim Fulton wrote:
It would be helpful to make hideuosness a little more specific.
It doesn't look like Python. What I really would love is a Python-inspired, indented format. An embedding of the facilities provided by dtml tags in a generally StructuredText-like format. Abstracting web content away from HTML, just as the ZORB abstracts away from HTTP. This might get defined (in a direction that departs from the StructuredText philosophy) as a standard bidirectional mapping between a XML and a "PYML" surface form, e.g. <mytag att1=val1 att2=val2> bla1 <othertag> bla2 </othertag></mytag> would turn into something similar to : mytag(att1=val1,att2=val2) : bla1 othertag : bla2 Of course, there are a few details to solve (e.g. CDATA) but (I believe) nothing too terrible. And providing a generic transform between xml syntax and an unclobbered python-like surface syntax may well turn out as a selling point, both for python and zope. While HTML/XML tags have some of the aura that COBOL had a couple decades back, I am sure that many resent the verbosity. Last, assuming a close fit to the actual python syntax, using the transform in the reverse direction would also allow using XSL to preprocess python source. Macros for free ;-) Regards, Boris Borcic -- (10^3+1)/(10+1) = (10-3)(10+3)
Boris Borcic wrote:
Jim Fulton wrote:
It would be helpful to make hideuosness a little more specific.
It doesn't look like Python.
Yes, I'll add a 'me too!' here. Looking like Python is very important. DTML is too Perlish in that it has verbose syntax with a lot of weird characters, and too many ways to do the same thing at times. Even the expressions that *do* look like Python become rather hideous due to the _ namespace and other things. <!--#var "_.str(_.int(foo) + 1)"--> looks unreadable compared to: <!--#var "str(int(foo) + 1)"--> I think what we need is a way to somehow visually and syntactically clearly distinguish what is HTML and what is DTML or even better something closer to what Python is. Perhaps turn things around and mark the *HTML* instead of marking the (Pythonic) logic. var(name=standard_html_header) HTML('''<p>And now, a list!</p>''') HTML('''<ul>''') for el in some_list: HTML('''<li>''') var(name=el) HTML('''</li>''') HTML('''</ul>''') HTML('''<a href="%s">%s</a>''' % (var(some_link), var(link_name))) var(name=standard_html_footer) Looks more pleasant to me than: <!--#var standard_html_header--> <p>And now, a list!</p> <ul> <!--#in some_list--> <li> <!--#var sequence-item--> </li> <!--#/in--> </ul> <!--#var standard_html_footer--> Of course the former is executable python. Of course one can get close to that in external method, but it seems to be more obscure to do DTML-ish things than what I just described. Hm. Digicool folks, could we have some plans on the Python scripting abilities you're working on? Would it look like my suggestion? Would you take any suggestions? :) Regards, Martijn
Martijn Faassen wrote:
Of course the former is executable python. Of course one can get close to that in external method, but it seems to be more obscure to do DTML-ish things than what I just described. Hm. Digicool folks, could we have some plans on the Python scripting abilities you're working on? Would it look like my suggestion? Would you take any suggestions? :)
We of course will take suggestions, but I think there's a few things that aren't terribly negotiable in our implementation of DTML/etc (this doesn't prevent other people from implementing other things, this is Open Source ;-)... the untouchables are: * DTML is inside HTML * Safety is paramount What this means is that your proposed syntax, to my eyes, is no better (though no worse probably) than what we have today, it is however, much more foreign to people who don't know Python. Remember, as the mantra goes, DTML is a *REPORTING* language, not a scripting language. Now on to the question of what will be in the 'Python Method' product... honestly, we're only in the Inception stage, so it's pretty vague right now, but the general idea is this: * One method == one object in the database * Operates in the namespace of its container * access to object database through self (maybe 'this'). * Expression machinery enforcement of security model * Additional safety net of catching resource DOS problems What this means is that you can extract logic from your DTML documents and move it into a clean Python syntax, and then simply refer to it: <!--#var pyDoSomething--> or whatever syntax you prefer :-) This to me puts DTML back where it should be, with no major bizarre contortions in expr syntax with _foo and _.bar() that... The hard part, and what will control time line, is the difficulty of extending/modifying the existing security mechanism (which depends on real-time modification of the AST parse tree) to work with multi-expression blocks. Honestly, I have no clue how much work this is. Note that this will operate in a "restricted execution" environment so that you can only import a subset of modules available---although the goal would be to let the administrator control which modules are available. Chris -- | Christopher Petrilli http://www.digicool.com | Digital Creations, Inc. petrilli@digicool.com
Martijn Faassen wrote: [my Python vs DTML ideas]
Christopher Petrilli wrote:
We of course will take suggestions, but I think there's a few things that aren't terribly negotiable in our implementation of DTML/etc (this doesn't prevent other people from implementing other things, this is Open Source ;-)... the untouchables are:
* DTML is inside HTML
Of course in practice this isn't much different from the other way around: <!--#var standard_html_header--> <ul> <!--#in mylist--> <li> <!--#var sequence-item--> </li> <!--#/in--> </ul> <!--#var standard_html_header--> could (given the right syntax :) differ only syntactically from: var("standard_html_header") @@@<ul>@@@ in mylist: @@@<li>@@@ var("sequence-item") @@@</li>@@@ @@@</ul>@@@ var("standard_html_footer") except for various indentation issues of course. :)
* Safety is paramount
Understood. The half-baked proposal in my previous post was vaguely between using Python proper and something as I described above, which looks like Python but isn't Python proper, but simply (mostly!) a syntactic shuffle around of DTML. More on using Python proper in an up and coming new mail. In this mail I just argue about (radical) syntactic changes to DTML. Security/safetly is of course paramount for anything that can be edited through the web.
What this means is that your proposed syntax, to my eyes, is no better (though no worse probably) than what we have today, it is however, much more foreign to people who don't know Python. Remember, as the mantra goes, DTML is a *REPORTING* language, not a scripting language.
Yeah, I know, I know. But, just to argue, I don't think the "this is foreign to people who don't know Python" argument is very strong; DTML (the intricacies and there are quite a few) is just as foreign to people coming to Zope as Python is, and probably much less easy to understand. But that may be only me. :)
Now on to the question of what will be in the 'Python Method' product... honestly, we're only in the Inception stage, so it's pretty vague right now, but the general idea is this:
* One method == one object in the database * Operates in the namespace of its container * access to object database through self (maybe 'this'). * Expression machinery enforcement of security model * Additional safety net of catching resource DOS problems
What this means is that you can extract logic from your DTML documents and move it into a clean Python syntax, and then simply refer to it:
<!--#var pyDoSomething-->
or whatever syntax you prefer :-) This to me puts DTML back where it should be, with no major bizarre contortions in expr syntax with _foo and _.bar() that...
Agreed. This is exactly what I want! DTML back where it belongs! DTML go home! Oh, um.. :)
The hard part, and what will control time line, is the difficulty of extending/modifying the existing security mechanism (which depends on real-time modification of the AST parse tree) to work with multi-expression blocks. Honestly, I have no clue how much work this is.
Having looked at Python internals at various occasions: *swallow* Deep magic.
Note that this will operate in a "restricted execution" environment so that you can only import a subset of modules available---although the goal would be to let the administrator control which modules are available.
Yeah, I was assuming a restricted execution environment. Thanks for the info! Regards, Martijn
Christopher Petrilli wrote:
What this means is that your proposed syntax, to my eyes, is no better (though no worse probably) than what we have today, it is however, much more foreign to people who don't know Python. Remember, as the mantra goes, DTML is a *REPORTING* language, not a scripting language.
Just to make it clear, when I characterized "hideousness" as "not looking like python", I meant to allude to (the basic traits of) surface syntax, not to semantics. Best, Boris Borcic
At 04:55 PM 6/15/99 +0200, Martijn Faassen wrote:
Yes, I'll add a 'me too!' here. Looking like Python is very important. DTML is too Perlish in that it has verbose syntax with a lot of weird characters, and too many ways to do the same thing at times.
Much as I dig Python, I'd have to disagree on this one. I'm the original language slut -- I'll learn the basics of anything if it'll make my life easier and I'll teach anybody what I know if it'll help me get out of the office at 5:30pm on a Friday night instead of at 7pm. The fledgling DTML seems to be what IBM planned for SEQUEL (precursor to SQL) back in the 70's: An easy way for end users to write their own reports without needing the Wizards at the data center. DTML as it is right now is too hard for simpletons, erm, average users to write this stuff. And yes, the Perl-like line noise doesn't help. SQL, with multi table inner joins, unions, and the like, is really too hard for non-power users. But simple selects and updates can be absorbed by anybody who's not dumb as a box of rocks. Keeping DTML simple (and simplifying the namespaces as you point out is an excellent example of simplification) will advance it. Obfuscation will prevent its acceptance. I have seen the light, brother!
I think what we need is a way to somehow visually and syntactically clearly distinguish what is HTML and what is DTML or even better something closer to what Python is. Perhaps turn things around and mark the *HTML* instead of marking the (Pythonic) logic.
Like CGI.pm? Ouch! Have you ever tried to do anyting *big* in CGI.pm? :-) You don't want to, trust me. I think that's a slippery slope. Suddenly there will be More Than One Way To Do It and we all know where that'll lead. Ask anybody who's had to use Lotus Domino and learn both LotusScript and the obscure @Macro Language. I-hope-we-can-still-be-friends-ly yours, Jules -- "There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch." -- Tim <0.8 wink> Peters
Jules Allen wrote:
At 04:55 PM 6/15/99 +0200, Martijn Faassen wrote:
Yes, I'll add a 'me too!' here. Looking like Python is very important. DTML is too Perlish in that it has verbose syntax with a lot of weird characters, and too many ways to do the same thing at times.
Much as I dig Python, I'd have to disagree on this one.
Do you disagree that DTML currently is rather Perlish and obfuscated? The ideal DTML is (as Chris Petrilli just said in his reply to me) a reporting language. If anything, the ideal DTML is *less* powerful than the current DTML. I think that in fact we agree on this. :) Of course my post that you are responding to was confused in that it was trying to push two concepts at once: * Cleaner DTML syntax, perhaps reached by stealing from Python? (unclear if this works, though I try to defend it in my reply to Chris) * More importantly: Clear, nice, Python way to do complicated things. Some attempt at DTML-in-Python will follow in a later post. [snip]
DTML as it is right now is too hard for simpletons, erm, average users to write this stuff. And yes, the Perl-like line noise doesn't help. Keeping DTML simple (and simplifying the namespaces as you point out is an excellent example of simplification) will advance it. Obfuscation will prevent its acceptance. I have seen the light, brother!
So we *do* agree. The path to more Zope power as I see it now: We need the Ideal DTML, and we do this by making it cleaner and if necessary even less powerful than it is now. More complicated stuff should be done in something other than DTML, and that other thing should (of course) be Python (unless it's something SQL can do well). Current Python ways to do things are however too hard to use for a number of reasons, so people misuse DTML for it. The Python way should be able to do at least what the DTML way can do (though should leave most of that to DTML), but much more as well. It should share with DTML the security/safety mechanism for expressions, and be manageable with the Zope web interface.
I think what we need is a way to somehow visually and syntactically clearly distinguish what is HTML and what is DTML or even better something closer to what Python is. Perhaps turn things around and mark the *HTML* instead of marking the (Pythonic) logic.
Like CGI.pm? Ouch! Have you ever tried to do anyting *big* in CGI.pm? :-)
I have never used CGI.pm, and barely know Perl to my relief. :)
You don't want to, trust me. I think that's a slippery slope.
I already know I don't want to. As I describe in my reply to Chris, I was mixing two things together and talked about syntactic and semantic changes at once. See my post to him for more details on the syntactic changes.
Suddenly there will be More Than One Way To Do It and we all know where that'll lead. Ask anybody who's had to use Lotus Domino and learn both LotusScript and the obscure @Macro Language.
I'm trying to make things cleaner, not harder. I was never proposing to throw away DTML (or its equivalent, Ideal DTML) completely, though I admit I sounded that way in my post.
I-hope-we-can-still-be-friends-ly yours,
Of-course-we-can-ly yours, Martijn
participants (8)
-
Boris Borcic -
Christopher Petrilli -
Eric Kidd -
Jim Fulton -
Jules Allen -
Martijn Faassen -
Michael Bernstein -
Paul Everitt