| Issue 32: | Formatters (and predicates) should be passed a stack of namespaces, rather than a single one | |
| 1 person starred this issue and may be notified of changes. | Back to list |
This is a design bug, but thankfully we can keep compatibility:
{"base-url": "http://foo
posts: [ { "relative-url": ... id1 },
{ "relative-url": ... id2 },
}
{.repeated section posts}
{base-url}/{relative-url} <-- Here we can access the "global" base-url
{relative-url|format-with-base-url} <-- The formatter has no access to it
{section relative-url is-public?} <-- Predicate needs access to it
{.end}
Sep 22, 2009
Project Member
#1
gtempacc...@yahoo.com
Sep 25, 2009
Note: This is a little problematic for compatibility. The 'html' formatter is:
def HtmlEscape(s): # s is a string from the JSON
return cgi.escape(s)
If you need any other variables, it would have to be:
def HtmlEscape(context):
DoSomethingWith(context.Lookup('other-name'))
return cgi.escape(context.Lookup('@'))
Might have to distinguish between the 2 kinds of formatters/predicates.
{@|html}
{relative-url|$format-with-base-url}
Not sure I like $. Likewise for the Plural predicate -- it may need to take an
integer as well as a context.
Another possibility is to distinguish formatters/predicates on atoms (strings,
numbers, bools) vs formatters/predicates on composites (lists, dictionaries).
Sep 25, 2009
Idea: formatters/predicates that begin with a lower case letter take atoms. Those that begin with a capital letter take contexts.
Sep 27, 2009
I'm not a fan of having case change the meaning of things. Why not just always pass the context as the second parameter? Some formatters use it, some don't. In this case, the html formatter just ignores the second parameter and the format-with-base-url uses it.
Sep 27, 2009
Well, that will break everyone's existing formatters. And I like being able to do:
more_formatters={'html': cgi.escape}
rather than:
more_formatters={'html': lambda s, unused: cgi.escape(s)}
For functions that already exist.
I'm assuming here that nobody has formatters that start with non-lowercase char.
It's a little unconventional but I think it's very simple and elegant. Template
authors generally don't need to be aware of it.
Sep 28, 2009
Hmm... in Javascript and PHP, it won't break existing formatters. It breaks things in Python, I guess, if you pass an unused parameter?
Sep 28, 2009
Yup, in Python that breaks it. Interesting that it doesn't in PHP and JavaScript. I suppose we could make the API different. Not sure how I feel about that. In general I want template-level compatibility. I suppose this doesn't break template compatibility, only API compatibility. But the list of formatters is supposed to cross-language. So "AbsUrl" should do the same thing in all languages. In Java it definitely matters. Probably C# and Ruby do too... I think Javascript and PHP are exceptional in this regard.
Sep 28, 2009
In Python, if you used named parameters, I think it can be more like JS and PHP. But that might be a Python 3.x thing. I can't remember where I read that.... If there is to be a break for the other languages, it could be with four parameters: formatter_function (data, context, formatter, argument_string) data -- the same thing as always context -- as you outline above formatter -- the string as the user wrote it (this would seem overly redundant unless you had several formatters mapped to the same formatter function) argument_string -- whatever text the user wrote that came after the previous formatter parameter (alternately, given the previous parameter is available, it could be the entire string the user wrote -- if the function cared about the stuff after, it could strip off the formatter name as given in the previous param). You could conceivably have the call type (one param or four params) to formatters and predicates be based on option, like meta characters are. In such a case, the user would have to specifically ask for feature that might then break their code, otherwise everything degrades to the current system.
Sep 29, 2009
Reply in the group. Implemented in Python as: https://code.google.com/p/json-template/source/detail?r=9957eb309b019980d8ded3571f2daebc7ee34eba As mentioned this doesn't rule out the other idea, which is a more complex superset.
Status:
Started
Nov 7, 2009
(No comment was entered for this change.)
Labels:
Todo-Java Todo-PHP
|