Thanks Yes, I've thought about a few ways to mitigate some of these issues:
1. in the app I can setup a module (like Render) and evaluate into this module exclusively. Hence, another approach might be to have some helper methods that setup the variables in the module and then eval the template itself inside the module too (must try though). So something in the lines of: set(:foo, "foo") set(:bar, [1, 2, 3]) parse_tpl(ejl"""$(foo) and $(bar)""") # all the above gets parsed in Render 2. break the parsing in 2 steps: a. reading the template string and parse it to generated Julia code (as strings) (an array of Julia code lines) - cache it b. (load strings from cache and) eval the code together with the vars === Another approach (which is how it's done in one of the Ruby templating engine) is to generate a full function definition, whose body parses the template and takes the variables as params. And then eval and execute the function with its params. However, I'm still struggling with the metaprogramming API as for instance parse() chokes on multiple lines, and I couldn't find a functional equivalent of a quote ... end blocks. But I'm hoping include_string() will do the trick (must test though). sâmbătă, 13 august 2016, 15:20:01 UTC+2, Yichao Yu a scris: > > > > On Sat, Aug 13, 2016 at 8:06 PM, Adrian Salceanu <[email protected] > <javascript:>> wrote: > >> That's pretty difficult as my goal is to use embedded Julia as the >> templating language. Similar to Ruby's ERB, ex: >> http://www.stuartellis.eu/articles/erb/ >> >> So say in the template I have something like >> >> <% if foo == "bar" %> >> Bar >> <% else %> >> Baz >> <% end %> >> >> The idea is to use Julia itself to parse the code block and Julia will >> raise an error is foo is not defined. So I can't really look it up. >> > > It's ok to use the julia syntax and parser but it's a pretty bad idea to > use the julia runtime to actually evaluating the expression, and absolutely > not by making them reference to local variables. > > For a start you are not allowed to reference local variables by names > anyway. > You also shouldn't allow reference to/overwrite of other local variables > (i.e. the template namespace should be fully isolated and independent of > any scope in the template engine). > > Since you want to eval, it seems that efficiency is not an issue, in which > case you can create an anonymous module and eval/create globals in that > module. This should also be reasonably fast if you are only using the > template once. > > If you want to use it multiple time and compile the template, you should > then scan for variable references in the expressions and process it from > there. > > >> >> I can either do >> >> <% if _[:foo] == "bar" %> >> >> or >> >> <% if _(:foo) == "bar" %> >> >> but it's not that nice. >> >> >> sâmbătă, 13 august 2016, 13:24:18 UTC+2, Yichao Yu a scris: >>> >>> >>> >>> On Sat, Aug 13, 2016 at 7:13 PM, Adrian Salceanu <[email protected]> >>> wrote: >>> >>>> Thanks >>>> >>>> It's for a templating engine. The user creates the document (a string) >>>> which contains interpolated variables placeholders and markup. When the >>>> template is rendered, the placeholders must be replaced with the >>>> corresponding values from the dict. >>>> >>>> The lines in the template are eval-ed and so Julia will look for the >>>> variables in the scope. So the vars should be already defined. >>>> >>> >>> You should explicitly look up those variables in the dict instead. >>> >>> >>>> >>>> Yes, ultimately I can force the user to use a dict (or rather a >>>> function for a bit of semantic sugar) - which is preferable from a >>>> performance perspective, but less pretty end error prone from the user >>>> perspective. >>> >>> >>> >
