History for ZRenderCheckbox

??changed:
-
ZRenderer check_var 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 forms
  full of tags like::

    <input name="is_larch" type="checkbox" class="fancy_checkbox">

  Suppose you want to control the state of these checkboxes based on the
  value of the 'tree' variable, which may or may not be defined.
  The usual Zope idiom for this would be::

    <dtml-if tree>
      <dtml-if "tree == 'larch'">
        <input name="is_larch" type="checkbox" class="fancy_checkbox" CHECKED>
      <dtml-else>
        <input name="is_larch" type="checkbox" class="fancy_checkbox"> 
      </dtml-if>
    </dtml-if>

  This is pretty ugly no matter how you look at it.  Now suppose that you
  need the designer to make further changes to the HTML.  They will see
  two checkboxes, and any changes will have to be made to both copies. If
  they rearrange the form, the checkboxes could easily become separated from
  the DTML logic.

  With ZRenderer implemented, they (or you) would add three attributes to
  each of the 'input' tags::

    <input name="is_larch" type="checkbox" class="fancy_checkbox" 
      z-render=check_var var=tree value=larch>

  You would write (or have written) a 'check_var' which tests whether
  'tree' exists and equals 'larch', and adds a 'CHECKED' attribute to
  the tag if so.  Something like this::

    <dtml-if expr="_.has_key(tag.var) and _[tag.var] == tag.value">
        <dtml-call expr="tag.set('CHECKED')>
    </dtml-if>
    <dtml-var tag>

  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.

  Notice that this method is completely generic, relying on its ability to
  read the tag's attributes in order to get the variable and value to test
  against each other.