[Zope3-dev] Number of languages in Zope 3

[Jean Jordaan]

>> <img tal:replace="structure here/Imagefolder/imagename" src="" />
> 
> I use this explanation:
> 
>   In a page template, special characters like '<' get replaced with
>   their HTML entity like '&lt;'.

Yes, but that isn't exactly what's happening in Joachim's example,
is it? here/Imagefolder/imagename doesn't point at a document
which happens to contain '<'s, it points at a Zope image object,
which is published as HTML by the Zope machinery, and it is this
HTML (which has materialised as though from thin air) which needs
the treatment of the TAL 'structure' word. And I think it's this
layer which Joachim sees as obscure. You have to know that calling
image objects returns HTML. By contrast,
<div tal:replace="structure here/Imagefolder"/>
isn't going to return a gallery of images, it's going to return
<Folder instance at 8c120f0>.

Another aspect that probably takes some getting used to is that
using 'structure' with 'replace' makes the actual tag you use
completely immaterial. If you wrote
<img tal:attributes="src here/Imagefolder/imagename/absolute_url"/>
the tag would matter, but you miss out on Zope's publishing of all
the nice image attributes. However, for object types that don't
return HTML as images do, this idiom would be the correct one.

Perhaps it would be less misleading to write
<tal:logo replace="structure here/Imagefolder/imagename"/>,
and it would even be technically correct to write
<input tal:replace="structure here/Imagefolder/imagename"/>
as the HTML generated by the publication of the image object
completely replaces the tag in the source document.

Actually using an img tag would only be *necessary* if the
template was meant to be edited WYSIWYG using DreamWeaver or
suchlike, in which case it would have to render an image
when not parsed to be useful:

<img tal:replace="structure here/Imagefolder/imagename"
      src="/hardcoded/demo/imagepath" />

> Ok. Personally, I like ZPT syntax a lot.

I love it, but I don't imagine that it's pelucid. Usually,
there's a sweet spot that's short, reads beautifully, and
works just right .. but often, before I hit it, I write
and delete a lot of stuff that makes DTML look good.

-- 
Jean Jordaan
http://www.upfrontsystems.co.za