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.
/imv
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">
</tr>
</tr>
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
PHPTAL@lists.motion-twin.com
http://lists.motion-twin.com/mailman/listinfo/phptal
