[pmwiki-devel] Nested IF conditions

[Simon]

I agree this is unexpected after playing around with it.

See http://pmwiki.org/wiki/Test/IfNested  and
http://pmwiki.org/wiki/PmWiki/ConditionalMarkup

It is worth noting though that PmWiki does not do a lot of recursive descent
parsing of expressions, hence the need to 'name' DIVs when nesting them.

It looks to me like the ELSE is being associated (incorrectly) with the
first IF rather than the second one as your examples and tests show.

I am puzzled why we can't name IFs (as we can DIVs) to get the effect you
want.

To solve your problem I suggest you look at multiple condition IFs

Simon



2009/6/20 DaveG <pmwiki at solidgone.com>

> After 4 hours debugging I discovered what I think is a bug if the
> conditional logic. Or perhaps nested conditions work differently to how
> I'd expect -- if so, how do I accomplish .
>
> (this was tested on pmwiki.org)
>
> This markup:
>    (:if equal 1 2:)111(:if equal 2 3:)222(:else:)333(:if:)444(:if:)
>
> produces: 333444
> expected: no output
> odd: 444 is shown, but 111 is not
>
> This case:
>    (:if equal 1 2:)111(:if equal 2
> 3:)222(:else:)333(:if:)444(:else:)555(:if:)
>
> produces: 333444(:else:)555
> expected: 555
> odd: 444 is shown, but 111 is not
>
> Which seems to indicate nested else conditional markup is simply
> ignored, or that the 444 is throwing things off. However this also
> doesn't work:
>    (:if equal 1 2:)111(:if equal 2
> 3:)222(:else:)333(:endif:)(:else:)555(:endif:)
>
> produces: 333(:endif:)
> expected: 555
>
>  ~ ~ Dave
>
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pmichaud.com/pipermail/pmwiki-devel/attachments/20090620/4a9fdd69/attachment.html