Hey,
On Tue, May 26, 2009 at 1:02 AM, Andy Chu <[email protected]> wrote:
>
> On Mon, May 25, 2009 at 1:29 PM, Martijn Faassen <[email protected]>
> wrote:
> I think you're trying to avoid duplicating information in both the
> data dictionary (a JSON tree) and the template string (HTML DOM tree).
> But this seems like a convoluted way to do it.
>
> How would you do this if you were using another template engine? e.g.
>
> http://code.google.com/p/google-jstemplate/
> http://beebole.com/pure/
I don't know, I haven't looked these template engines. In case they
can't do what I want, should json-template be restricted to what these
languages can do? I'm trying to be creative here. :)
> These systems actually assume you're generating HTML; JSON Template is
> for generic text and thus has no knowledge of the output.
I know that, but it also has support for HTML output, and that's what
I care about. That doesn't mean I want to stop anyone else from doing
something else; I just want it to support what I want to do. I'm
obviously exploring patterns and ideas here.
> From what you're saying, a template preprocessor shouldn't be ruled
> out as a solution. The language was designed to be trivially parsed
> (it can be split into tokens with a single regex.split() call).
Sure, a preprocessor would work too. In fact it'd be possible to
change the compilation process too to insert the fragments whenever a
{.directive} is used; I think that could lead to a pretty clean API.
> What are your event handlers doing?
My event handlers do a variety of things. Generally I render a list of results:
<div>1<a>More..</a></div>
<div>2<a>More..</a></div>
<div>3<a>More..</a></div>
Each entry has an icon you can click on, the server will place it on
some list then, or remove it. The URL that is accessed to to
add/remove a particular item should be known to the event handler, but
is not directly embedded in the template.
Each entry has an 'expansion' icon (say the "More..." link) to find
out more information about this item. Again, the URL that is accessed
to find the expanded information (which actually results in the
rendering of another json-template, but that's not relevant) should be
known to the event handler but isn't directly embedded in the template
as it isn't displayed.
Each entry has an application internal 'unique_id' piece of
information that isn't displayed, but that a drag & drop event handler
uses to set up drag & drop behavior.
> Why don't you just include their names in the data dictionary?
I need to think through what you mean exactly, but:
I think the template should be for displaying things, the data
dictionary should be for (RESTful) data and URLs and the javascript
should be for implementing the event handlers for whatever is
displayed. The javascript is the bit where the HTML DOM and the JSON
data needs to be combined, as an event handler needs both pieces of
information. The JSON data could be embedded in the HTML to accomplish
this.
I think what you just suggested is doing it the other way around:
embed ids in the JSON and then put them in the HTML too in the <a
id="{id}">More...</a> links. Then to hook up event handlers, you could
loop through the JSON structure to find the ids, and then dig up the
id from the HTML using getElementById. Then you can hook up the event
handler, and your loop through the json will be in the right context
to look up data from the surrounding JSON. I think that's an
interesting approach and I'll have to think more about it; it turns
around what drives the functionality that sets up event hooks and
moving the loop from going through the DOM to going through the JSON.
One drawback I see here is that it requires the modification of both
the JSON structure and the template to support this pattern. In my
approach, the template and JSON structure remain unaffected. In
addition, more knowledge about name lookup and the JSON structure
would be required in the javascript, whereas in my approach I reuse
the lookup mechanism of json-template.
[snip]
>> 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.
>
> Yeah that's the kind of thing that smells funny to me.
You're bound to constraints anyway if you're outputting HTML, and
you'll only be found to these constraints if you actually use this
functionality (which should be in an extension).
> You're
> avoiding what appears to be a small amount of duplication, in favor of
> magic. I'm not sure it's a net win.
One person's "magic" is another person's automation. The evaluation
should be whether the automation is brittle and hard to predict. I
don't think it has to be, but that's what I'm finding out by using it.
Anyway, you won't have to use this. I'm just looking for ways to hook
into the system to allow this pattern at all.
So what I'm suggesting is some form of hooks that allow {.directive}
to be replaced in the output with a particular snippet, along with
*some* form of public API where I can use the same lookup mechanism as
json-template does for name lookups.
> What if I want to use a {.repeated section} for something that has
> nothing at all to do with the DOM? Like I'm generating JavaScript in
> the <head> of the document?
That's indeed a problem scenario - I don't have this problem in my
particular use case as the page is composed out of a number of smaller
templates. Anyway, I'm not proposing you use this or that this gets
folded into the core. I just want enough support to exist in the core
to support my use case.
> It's possible you can still do that with the hooks, but it makes
> things more complicated. This is a minor concern; the real concern is
> if people would actually use these hooks for anything beyond what
> you're describing. (I haven't seen it yet)
You won't see a lot of creative approaches to use the hooks as I'm the
only one talking about them right now... Maybe we won't ever see 'm.
The other use case I can see for this kind of insertion behavior is
for debugging by inserting comments like this:
<!-- {.section foo} -->
[snip]
> It should be possible to do what you want by just subclassing
> _ScopedContext too.
I'm not sure I understand; _ScopedContext cannot modify the template's
output as it doesn't have any access to the callback.
In an earlier patch I did include some modifications to _ScopedContext
to construct the paths, and those could be done by subclassing
instead. Instead I now construct the paths by going through the JSON,
following your recommendations.
> Although as mentioned, I would like to keep the surface of
> the API small.
That's what I'm trying to do. The two things I need exposed are:
* a way to insert extra snippets whenever {.section} or {.repeated
section} is used (basically anything that can change the scope). Can
be accomplished using hooks as I have in my patch, or by a
modification of the compilation process or even a preprocessor, which
likely would be more efficient. If by preprocessing, I'd like the
logic available externally that can help in constructing one.
* a way to look up a name in a data dict given a particular path
(which can be indicated by a list of objects, doesn't need to be
serialized to a string) that indicates the scope. I.e. exposing
_ScopedContext.Lookup without exposing the rest of _ScopedContext too
much.
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
-~----------~----~----~----~------~----~------~--~---
