Martijn Faassen wrote:

if it doesn't slow things down or add features that are not really needed, I think it's fine, but maybe an explanation would be good as
to what it does?

It basically does the same thing as ctal does, except less (no
tal:repeat for instance, though I did have a simple tal:define), and it
isn't going anywhere. I dabbled with it a few years ago as I thought it
was an interesting idea and I just wanted to play a bit with javascript.

It had unit tests, and the regex stuff that I was referring to may be
interesting - it ports the regexes from Zope's TALES to Javascript so
that the parsing of tales expressions works the same.

This is the module that has the regex bits, ported directly, if I recall correctly, from Zope's python code:

OK I see, it's the variable substitution;

string:${name}/${address} ..

the question is what this is not better computed in the model. If it's just for presentation it's fine (e.g. adding a colon between two fields),

but then one could (even should) write:

<span>...</span>: <span>...</span>

but if the data is supposed to be a URL or something meaningful for the entire application then there's a problem, because it's the template that creates the data and the rest of the application has strictly no access to it (at least in the MVC model where the view observes the model and not the opposite).


I really think that the best way to add features is to create a
sample applications and see what's missing in the language or what
feels unnatural or too complicated to achieve, but basically if a
missing feature forces you to move the logic to the data model, it is
definitely not a missing feature. I believe that ZPT is too much of a
scripting language.

Sure. I'm not sure whether the regexes are useful, just would be nice if
they didn't go to waste after all. :)

also I think that one namespace is enough (no "context/title", "request/user"), but use "title" and "user" instead ... extra
namespaces in a template are a sign that the view has not done a good
job at preparing a data structure for the template to render it.

Hm. If I'm rendering a bunch of records to a HTML table, say, I'd prefer my records to be in a list, and the records themselves give access to further details.

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..

regards /JM
Zope3-dev mailing list

Reply via email to