On Sat, Aug 13, 2016 at 8:06 PM, Adrian Salceanu <[email protected]> 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. >> >> >>
