> The predicate strings are interpreted by the user. So you can parse
> arguments, and *interpret* any argument as a name to lookup in
> ScopedContext. This is done with the FunctionRegistry API.
If I understand this correctly, you mean that every predicate does a
RegExp to see if it should handle it? So if I have a thousand
predicates, every time there is a predicate, you do 1000 regular
expression searches to see which one should get it?
> So for example, you can implement operators with "is" expressions
> (color is "blue"), but it's not in the core language. It is
> implementable just like the Pluralize formatter.
A possible implementation of 'is' passed to a template:
new Template( tpl_str, options:{ predicates={
'is': function(str, context, args) {
if (!this.isRE)
this.isRE = new RegExp('^(not\\s+)?"?(.*?)"?$');
var matches = args.match(this.isRE);
var val=matches[2]||'';
matching= str==val;
return matches[1] ? !matching : matching;
}
}})
> Can you try to implement the FunctionRegistry API in JS/PHP? Your
> implementation is still hard-coding a lot of things (the use of
> _CALL_RE demonstrates this; that should go away). FunctionRegistry
> sublasses/ChainedRegistry is the "Composite" and "Chain of
> Responsibility" design pattern if you are that kind of person.
I haven't looked at the Python version. What I have in the JS and PHP
versions is this: more_formatters and more_predicates both get the
first opportunity to parse the entire string, decide what the
formatter is vs. what the args are, etc. If those don't return a
result, then I use _CALL_RE assuming that we just have a non-regex
string match for the formatter or predicate (this is where the default
ones get picked up). The function itself does the regex for the args.
But I see now, that if I move this to compile time, it will be faster.
I'm able to serialize the compiled template on the server side so I
don't have to reread and compile it there, so this will be
particularly helpful.
I suppose my example could be more like this --- predicates:
{ regex_str1: predicate1, regex_str2: predicate2}
new Template( tpl_str, options:{ predicates={
'^is (not\\s+)?"?(.*?)"?$' : function(str, context, args) {
var val=args[2]||'';
matching= str==val;
return args[1] ? !matching : matching;
}
}})
Or every predicate/formatter is an object { regexp:'^is (not\\s+)?"?
(.*?)"?$', fn: function(str,context,args){...}, name:'The IS
predicate' }. I guess I'll see what is in the Python version...
> I think that will clear things up. Most of this mail misunderstands
> what is already there.
I find Python hard to read for the impatient. I'll have to slow down
and look at the registry code. I was thinking that it was simply a way
to deal with Python's issue of calling with a variable number of
arguments, that I didn't think to look that there was more there.
> If you want to never use ?, that's already possible with my scheme.
> You just use ".if". {.if foo} is perfectly legal -- {.if color is
> "green"} is also legal, where the predicate is 'color is "green"'.
> The entire predicate is parsed by the user at *compile time* via
> FunctionRegistry and applied by the template engine *at runtime*.
OK, this makes more sense now. I'll have a look this week, and see
about how to move it into JS and PHP.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
