I just ran into this issue as well. My attempted usage pattern is
along the lines of:
{.section inner} {foo} {.section outer} {@} {.or} Fail {.end}
{.end}
Using the following dictionary:
{ 'outer' : 'OUTER',
'inner' : { 'foo' : 'FOO', },
}
In this case, I'm trying to use .section as a conditional test. This
can be satisfied using the custom predicates you're talking about.
E.g.:
{.section inner} {foo} {.if outer?} {outer} {.or} Fail {.end}
{.end}
That's how I'm currently working around the problem. Though, as a
separate issue, neither FromString() and FromFile() take a
"more_predicates" parameter, which sort of breaks things. I think I
can double-workaround using the undocumented _constructor parameter,
but I haven't tried it yet.
However, I'm confused by the .section lookup logic. It seems like it
should be consistent with normal variable lookups. I think it can be
done by decoupling the name lookup traversal from the section stack.
For name lookup, think of the JSON structure as a tree and the current
context as a pointer to a node in the tree. A lookup starts at the
current context walks up the tree to the root until a match is found.
There would need to be a way to get each context's parent during the
lookup. This could be done either by injecting parent pointers into
the JSON tree or by keeping the path to the root on each context.
The section stack just keeps track of your current starting point for
lookups. Only the top element is directly used for any given lookup.
When you push a new section, you do a normal lookup from the current
context to find the new context, then push it on the stack.
Given the current limitations on sections, I believe the proposed name
lookup rule is the same for variables. What we get is generality on
sections. You can start a higher level section or even a nested
section (e.g {.section foo.bar}). It also handles the conditional
predicate usage.
-Josh
Post by Andy*** I thought I responded this morning -- the post isn't showing up in
Groups, but luckily I saved a copy ***
Post by Oliver OliAt this point I'm thinking json-template is less elegant than a
standard templating language. Wouldn't it be much easier to have
access to the global namespace / root elements?
like
{.section $admin}
{.end}
but I'm having the feeling that I'm missing something. Could you
explain for what we need predicates?
For the case of testing if "admin" is set at the root, it's possible
that could work.
But in general it doesn't work. There were some very long discussions
about this on the group. This might get you to them since Groups
search is also broken:http://www.google.com/webhp?hl=en#hl=en&source=hp&q=predicates+json+t...
1. Sections test if a namespace exists and then *push* the current
context into it. So they do 2 things.
This leads to a fundamental asymmetry of sections -- the "main" block
is executed in a different context that the "or" block is.
2. Predicates are arbitrary tests. They can also test if a namespace
exists, but in general are user-specified.
The syntax of trying to put user-defined tests into sections was also
problematic, in addition to the semantic problems.
So I think if we just provide something as simple as {.section $admin}
it should be fine. The idioms just haven't been worked out yet. I
was propoing {.attr admin?} or it can also be spelled {.if attr
admin}.
Just plain {.admin?} or {.if admin} is possible and definitely looks
nicer, but it leads to some potential ambiguity. In any case, the
user can actually program this any way they want, but I would like to
make something standard to relieve them of thinking about it if they
don't want to.
Andy
--
You received this message because you are subscribed to the Google Groups "JSON Template" group.
To post to this group, send email to json-template-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to json-template+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/json-template?hl=en.