Martijn Faassen wrote:
I don't think it has an implementation of string TALES expressions.
It's parsing anything that's actually *inside* the attributes you add
on HTML with tal, such as detecting whether a TALES expression type
identifier is used ('string:' or 'python:', say), or 'structure', and
the right splitting of tal:repeat="foo bar" (into 'foo' and 'bar'),
and semicolons for multiple attributes with tal:attributes, and so on.
I just literally ported that code to javascript from Zope's
implementation so it follows the established rules pretty well.
OK, now I get it :-)
in the CTAL implementation this is done for each type of rule
(ctal:content, ctal:attributes, ...) using ctal.eval_expr() or
ctal.get_nameexpr() or eval_pathexpr(). Could be good to have a single
method for parsing the expressions.
[snip]
More in general, it's possible that some template will receive two
sets of data that's quite separate from each other. I like
namespaces then too. You can of course always argue that such a
template should be factored into multiple smaller ones, though the
question remains how they'd each receive only their data and not the
rest.
what I mean it that the structures can always be merged before they
are passed to the template, then the data can be organized as:
data = {
items: [ ...],
people: [],
somemoredata: {}
}
ZPT does a mapping between several data structures (context, request,
view ...) and the variables with the same name in TAL, which results
in several namespaces. Such variables are very platform-dependent and
a templating language basically needs only one data structure to do
the rendering..
I'm not sure I understand fully... Perhaps you mean this:
A pattern in templating is to prepare the data fully in nested
dictionaries and lists with simple strings and integers inside before
the data is pushed along to a template, as opposed to the template
pulling it out of request and context and view individually (with
method calls, often). Perhaps you are referring to this pattern. I
like this pattern, as it has positive qualities concerning
debuggability, modularity, loose coupling and makes possible various
performance optimizations.
XSLT and ClearSilver are templating languages which have this pattern.
TAL can be made to follow this pattern with some small modifications.
Regards,
Martijn
Yes, that's what I mean. Clearsilver is a good example. There are
several advantages:
- the data structures are platform-independent (they can be encoded in
JSON, C, python), and they can be easily converted from one language to
another, even to and from XML, this simplifies the transport too (e.g.
in Ajax, webservices)
- the template does less, it does not need to know anything about zope,
it works faster, the data access from inside the template is not an
access to the ZODB ...
- it is possible to create a simple schema definition from the data
structure itself (this is what I've done in the Ajax toolkit I'm writing)
for instance from:
data {
"personid": 123,
"name": "bill"
"info": {..},
"phonenumbers": []
}
one can deduce a simple schema like:
schema = {
"personid": int,
"name": string,
"info": dict,
"phonenumbers": list
}
of course this works only on the first-level of the structure, but
this is enough in many use cases to make sure that an integer field for
example does not all of a sudden become a list. This can be used to
enforce a storage policy.
Regards
/JM
_______________________________________________
Zope3-dev mailing list
[email protected]
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
