Hello Zopistas, we are before a big redesign of our Zope Site http://www.european-e-business.com The complete Look&Feel will be changed and we will switch from the Zope oldie 2.1.6 to the latest Zope version. The GUI will be developed with DreamWeaver. We are currently facing the following decision: * do we use ZPT/XHTML for presentation or * do we stick with the familiar DTML The designer told us, he (and his tool) can handle both. Thus, it boilds down to: ZPT/XHTML DTML modern approach in the future, probably only investment in the future used in niches in flux, probably unstable stable, we know its strengthes/weaknesses maybe, missing features (e.g. batching) poor documentation quite well documented by now e.g. loop variables, TALES variables What are your experiences? What do you think? Dieter
Hi! My first experience with ZPT is somewhat mixed. I like the general concept (i.e. making it possible to edit page templates with a WYSIWYG editor while retaining the Zope-specific tags), but the syntax is a bit strange (and, as you pointed out, not documented well). The lack of documentation surprised me a bit. After all, DC has started to establish certain standards for documentation ... I think ZPT work very well if you usually have a relatively simple page layout (like having a standard header and footer). I am not yet sure how it can work with more dynamic sites, like most of ours. We usually have not just a header/footer, but dynamic components for navigation, news boxes, etc. In the Kontentor framework, even the actual web content is built dynamically from header, text block, and image objects. ZPT's approach might not work for those sites. Joachim
I think ZPT work very well if you usually have a relatively simple page layout (like having a standard header and footer). I am not yet sure how it can work with more dynamic sites, like most of ours. We usually have not just a header/footer, but dynamic components for navigation, news boxes, etc. In the Kontentor framework, even the actual web content is built dynamically from header, text block, and image objects. ZPT's approach might not work for those sites.
We don't use standard_html_header or anything like that. Our components are very modular and I am not even involved in what the "data" code does. I'm just producing ZPT templates and someone else picks them up. It just happens. My ZPT templates don't have <html> tags. Mostly just a little table. Therefore I can't really open them in GoLive like you're supposed to be able to do. Note! the Dreamweaver/GoLive thing is just a little bonus you get. Peter
Joachim
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
We don't use standard_html_header or anything like that. Our components are very modular and I am not even involved in what the "data" code does. I'm just producing ZPT templates and someone else picks them up. It just happens. My ZPT templates don't have <html> tags. Mostly just a little table. Therefore I can't really open them in GoLive like you're supposed to be able to do. Note! the Dreamweaver/GoLive thing is just a little bonus you get.
That sound exactly like what we are doing now with DTML. Some questions: - If you can't use a WYSIWYG editor with your templates, why exactly are you using ZPT? - What are the advantages? Better syntax? Better performance? Joachim
On Fri, 22 Jun 2001, Joachim Werner wrote:
- If you can't use a WYSIWYG editor with your templates, why exactly are you using ZPT? - What are the advantages? Better syntax?
What a joke ! While DTML syntax is easily understandable by programmers (even if they don't know python at least they can see where the loops and condition tests are) despite DTML's double-quoting aspect, I fear that ZPT's one isn't, at least for me, seeing the example/comparison we have seen today. On the other side, ZPT's syntax is maybe more easily readable by HTML coders than DTML's one, but I'm really in doubt about this. I too would be glad to know the real advantages of ZPT over DTML. bye, Jerome Alet
Better syntax?
What a joke !
While DTML syntax is easily understandable by programmers (even if they don't know python at least they can see where the loops and condition tests are) despite DTML's double-quoting aspect, I fear that ZPT's one isn't, at least for me, seeing the example/comparison we have seen today.
That's why I am asking. My personal impression is the same. Most of the DTML tags are very easy to understand and learn. It only becomes a different story if you have to use advanced syntax using _[] etc., but even for that, the problem seems to be mainly in documentation. Cheers Joachim
They can be used in a WYSIWYG editor fine. Much better than DTML can. The editing advantage of ZPT comes third on my list of importance of ZPT. 1) More clear. No mix of namespaces makes coding stricter and easier to maintain 2) Forces valid XHTML. With DTML you seldomly get a clear picture of your <span> and <table> tags. In our environment the skill level varies greatly and novice users tend to bombard it with invalid HTML and hence undisplayable in Opera or Netscape Peter ----- Original Message ----- From: "Joachim Werner" <joe@iuveno-net.de> To: "Peter Bengtsson" <mail@peterbe.com>; <zope@zope.org> Sent: Friday, June 22, 2001 11:13 AM Subject: Re: [Zope] ZPT: ready for prime time?
We don't use standard_html_header or anything like that. Our components are very modular and I am not even involved in what the "data" code does. I'm just producing ZPT templates and someone else picks them up. It just happens. My ZPT templates don't have <html> tags. Mostly just a little table. Therefore I can't really open them in GoLive like you're supposed to be able to do. Note! the Dreamweaver/GoLive thing is just a little bonus you get.
That sound exactly like what we are doing now with DTML.
Some questions:
- If you can't use a WYSIWYG editor with your templates, why exactly are you using ZPT? - What are the advantages? Better syntax? Better performance?
Joachim
I have to agree on some points here. ;-) I prefer ZPT to dtml now because of the much clearer namespaces and html nesting , even though i never use WYSIWYG editors.. They work much better than DTML with text-editors too , as color coding is correct , and they are compatible with HTML/XML tools , like TIDY.. Une misunderstanding that should be cleared up , though , it that they force you to write valid XHTML.. This idea seems to have been ditched a while ago , and as of the current implementation , creating valid XHTML documents (especially with forms) is almost impossible - because of the way they handle single attributes , like 'selected' and 'checked' (which are not single at all in XHTML, but written explicitly , like this : selected="selected") .. This is not currently supportd by ZPT.. :-( - and dreamweaver f***s up valid XHTML totally, but perhaps GoLive can fare better in this respect ? anyway , ZPT rule! - with or without WYSIWYG editors! -- Geir Bækholt web-developer/zopatista geirh@funcom.com funcom oslo | webdev-team <!-- PGPid : 0x90B47B20 --> on or about, Friday, June 22, 2001, we have reason to believe that Peter Bengtsson wrote something along the lines of : PB> They can be used in a WYSIWYG editor fine. Much better than DTML can. PB> The editing advantage of ZPT comes third on my list of importance of ZPT. PB> 1) More clear. No mix of namespaces makes coding stricter and easier to PB> maintain PB> 2) Forces valid XHTML. With DTML you seldomly get a clear picture of your PB> <span> and <table> tags. In our environment the skill level varies greatly PB> and novice users tend to bombard it with invalid HTML and hence PB> undisplayable in Opera or Netscape PB> Peter
We've been using ZPT for several months now. All our new production code is written with it; DTML is history. We're pretty happy with the results. Our site is not a huge high volume thing, but I think that's probably irrelevant. dieter> ZPT/XHTML DTML dieter> dieter> modern approach in the future, probably only dieter> investment in the future used in niches dieter> dieter> in flux, probably unstable stable, we know its strengthes/weaknesses Although there are periodically changes (and new features) introduced, (so yes, "in flux" is reasonably accurate), I would not say it's unstable. dieter> maybe, missing features dieter> (e.g. batching) There are some "shortcomings", yes. However, when they surface, they frequently get a solution implemented quickly. Hats off to Evan and team for being among the most responsive developers I've ever dealt with. To put it in perspective, none of the shortcomings I'm aware of have approached the severity of <dtml-var "_.['sequence-item']">, or whatever the twisted syntax is... dieter> dieter> poor documentation quite well documented by now dieter> e.g. loop variables, dieter> TALES variables If you look at the specs in the ZPT wiki, you find that the documentation is kept pretty much up-to-date. No, it's not in the same place or format that the rest of the docs are... and that would be nice -- but most of it *is* written, IMHO. dieter> What are your experiences? dieter> What do you think? I find it much more productive than DTML. I've been around zope for about 2 years, so I'm not exactly a newbie. However, the rest of my team is. Our graphic designer is not a programmer, and the fact that he can work on pages full of dynamic content and not trample on the code is a wonderful thing. (ZPT's "prototype" concept means that he can see examples of the data in the editor -- something for which DTML has no analog.) Pages end up much cleaner, IMHO. I expect it to be much more maintainable when we get down the road a bit and we've forgotten the details. Part of that is due to the fact that it's easy to pop in and out of python scripts while doing a page. (Which is of course also possible in DTML-land; it's just a little less clear when and how to do it.) From: "Joachim Werner" <joe@iuveno-net.de> joe> I think ZPT work very well if you usually have a relatively simple page joe> layout (like having a standard header and footer). I am not yet sure how it joe> can work with more dynamic sites, like most of ours. We usually have not joe> just a header/footer, but dynamic components for navigation, news boxes, joe> etc. In the Kontentor framework, even the actual web content is built joe> dynamically from header, text block, and image objects. ZPT's approach might joe> not work for those sites. I'm not familiar with Kontentor. However, I don't understand the limitation you are alluding to. ZPT can do all that with ease.
[Apologies to those also on the ZPT list -- but this item that came in today illustrates my point perfectly.] Which implementation do you like?
<dtml-call "REQUEST.set('activeTab',REQUEST.get('activeTab',0))"> <table border="0"> <tr> <dtml-in tabList> <dtml-if "_['sequence-index']==activeTab"> <td align="center" width=97 height=19 background="frontTab.gif"><a href="&dtml-target;">&dtml-label;</a></td> <dtml-else> <td align="center" width=97 height=19 background="backTab.gif"><a href="&dtml-target;">&dtml-label;</a></td> </dtml-if> </dtml-in> </tr> </table>
<table border="0" tal:define="activeTab python:request.get('activeTab', 0)"> <tr tal:repeat="tab tabList"> <td align="center" width=97 height=19 background="frontTab.gif" tal:define="index repeat/tab/index" tal:attributes="background python:test(index==activeTab, 'frontTab.gif', 'backTab.gif')"> <a href="/" tal:attributes="href tab/target" tal:content="tab/label">Label</a></td> </tr> </table>
--- Which implementation do you like? <dtml-call "REQUEST.set('activeTab',REQUEST.get('activeTab',0))"> <table border="0"> <tr> <dtml-in tabList> <dtml-if "_['sequence-index']==activeTab"> <td align="center" width=97 height=19 background="frontTab.gif"><a href="&dtml-target;">&dtml-label;</a></td> <dtml-else> <td align="center" width=97 height=19 background="backTab.gif"><a href="&dtml-target;">&dtml-label;</a></td> </dtml-if> </dtml-in> </tr> </table> Versus <table border="0" tal:define="activeTab python:request.get('activeTab', 0)"> <tr tal:repeat="tab tabList"> <td align="center" width=97 height=19 background="frontTab.gif" tal:define="index repeat/tab/index" tal:attributes="background python:test(index==activeTab,'frontTab.gif', 'backTab.gif')"> <a href="/" tal:attributes="href tab/target" tal:content="tab/label">Label</a></td> </tr> </table> --- well, maybe i've worked too long with asp or maybe i'm just not good enough using zope or maybe it's baby-perl or... i dunno what ;-))) but i kindda like the dtml-one a bit more, and for different reasons. 1] i've had to train someone to use zope and it's easier to do it in dtml (using cutnpaste code) (if the guy has no prog background of course) 2] its more clear to me (and using tag highligthing + indent much cleaner) than mixin html and zpt syntax 3] i like verbose stuff, at least you can come back to a projet 6 month later and still be able to jump right back on track imho of course, but i'm just a newbie :-( infos
jmr@computing.com wrote:
<dtml-call "REQUEST.set('activeTab',REQUEST.get('activeTab',0))"> <table border="0"> <tr> <dtml-in tabList> <dtml-if "_['sequence-index']==activeTab"> <td align="center" width=97 height=19 background="frontTab.gif"><a href="&dtml-target;">&dtml-label;</a></td> <dtml-else> <td align="center" width=97 height=19 background="backTab.gif"><a href="&dtml-target;">&dtml-label;</a></td> </dtml-if> </dtml-in> </tr> </table>
<table border="0" tal:define="activeTab python:request.get('activeTab', 0)"> <tr tal:repeat="tab tabList"> <td align="center" width=97 height=19 background="frontTab.gif" tal:define="index repeat/tab/index" tal:attributes="background python:test(index==activeTab, 'frontTab.gif', 'backTab.gif')"> <a href="/" tal:attributes="href tab/target" tal:content="tab/label">Label</a></td> </tr> </table>
You're joking right? They're both horrible :-( I'm sure the second one could be made nicer with a bit mroe PythonScript usage, if not then I'll stick with DTML, and I'm sure people here can remember how much I like DTML ;-) cheers, Chris
You're joking right? They're both horrible :-(
I'm sure the second one could be made nicer with a bit mroe PythonScript usage, if not then I'll stick with DTML, and I'm sure people here can remember how much I like DTML ;-)
Irony? Do you like or dislike DTML? The syntax in ZPT might _look_ a little bit messier in terms of number of characters, but it is easier to _read_ because you must specify everything more precisly. <dtml-var firstname> isn't very obvious to debug. Where the hell does 'firstname' come from?
cheers,
Chris
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Peter Bengtsson wrote:
You're joking right? They're both horrible :-(
I'm sure the second one could be made nicer with a bit mroe PythonScript usage, if not then I'll stick with DTML, and I'm sure people here can remember how much I like DTML ;-)
Irony? Do you like or dislike DTML?
Dislike in most contexts where its used...
The syntax in ZPT might _look_ a little bit messier in terms of number of characters, but it is easier to _read_ because you must specify everything more precisly.
I disagree about it being easier to read. But, I think it's how people choose to use it. I reckon with careful use, both DTML and ZPT can be nice and easy to read...
<dtml-var firstname> isn't very obvious to debug. Where the hell does 'firstname' come from?
That's the whole point, and in that sense ZPT is the same AFAIK. cheers, Chris
in flux, probably unstable stable, we know its
strengthes/weaknesses
maybe, missing features (e.g. batching)
This is what the ZTUtils are for. Batching already exists. Here's one example: http://www.zope.org/Members/peterbe/DTML2ZPT/#example4
What are your experiences? What do you think?
ZPT are wicked! They "force" novice web developpers to produce valid Netscapable HTML and it is very "powerful" in that you can do many things. If the HTML can't be saved you'll have to ask the HTML coders to try harder, and the ZPT actually fixes bad HTML for you. http://www.zope.org/Members/peterbe/tidyhtml With ZPT you're forced to know where things are coming from before you call them. <dtml-var name> can be written in TAL in 5 different ways depending on where 'name' comes from. This makes it easier to debug ZPT afterwards. The list of Proposed Changes is pretty scary though http://www.zope.org/Wikis/DevSite/Projects/ZPT/ProposedChanges It feels like trying to ride a horse that doesn't stop, and will not stop for a while. Yeah, do it! ZPT will learn from the misstakes of DTML which is good. It smells kind of like Perl vs. Python here. Peter
Dieter
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
participants (9)
-
Chris Withers -
Dieter Maurer -
Geir B�kholt -
infos -
Jerome Alet -
jmr＠computing.com -
Joachim Werner -
Peter Bengtsson -
Steve Drees