[Zope] Re: Java re-invents DTML :-)

Max M maxm@mxm.dk
Mon, 24 Feb 2003 19:55:46 +0100


Dylan Reinhardt wrote:

 >> <div metal:use-macro=3D"container/lay_box/macros/box">
 >> <span metal:fill-slot=3D"title">UV elementer</span>
 >> <div metal:fill-slot=3D"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=3D'Some title', boxContent=3D'This is some=
=20
content ...')">


You are right that zpt looks worse on the surface, but if you want=20
"boxContent" to be something like:

<table>
<dtml-in "objectValues()">
<tr>
<td>=95 <a href=3D"<dtml-var absolute_url>"><dtml-var title_or_id></a></t=
d>
</tr>
</dtml-in>
</table>


You would need to create another dtml document just for the purpose of=20
writing the content of this "box"

If you have 5 boxes on a page, that is a LOT of auxillary methods just=20
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=3D"container/lay_box/macros/box">
<span metal:fill-slot=3D"title">Some title</span>
<div metal:fill-slot=3D"content">

<table>
<tr tal:repeat=3D"obj here/objectValues">
<td>=95 <a hef=3D"#" tal:attributes=3D"href obj/absolute_url"
tal:content=3D"obj/title_or_id">">title</a></td>
</tr>
</table>

</div>
</div>

<div metal:use-macro=3D"container/lay_box/macros/box">
<span metal:fill-slot=3D"title">Some other title</span>
<div metal:fill-slot=3D"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=20
view/page in the same file, while you still only have to write the code=20
that is unique to that particular view. And you can re-use design=20
elements at the same time.

> Your example shows not just the same results, but the same logic and=20
> same shortcomings. It's just different syntax layered on the same=20
> basic solution. Each example is created and declared differently, but=20
> 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=20
> the complexity of the code in ZPT too, which is the only argument you=20
> raised against doing it in DTML.


No. You will need a lot more glue code in dtml to do the same thing as=20
you do "naturally" in zpt.

regards Max M