On 12/22/05, Kevin Dangoor <[EMAIL PROTECTED]> wrote:
> There are actually interesting ways that changes on the parser end
> could make Kid more attractive to the people who like Cheetah without
> making it less attractive to the people who like Kid. David Stanek
> mentioned to me the idea of using a more liberal HTML parser (which
> would take somewhat cruddy HTML input and produce nice HTML output on
> the other end). Anything that can ultimately end up as Elements (and
> then serialized to plain text or HTML or XML or whatever) is fair game
> to be mixed and matched with the rest of Kid output. That's one nice
> thing about Kid's architecture: if you hand it an Element to render,
> it just drops it into the tree, ready for serialization.
I'm fine with optional Kid preprocessors that cover over some of the annoyances:
#####
<FOR expr="r in records" attr="value"> =>
<div py:for="r in records" attr="value">
#####
<FOR expr="r in records" tag="span" attr="value"> =>
<span py:for="r in records" attr="value">
#####
<?python <![CDATA[
is_insufficient = level < 100
]]> python> =>
<?python
is_insufficient = level & 100
?>
Although a more pleasant spelling for <![CDATA[ would
be nice. Maybe <?python-cdata ... ?>
#####
That py:layout feature.
http://lesscode.org/projects/kid/ticket/105
#####
Some kind of if/else. I can't think of a fesasble way without two
child elements though, and this may be worse than the original
problem.
<IFELSE expr="records">
<THEN>
# Draw table.
</THEN>
<ELSE>
<div><em>No records.</em></div>
</ELSE>
</IFELSE> =>
<div py:if="records">
# Draw table
</div>
<div py:if="not (records)">
<div><em>No records.</em></div>
</div>
> And py:match
> is addictive when you use it (and, as far as I know, Cheetah has
> nothing like it).
No, but nobody has asked for it either. For functional uses (like the
"greeting" example in section 7.8.1 of the Kid Language
Specification), people would just use methods. For overloading the
<title> tag and other header stuff, either the parent or subclass
template would have the actual tag with placeholders for the varying
stuff, and the other template would have #def's or #attr's to specify
the varying stuff. #block may also be useful. I don't think #match
is feasable in Cheetah; how would it know which sections of the
template to replace?
--
Mike Orr <[EMAIL PROTECTED]>
([EMAIL PROTECTED] address is semi-reliable)
