On Mon, Jun 22, 2009 at 1:14 PM, Russ Cox<[email protected]> wrote:
>
>> But there's a problem as you've defined it: sections can't contain
>> .name lookups now. Even if they could, the lookup is "direct", not
>> the type that walks the stack. The fundamental problem is that for a
>> section, you're looking for context to test for truth and push on the
>> stack, while in a substitution, you're looking for a value to put in
>> the output. These just can't be made the same.
>
> Sure they could. It's a bit surprising
> that they're different now anyway.
> In both cases you are looking for a value.
In the .section case, you don't want to look *up* the stack for
something to push onto it. That's just confusing and not necessary.
It's conceivable that sections could have dotted lookup, so the
expression syntax would be the same, but the way you evaluate the
expressions will still be different.
> The fundamental problem I have with predicates
> as a special case is the reuse of the | syntax.
> If predicates were written {.section num?plural}
> then it would be clear they were a different case.
Yes, and since I want to reserve room for filtering sections, we can't
use | unless the ? in plural? becomes part of the language.
I tried the {.section num?plural} syntax -- it still just feels a
little wrong. It would be good to imagine what more than 2 cases
would look like:
{.section num .plural?}
There are {...@} people here.
{.==1?}
There is only one person here.
{.or}
There is nobody here.
{.end}
Not saying that's the best syntax, but if we need multiple cases,
there should be room for expansion.
> I think this would be great, but I wonder
> if there is better syntax. On the page,
> {.section a|b} looks like a section with
> argument a|b, but in fact it is {(.section a)|b}.
> I think it would make more sense to add a
> separate "pipe this block through a filter"
> operator than overload .section. .section is
> about testing conditions and walking into structs.
>
> Your example:
>
> {.section program|html}
> if (n < 3 && m > 4) ...
> {.end}
>
> does not have any substitutions, and that
> sounds like a common case. So why
> should the reformatting of a block require
> pushing a new variable on the evaluation stack?
You can avoid this by having the default argument be @:
{.section|html}
Just literal strings
{.end}
Django has something called "blocktrans" which is just plain ugly:
http://docs.djangoproject.com/en/dev/topics/i18n/
But I think you're right about the common case not involving
substitutions. And in that case the translation can be done outside
of JSON Template -- as a filter on the JSON data dictionary. The
"JSON Config" language I mentioned to you will support this -- it's an
expression language that evaluates to JSON.
There are a quite a few cases where you want to do multiple template
expansions, so the configuration language will "coordinate" those.
That's nicer than having the template language itself specify multiple
stages of filtering.
Another complication is that some filters can be done piece-by-piece,
like HTML escaping, while others can't, like wikification. I want to
preserve the option of compiling to JavaScript or C without too much
fuss.
So I think I'll put the section filtering off at least until JSON
Config is done, and I can handle the common case there. It would be
extremely convenient to do things inline in the template, but it will
complicate the implementation, and I'm concerned about the JavaScript
code size. I want to hold off for the larger picture of composing
these little languages.
For now we'll have to come up with some syntax for predicates on
sections, since those problems can't be solved outside the language.
I'm open to more suggestions on syntax.
I like the idea of trying to make it an idiom, but the asymmetry
between the evalutation context of the section clauses looks like a
dealbreaker. The subtlety is that the section argument specifies an
evaluation context for ALL clauses -- and the predicate decides
*which* clause to show. The {.or} clause should be evaluated in the
named context if it exists, regardless of the result of the predicate.
Andy
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JSON
Template" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/json-template?hl=en
-~----------~----~----~----~------~----~------~--~---
