At 05:21 AM 2/24/2003, Max M wrote:
I strongly suspect that those who hang on to dtml either have a lot of redundant layout-code, or use some terrible time-consuming methods to make dtml "behave"
The possibility that you may not be aware of some features of DTML is beyond consideration, of course.
Many designers will then just copy paste this code all over a site.
That's bad... granted.
To call this dtml method from dtml you would use something like:
<dtml-var lay_box(boxTitle='Some title', boxContent='This is some content ...')>
Easy enough so far.
But the problem here is that you need some very complicated python/dtml code to populate the box with content that is just a little more complicated than that.
Huh? If you're making a more complex layout, you need more complex layout code. That's a given, isn't it? But as regards passing values around, the syntax *doesn't* have to get any more complicated than what you've shown. In fact, most of mine is simpler. That's what makes it work better for complex widget-based UIs. I call most of my DTML from Python products. I write the DTML to be context-aware, and simply call them thus: # declared once as class attribute some_interface = DTMLFile('my_interface', globals()) def some_method(self, REQUEST): """An example""" # do something REQUEST['my_var'] = self._some_private() # hand off the formatting of the results return self.some_interface(self, REQUEST) That's as tough as it gets. Creating new behaviors doesn't require *any* change in what parameters I'm passing around. If I handle REQUEST correctly, it all just works.
In zpt on the other hand it is so easy to do it right. You just define a metal macro with your re-usable design element:
It can then be called from any zpt page in a very flexible manner.
<div metal:use-macro="container/lay_box/macros/box"> <span metal:fill-slot="title">UV elementer</span> <div metal:fill-slot="content"> This is some content ... that can be very flexible ... </div> </div>
How is the above possibly simpler or easier to read than: <dtml-var "lay_box(boxTitle='Some title', boxContent='This is some content ...')"> If you use more arguments than you want to type out, use a mapping object to pass them around. Your example shows not just the same results, but the same logic and same shortcomings. It's just different syntax layered on the same basic solution. Each example is created and declared differently, but they model the exact same process. Making anything more complex than your example is going to increase the complexity of the code in ZPT too, which is the only argument you raised against doing it in DTML.
Here you also call the zpt "function" with 2 parameters. The big difference is that the 2 parameters can be complex layout themself. Which is exactly the right aproach for a layout language.
I'll settle for it being easy for DTML objects to call each other in context.
And if you find that it isn't enough reason to switch, you have not understood the magnitude of the problem it solves!!!
Or I *do* understand that the actual difference between the two approaches is so small as to be unworthy of so much fuss and bother. The differences between DTML and ZPT are primarily syntactical. Just below the surface, they are far more alike than different. I don't see the choice of syntax as having nearly the impact you seem to feel it does. Just use the syntax best suited for your problem and get on with your life. Dylan