RE: [Zope] Re: Java re-invents DTML :-)
On Sunday 23 February 2003 09:00 am, Fernando Martins wrote:
Maik Jablonski wrote:
Stephan is not the only one... I like ZPT (great concept), but I still prefer DTML too... Just another measurement error? ;)
Maybe you don't work with a designer(s) who barely understand html and you don't need to go back and forth between design and coding? Then, zpt might not be make a big difference?
Some people would consider that an organizational problem. Either pay for training, or get smarter designers. ;-D For my purposes, anyway, a designer who "barely understands HTML" is useless, anyway. As I mentioned, I don't think that form without function is worth pursuing. Anyway, we're more likely to have designers who've never seen a GUI page designer (or have and hate them). You know -- the kind of designers who try to make things look good in Internet Explorer, Mozilla, *and* w3m. As for the "try it and you'll know we're right" attitude -- If I bought into that, I'd be programming web pages in Lisp by now. Lispers have been swearing we'll all convert as soon as we get over our irrational fear of parentheses since, what?, the 1970's? I think there's another perfectly good explanation for why people "who use both ZPT and DTML" prefer ZPT, while those who "only use DTML" prefer DTML: 1) After assessing it, it was obvious we hated ZPT. And we don't *have* to use it for anything, because it's redundant. 2) After assessing it, you loved ZPT. However, you can't live without DTML so you still use it. So, naturally, you're stuck using both, whereas we don't need anything else, because we're happy. I personally find this the most rational explanation. I think the real distinction between ZPT and DTML partisans is what it is they spend most of their time doing, and how they think about the resulting applications: If you are using a basically static site design, which is simply a front-end to a python application, ZPT may be great -- and if it solves your organizational problem, very much so. But if your site is basically generative -- being itself restructured by the output of a python application, and not a mere vessel for it, then DTML is awfully handy. Of course once you pick one or the other as a favorite, you'll probably wind up being biased to that simply because you know it well. You will also tend to think one way or the other about the site design, further biasing your opinion. Fortunately, the world is big enough for both of us. One of the reasons I went for an integrated Python/Zope solution for my project was to avoid an excessive number of development languages. Python, being very general purpose, makes that feasible. The downside is, I'm now reimplementing a lot of stuff in Python and DTML that is already available as PHP code. The "hack" approach would be to just stick PHP into my application and be done with it, but I feel I'll get a better (smaller, faster, simpler, easier to interface) product if I keep things more integrated. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Terry Hancock wrote: [...]
Some people would consider that an organizational problem. Either pay for training, or get smarter designers. ;-D
Yeah, but not so simple to go from theory to practice. And one has to live with "in the meanwhile". [...]
As for the "try it and you'll know we're right" attitude -- If I bought into that, I'd be programming web pages in Lisp by now. Lispers have been swearing we'll all convert as soon as we get over our irrational fear of parentheses since, what?, the 1970's?
Hey! I've been there. I used it for a year and it is impressive. But uses another paradigm (mind set) and lots of recursion (which a lot of programmers don't get). It looks like Python borrowed a few elements from it (e.g. map) and maybe others could be adopted. ;-) [...]
I think the real distinction between ZPT and DTML partisans is what it is they spend most of their time doing, and how they think about the resulting applications: If you are using a basically static site design, which is simply a front-end to a python application, ZPT may be great -- and if it solves your organizational problem, very much so. But if your site is basically generative -- being itself restructured by the output of a python application, and not a mere vessel for it, then DTML is awfully handy.
This is the most intriguing statement. It appears you are mixing logic with presentation in Python, which we all know should be avoided. Do you have some case in mind to clarify? (I barely know DTML, so it's hard for me to get your point.) Cheers, Fernando
At 12:46 PM 2/23/2003, Terry Hancock wrote:
If you are using a basically static site design, which is simply a front-end to a python application, ZPT may be great -- and if it solves your organizational problem, very much so. But if your site is basically generative -- being itself restructured by the output of a python application, and not a mere vessel for it, then DTML is awfully handy.
An excellent point. Zope is great for building content management systems, but it's also a powerful general-purpose application server. People doing content management work seem better served by ZPT. You can tell at a glance what the page looks like and what kind of information it contains. But it's also been my experience that constructing a complex UI from a large number of context-sensitive widgets is far more easily (and readably) done in DTML. Choosing which language to use should hinge on which language provides greater transparency in a given situation. There's no particularly good reason why there *should* be one Zope templating language any more than there's a good reason why Zope should run on only one OS. Zope is a richer platform for providing a wider range of choices. My $.02, Dylan
Terry Hancock wrote:
I think the real distinction between ZPT and DTML partisans is what it is they spend most of their time doing, and how they think about the resulting applications: If you are using a basically static site design, which is simply a front-end to a python application, ZPT may be great -- and if it solves your organizational problem, very much so. But if your site is basically generative -- being itself restructured by the output of a python application, and not a mere vessel for it, then DTML is awfully handy.
I completely disagree with that! Doing sites with completely non-redundant design code is *much* simpler in zpt than in dtml. 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" Here's a simple example of what I mean: If I have a layout element that is re-used on several pages, like a "slashbox", it could have the following html code: <!-- lay_box --> <table> <tr> <th> Some title </th> </tr> <tr> <td> This is some content ... </td> </tr> </table> Many designers will then just copy paste this code all over a site. Having disasterous effects when the time comes to change the layout. It can be expressed in dtml like this: <!-- lay_box --> <table> <tr> <th> <dtml-var boxTitle> </th> </tr> <tr> <td> <dtml-var boxContent> </td> </tr> </table> To call this dtml method from dtml you would use something like: <dtml-var lay_box(boxTitle='Some title', boxContent='This is some content ...')> 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. This offsets the time saved by re-using the code. 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: <table metal:define-macro="box"> <tr> <th> <span metal:define-slot="title">title</span> </th> </tr> <tr> <td> <div metal:define-slot="content">content</div> </td> </tr> </table> 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> 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. Metal really is what makes the big difference between dtml and zpt. And if you find that it isn't enough reason to switch, you have not understood the magnitude of the problem it solves!!! regards Max M
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
Dylan Reinhardt wrote:
<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 ...')">
You are right that zpt looks worse on the surface, but if you want "boxContent" to be something like: <table> <dtml-in "objectValues()"> <tr> <td>• <a href="<dtml-var absolute_url>"><dtml-var title_or_id></a></td> </tr> </dtml-in> </table> You would need to create another dtml document just for the purpose of writing the content of this "box" If you have 5 boxes on a page, that is a LOT of auxillary methods just for rendering one view. It is code bloat that makes the code much harder to follow. I know ... i've been there. In zpt, on the other hand, you have it all in one easy to read file. ------------------ <div metal:use-macro="container/lay_box/macros/box"> <span metal:fill-slot="title">Some title</span> <div metal:fill-slot="content"> <table> <tr tal:repeat="obj here/objectValues"> <td>• <a hef="#" tal:attributes="href obj/absolute_url" tal:content="obj/title_or_id">">title</a></td> </tr> </table> </div> </div> <div metal:use-macro="container/lay_box/macros/box"> <span metal:fill-slot="title">Some other title</span> <div metal:fill-slot="content"> This is my second box with unique content, and still just 1 file. </div> </div> ------------------ The advantage being that you can have all the code concerning 1 view/page in the same file, while you still only have to write the code that is unique to that particular view. And you can re-use design elements at the same time.
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.
Naturally. But how they do it makes a hell of a difference in practice.
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.
No. You will need a lot more glue code in dtml to do the same thing as you do "naturally" in zpt. regards Max M
At 10:55 AM 2/24/2003, Max M wrote:
You would need to create another dtml document just for the purpose of writing the content of this "box"
Which I consider a feature, not a bug. More on that in a second.
If you have 5 boxes on a page, that is a LOT of auxillary methods just for rendering one view.
But if you do segment your code at this level, you may have an easier time re-using those 5 boxes on other pages in other contexts. The decision hinges not on *if* you re-use code, but on *how* and *where* you re-use it. My philosophy is that the best way to re-use code is to have a larger number of relatively autonomous single-purpose objects that act correctly in different contexts. Each widget is an object. This philosophy stresses polymorphism and encapsulation as primary virtues. What you're advocating is a more monolithic approach: that a single ZPT object should define whatever widgets it uses and that these widgets are primarily used within a specific context. This approach stresses more of a project-centered orientation to software design.
In zpt, on the other hand, you have it all in one easy to read file.
The advantage being that you can have all the code concerning 1 view/page in the same file, while you still only have to write the code that is unique to that particular view. And you can re-use design elements at the same time.
Monolithic design can work great for individual projects, but when you have dozens of clients and at least as many projects, how are you going to remember which page of what system for which client you used for defining your slashbox macro? And why should you add new features to *that* file when the features are for a different system? How does *that* make sense? Conversely, how does it promote code re-use to have several different ZPT files making custom changes to some lowest-common-denominator macro? If any number of your objects make use of a common option or feature, you should only code that feature once. By defining each widget as its own object, any changes you make are easily tracked and it won't be any harder to find your slashbox code than to look in /widgets/slashbox. You appear to be striving for a higher widget-to-object ratio than *I* would find useful. To me, it's a design goal that each piece of the puzzle should be implemented as its own object. I would find it more confusing and duplicative to give each page its own set of context-specific widgets. I'm sure it works great for the kind of work you do and I'm not trying to talk you into changing your coding style... just pointing out that it may not be the best approach in all situations... particularly not those I'm working in. :-)
You will need a lot more glue code in dtml to do the same thing as you do "naturally" in zpt.
That's not my experience. But that may be a function of what each of us is trying to do and what our requirements are. ZPT is a great tool for many (maybe even most) applications... but it simply isn't a best-for-all-situations, one-size-fits-all technology (as if such a thing ever existed). DTML is the better tool for some problem domains. I'm not sure how that's controversial. Dylan
participants (4)
-
Dylan Reinhardt -
Fernando Martins -
Max M -
Terry Hancock