[Petal] [rfc] if: ... then: ... else: ... modifier
Steve Purkis
spurkis at mkdoc.com
Fri Sep 12 15:58:39 BST 2003
On Thursday, September 11, 2003, at 12:59 pm, William McKee wrote:
> Hi Steve,
>
> I have no objections but would like to discuss some design ideas to get
> input from the list. I can see where there is some benefit to doing an
> if..else statement using modifiers if you are working with designers
> that
> use GUI's. The current method of using petal:if statements causes you
> to
> create two separate navbar Search objects to achieve the desired
> results.
That's a good point I hadn't thought of.
> e.g.,
> <a petal:if="search_page" petal:attributes="class nav-selected"
> href="/search.html" class="nav">Search</a>
> <a petal:if="false: search_page" petal:attributes="class
> nav-unselected"
> href="/search.html" class="nav">Search</a>
>
> BTW, in your example and thus in mine above, did you mean to include
> class in the petal:attr as well as a separate attribute? Will Petal
> replace the attribute with the dynamic version?
No, that was a typo. No idea what Petal would do, but I wouldn't rely
on it anyways.
> However, the examples you provide are making TAL start to look
> complicated. What if you created a modifier that takes three parameters
> and returns the value of the 2nd or 3rd parameter based on the trueness
> of the 1st? This is kind of like the ?: if form (what's the name of
> that
> function?).
'?:' is the conditional operator...
I agree that 'then:' and 'else:' make the syntax look a bit more
complex, but it's something I think most people can live with. The
main reason for its existence is one of parsing - how do you figure out
that the first two arguments of this expression:
<p petal:replace="if: foo/some_method arg1 arg2 then_value
else_value"/>
should be passed to $foo/some_method ? Tricky. If you put arguments
in quotes as you suggested:
<p petal:replace="if: 'foo/some_method arg1 arg2' 'then_value'
'else_value'"/>
you might find yourself breaking other expressions like:
<p petal:replace="if: 'foo/some_method string: 'literal quotes''
'then_value' 'else_value'"/>
and using '?' and ':' is out because ':' is a special char in Petal.
You could also require the use of '${expr}':
<p petal:replace="if: ${foo/some_method string: 'literal quotes'}
${then_value} ${else_value}"/>
which is a valid option I turned down as I thought it was ugly and
harder to write a regexp for. So better to just reserve the 'then:'
and 'else:' modifiers -- come to think of it, they could prolly be
written as separate modifiers and installed in %Petal::Hash::MODIFIERS.
Don't know if you'd gain anything by doing that, though...
If Petal had an expression parser then it would be easier to write
cleaner extensions. But that's potentially a lot of work, so I doubt
it will happen anytime soon. :)
> e.g.,
> <a petal:attributes="if: search_page 'nav-selected'
> 'nav-unselected'">Search</a>
>
> However, this example brings up a problem I had with the date: modifier
> where I was trying to pass in a string to be used as the separator.
> Jean-Michel claims I should be able to do it, but I did not have any
> luck.
You should be able to do it with 'string: foo', no?
> I'm out of town for a week so I'll talk to you on my return.
'till then,
-Steve
More information about the Petal
mailing list