[Zope] Continued problem tal:condition

[KevinL]

On Thu, 2002-08-22 at 04:30, Dieter Maurer wrote:
> zope writes:
>  > ...
>  > Now all my macros are in the same page.
>  > I m am trying to use :
>  >   <div tal:condition="request/form/lkid | nothing">
>  >      <tal:block define="mName
>  > python:here.oms.Users.lib.pset_links(lkid=request.form['lkid'])">
>  >          <metal:block use-macro="container/zptmac_memall/macros/?mName">
>  >           List
>  >          </metal:block>
> This does not work, because TAL-attributes are only evaluated once
> all METAL-attributes have been executed.
> 
>   As a consequence you must not refer to a TAL defined variable
>   in a METAL attribute.
> 
> Use a Python script to return the macro object you need.
> 
> 
> Furthermore, you cannot suppress a METAL attribute execution
> with a "tal:condition" (for the same reasons).
> 
>   Use an (almost) empty macro in such a case (it may need to
>   define slots, when you call it with "metal:fill-slot").

Um.  That's wrong, I believe.  I have code that does almost what he's
doing above - defines skin and subSkin, which are then referenced as
?skin and ?subSkin in the metal use-macro attribute.  At least, I did
before I had to shift to python returning the macro...  We also have
code that uses a macro only if a certain condition is met (and just
prints a redirect otherwise), and I'm fairly sure that works.

I think he's actually having trouble with the existence or not of the
form element.  Could try:

tal:condition = "python:request.form.get('lkid',None)"

That'll allow people through if lkid exists and is non-null, but won't
error if it's not there (.get() returns the value if found, or the
default value (in this case None) if not found).  My preferred syntax
(because it dodges using python in the tag) is:

tal:condition = "exists:request/form/lkid"

But that will let the user through if lkid exists and is "" - may or may
not be a problem to you.

Inside that, the tal:define and metal calls look fine to me, presuming
your pset_links() method is operating as expected (ie. taking the lkid
value and returning a macro name).

KJL