[Zope-dev] Two small ZPT suggestions

Toby Sargeant sargeant@wehi.edu.au
Thu, 17 Jul 2003 11:27:32 +1000


--u3/rZRmxL6MmkK24
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

I must preface by saying that I'm relatively new to ZPT, and haven't been
using it in the context of Zope. Having said that, however, I think that
what follows is still applicable.

Two things that have struck me as potentially useful additions have been
a syntax for expressing case statements and arguments to macros (slots
are useful, but aren't applicable when, for instance, you want to write
a macro to mark up an arbitrary object). Both of these are essentially
syntactic sugar, but (imho) improve readability and aid brevity.

The syntax I have come up with (and have an implementation for) is as
follows:

case statements:

two new attributes are added: tal:switch and tal:case.

as an example:

<table tal:repeat=3D"row rows"
       tal:switch=3D"row/rowtype">
  <tr tal:case=3D"string:group">...</tr>
  <tr tal:case=3D"string:user">...</tr> =20
  <tr tal:case=3D"string:files">...</tr>=20
</table>                       =20

compare:

<table tal:repeat=3D"row rows">
  <tal:block tal:define=3D"casevar row/rowtype">
    <tr tal:condition=3D"python:casevar=3D'group'">...</tr>
    <tr tal:condition=3D"python:casevar=3D'user'">...</tr>
    <tr tal:condition=3D"python:casevar=3D'files'">...</tr>
  </tal:block>
</table>

This is essentially the same as using tal:define and multiple tal:condition
blocks, except for the fact that the case values aren't part of the visible
variable space. Missing at the moment are:

* ways to change the type of comparison used in the case test.
* a sensible definition of how a default case should work.
  (this is actually pretty obvious, but would require more work, as the
   case statements can't be simply treated like conditionals)

macro arguments:

metal:use-macro tags allow metal:arguments=3D"define_list" which defines a
set of variables in a new local scope in which the macro is executed.

if tal:define could be used in conjunction with metal:use-macro in such
a way as to have the define executed first, then the additional tag
wouldn't be required. My reading of the docs suggests that there's reason
for the ordering of excution of tal: and metal: tags, so the new tag
may well be the only way.

<tal:block metal:use-macro=3D"a_macro"
           metal:arguments=3D"obj path/to/an/object;
                            verbose python:1" \>

compare:

<tal:block tal:define=3D"obj path/to/an/object;
                       verbose python:1">
  <tal:block metal:use-macro=3D"a_macro" \>
</tal:block>

Toby.

--u3/rZRmxL6MmkK24
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/FfuD+/wZttnhWGYRAq25AKDIWmtSOC3LyC5dFCNQTk0myVnd6ACgqNYF
c4otoVmlN2avaKujImHI60k=
=Clgy
-----END PGP SIGNATURE-----

--u3/rZRmxL6MmkK24--