Issue 32: Formatters (and predicates) should be passed a stack of namespaces, rather than a single one
Project Member Reported by gtempacc...@yahoo.com, Sep 21, 2009
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
For clarification, the "stack of namespaces" is exactly what JS prototypes are,
although I don't think of the as "prototypes" because the attributes generally don't
overlap.

We could also change the JS implementation to actually use .prototype -- this would
probably make it a bit faster.
Sep 25, 2009
Project Member #2 gtempacc...@yahoo.com
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
Project Member #3 gtempacc...@yahoo.com
Idea: formatters/predicates that begin with a lower case letter take atoms.  Those
that begin with a capital letter take contexts.

Sep 27, 2009
Project Member #4 sroussey
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
Project Member #5 gtempacc...@yahoo.com
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
Project Member #6 sroussey
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
Project Member #7 gtempacc...@yahoo.com
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
Project Member #8 sroussey
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
Project Member #9 gtempacc...@yahoo.com
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
Project Member #10 gtempacc...@yahoo.com
(No comment was entered for this change.)
Labels: Todo-Java Todo-PHP