Hi there,
On Thu, May 21, 2009 at 5:49 PM, Andy Chu <[email protected]> wrote:
> So the problem with the hooks is that I don't see any use case for
> them that can't be addressed in a way that doesn't modify the core
> code.
You mean by writing a pre-processor for the templates? That's a lot
more involved than hooking into some hooks, and effectively is a way
to build new languages. json-template is already a template language.
> Putting them in the core code basically generates TODOs for all
> the other implementations, which is sometimes acceptable, but in this
> case I don't see enough reasons yet.
This particular purpose is particularly useful if you end up
generating a HTML DOM, which is probably mostly going to happen in the
context of a web browser. It may be that the other purposes make it
valuable for other languages too.
> Can you think of any other examples where the hooks are useful?
I already mentioned an example: if you want to do debugging you could
use some hooks to show (in a comment, for instance) exactly what the
state is of the local scope, or what decision has been taken by the
language (<!-- the result of an or -->).
You have logging functionality scattered through the codebase. You
could instead get rid of this logging and make it a configuration
using the hooks. Is this logging behavior part of json-template's
language definition or not, by the way?
> And why not after hooks?
Yes, something I mentioned in my initial communication about these
hooks: "(perhaps also for {.end} and {.or})". I don't have a need for
them yet, though, but for the debugging purpose it would be nice to
show you are leaving a scope, and for the logging as well.
> Why not a hook before starting all of template
> expansion and ending it?
I think a hook for manipulating the JSON structure would be useful,
though that could also be solved by subclassing. For logging such a
hook would also be useful, I imagine.
> And a hook where 'alternates' is used? I can't judge the hooks in the absence
>of real problems.
I will note that you already actually hook into the logging system in
all of those places that you mention.
And: hey, me, me, I have a real problem that needs some of these
hooks. I've been talking about this set of use cases for a few weeks
now: I do have a concrete use case of setting up event handlers
without directly embedding them into the HTML and getting the local
JSON context when I do so. I'll note most javascript libraries offer
APIs to set up events externally, presumably for a reason.
As you will recall, I also mentioned the logging system as bothering
me (and I actually still use a patched version of the codebase to
avoid the issues) - if logging went through these hooks, you could
easily disable logging entirely, or make it log to something
different.
> Also, it's probably not clear from the code, but the builder interface
> isn't meant to be public -- i.e. it could change over time
> incompatibly (and it fact it already did when I added the dotted
> lookup).
[snip]
I'm having trouble understanding what you're talking about here. I'm
not talking about expanding any public interfaces, except the
'options' object that gets passed in to 'expand' so that you can
optionally pass in a few hooks. Everything else is an implementation
detail.
What builder interface? I don't even see a reference to the word
'builder' in the code; are you referring to the compilation process?
In any case, I don't see how this is relevant to my patch as I'm not
expanding the public interface of any object except 'options'.
Did you read my patch? You can ignore the part where I put in 'name'
in the stack or the "Path" function; that can be handled by
preprocessing the JSON structure.
To allow hooks during template expansion I need to be able to pass
them in as options. I then pass these options to ScopedContext and set
them up as methods (with a default fallback to do nothing). Then I
modify the implementation to call the hooks at the right point.
>> * how would I set up the javascript tests to set up with hooks?
>
> I don't see a good way to test in a language-independent way, because
> it's a feature that depends on passing callbacks, sort of like the
> formatters.
So, how to set up tests for this?
I imagine this could be a standard test for logging; you fill in all
the hooks with log functions (implemented in the language itself), and
then you test whether you get the correct logging output.
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
-~----------~----~----~----~------~----~------~--~---
