I would advocate to don't make Tales syntax more complex. There is however one point which I would think as a good compromise, the use of inline PHP. For example:

<option tal:attributes="selected <?php $ctx->item->index == $ctx->selected ?>">foo</option>

This would work nicely with syntax highlighting and other editor/IDE features, is common enough for PHP developers and allows for arbitrary complex expressions.

The Tales parser just detects that the start of the expression is the "<?php" (or even "<?") and then fetches all the contents until "?>" is found (PHP's tokenizer could even be used to avoid false positives). The whole PHP chunk is then outputted in the generated file where the $ctx->path() call would go for normal tales expressions.

This would probably mean that the source template will need to be preprocessed, since as far as I know, processing instructions are not allowed inside attribute values.

I'm already using a similar approach that keeps the template as valid XML. Example:

<?php $ctx->isSelected = $ctx->item->index === $ctx->selected ?>
<option tal:attributes="selected isSelected">foo</option>

The key point for me is to play nice with source code editors when using complex/terse syntax, so adding operators to Tales could turn to be problematic when not used with care or by non-experienced programmers.

By the way, if you decide to go for extending Tales, I think it'll be very dangerous to allow function calling from them. Even if you try to add some white-listing security feature, it could always be prone to abuse and a possible attack vector.


On 11/17/09 2:05 PM, Kornel Lesiński wrote:
On 17-11-2009 at 12:35:02 Marco Pivetta <ocram...@gmail.com> wrote:

I know it's not an elegant solution, but it's a solution and I already use it: what about tal:define? It is already possible to fix those tales problems wrapping content within a tal:omit-tag-ed "definer element" or directly a tal:define block.

I don't understand how does it help.

If you have "selected_id" variable and want to select <option> with that ID, how would you do it with tal:define? without help of php: modifier?

even/odd classes can be done with pure TALES and tal:omit-tag, but it's ugly:

<tr class="even" tal:omit-tag="repeat/row/odd">
<tr class="odd" tal:omit-tag="repeat/row/even">

I'm probably loosing the point of the discussion, but I don't really see any reason to make the syntax more complex and also a bit heavyer to compute for the parser...

This would be heavier only once during template compilation, so performance is not a problem.

PHPTAL mailing list

Reply via email to