[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