History for ZRenderAbsImage

??changed:
-
ZRenderer absolute_image Example

  Suppose you were working with a web designer, who knew very little about
  Zope and less about DTML.  They might provide you with HTML pages
  full of tags like::

    <img src="images/larch">

  Suppose you plan to load into folder '/Project1/images' all of the images
  which the designer placed in their local 'images' directory.  You really
  don't want to leave the 'src' references relative, since this kills
  caching, and you'd like to take advantage of the features of the Zope
  Image class.  You might edit the HTML in a number of ways (all of what
  follows assumes PathNameTraversal for simplicity)::

    1. <img src="/Project1/images/larch">  (literal URL)
    2. <img src="&dtml.url-images/larch;"> (using acquisition)
    3. &dtml-images/larch; (acquire and let it render itself)

  Now suppose that you need the designer to make further changes to the
  HTML.  Unless you back out all of your edits, the designer will have
  a hard time, and in any case you'll have to hand edit their changes.
  If you did '1.' or '2.', they will see a broken image.  '2.' and '3.'
  may confuse the HTML editor, and '3.' doesn't even contain an 'img' tag
  any more.

  With ZRenderer implemented, they (or you) would add an attribute to all
  of the image tags::

    <img src="images/larch" z-render=absolute_image>

  You would write (or have written) an 'absolute_image' which reads the 
  'src' attribute of the tag, uses it to look up the Image object, and
  returns the new tag generated by the Image.  Something like this::

    <dtml-var expr="_![tag.src]()">

  Then, unless the designer's editor is brain-dead enough to strip out
  attributes it doesn't recognize, you can send this HTML back and forth
  and have it work unmodified in both environments.

  If you wanted, you could even add more complex behaviors to !ZRendered
  images, such as automatic image rollovers, generated links, or anything
  else you can compute in your method.