On Mon, May 25, 2009 at 1:29 PM, Martijn Faassen <[email protected]> wrote: > > 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.
I really can't see the whole picture from this description. An example would be necessary to explain this to users anyway. 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/ These systems actually assume you're generating HTML; JSON Template is for generic text and thus has no knowledge of the output. >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). What are your event handlers doing? Why don't you just include their names in the data dictionary? >> 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. Yeah that's the kind of thing that smells funny to me. 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. 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? var items = [ {.repeated section items}{@|js-string}{.end} ]; >> 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. You have to call the render() callback in the right order, since obviously the template itself specifies an order. But sections of the template can be *evaluated* in any order. If I have 3 children, I can do _Execute(3), _Execute(1), _Execute(2) in parallel, and then assemble the results in the correct order. 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) > * 'log'. configurable logging functionality is going to be hard to > implement too with this particular constraint on any implementation. As mentioned, logging isn't part of the language at all (how could it be?). It's just there for debugging the implementation. Anyway, I'm not really seeing it, but an example would help. The main issue is that the application of the hooks seems very narrow. It also seems to break some barriers that were there before. I think of JSON Template as a very simple operator, like % in Python. Template is on the left, dictionary is on the right, and you get a result string in a single atomic operation. The internals aren't specified. It should be possible to do what you want by just subclassing _ScopedContext too. I think you would override PushSection(), Pop(), and next(), calling the superclass methods while adding your own behavior. Although as mentioned, I would like to keep the surface of the API small. Andy --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
