Hey,
On Mon, May 25, 2009 at 9:49 PM, Andy Chu <[email protected]> wrote:
> OK, I'll have to look at this in more detail, but to get a sense for
> what it's doing, a full example of the client code would help. I
> would just write it as JavaScript for now, and not worry about
> language-independent tests. If you can include an HTML page/template
> that would help too. I'd need to try it out and run it myself.
I can't show a full example of client code as it's part of a large
codebase, but the principle is very simple:
Currently I need to write this each time I need to pass along data
when setting up an event handler (the javascript view system we have
sends out an event after each expansion, so we can hook into that to
set up event handlers for whatever got expanded) :
<div class="my_data" style="display:none">{my_data}</div>
and then some javascript code to scrape that out of the document again
(imagine this also for a repeated section):
value = scrape_data(node, 'my_data')
This is annoying. The template has to be modified with things that
have nothing to do with what you see, just to support event handlers
that may need this data. This while the data is available all this
time, parsed and ready, in the json data structure.
With my modifications, I can use my existing templates without
changing them and without them having any knowledge of event handlers,
and then can just get the information without scraping:
value = get_node_lookup(json_data, node)('my_data')
(parsed and all, in the original format as it is in JSON)
The template is out of the loop now and can stay very simple and focus
on what's visible. Because I pass in the node, it'll get the data in
the proper context (it'll know when section and repeated section were
used to produce the HTML). So, if my node is generated by some nested
structure like this:
{.section foo}
{.repeated section bar}
{.section qux}
<div>{frobz}</div>
{.end}
{.end}
{.end}
{.end}
if I get hold of the <div> in there and use that as the node, it'll
give me a lookup function that works in the context of
foo.section[x].qux.
> Off the bat, from your example, it seems odd to write into directly
> the page from the beforeSection callback. I would just include that
> in that data dictionary, and the template would have a substitution
> for it. I think the property that the template is *not* modified
> isn't a feature, but something that will obscure what's going on to
> template authors. Better to be explicit than implicit.
I think the coin finally dropped. Sorry, that was the whole point of
what I've been talking about for a few days now. I told you that I
went a step beyond inserting paths manually.
"Explicit is better than implicit" is not about doing away with
abstraction or automation. The whole point of this exercise is to
automate the need to write this stuff away. All this is entirely
explicit, as the hooks that do this are installed explicitly.
You can very easily explain this behavior. You just say that
{.section} and each {.repeated section} are replaced by some snippet
you can configure.
There are additional constraints you put on the template writer, of
course. The template writer probably shouldn't be doing this when
these hooks are installed:
The list is: {.repeated section foo}{foo}{.repeated section}
(though that quite possibly may work as the divs inserted are invisible)
I think it's fine to put minor additional constraints on template
authors, just like you put constraints on the authors when they write
HTML instead of plaintext. After all, it's up to the developer to use
these hooks or not.
> Another consideration which I mentioned briefly in a bug is that the
> evaluation order in JSON Template isn't constrained by the language.
> It's a purely functional language. All the constructs can be
> evaluated in any order whatsoever, and then the final pieces assembled
> in sequence to produce the output. Adding these callbacks will
> constrain an implementation to sequential evaluation.
The implementation is already constrained, as it's *this*
implementation. The following is already in your public API:
* the 'render' function from Template then. It takes a callback that
is expected to be called in a particular order.
* 'log'. configurable logging functionality is going to be hard to
implement too with this particular constraint on any implementation.
Anyway, my code won't have to change one bit, as there is no
order-dependency in my particular hooks (except that the data_dict
needs to be preprocessed before the rest gets executed, which I think
is entirely reasonable). You could easily make this part of the
definition of any such hooks.
You could of course make this behavior part of the language definition
if you wanted to. You'd have to define some mechanism by which people
can supply snippets that get expanded each time a {.section} or
{.repeated section} is encountered.
Something like this in options might do:
directive_expansion: {
section: '<div class="this" id="{_path}"></div>',
repeated_section: '<div class="this" id={'_path'}></div>'
}
_path is of course pushed in by preprocessing the JSON.
> For a path syntax, note that there is something called JsonPath, like
> XPath for JSON:
>
> http://goessner.net/articles/JsonPath/
> It's not extremely common or standardized AFAICT, but worth looking at.
Thanks, I heard of it before and it's cool. Might be overkill for what
I'm trying to do, don't know; it was easy enough to roll this by hand
to get started, but using that syntax might make the resulting HTML a
bit easier to read.
Regards,
Martijn
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
