On Tue, Aug 16, 2016 at 4:37 AM, Adrian Salceanu <adrian.salce...@gmail.com>
wrote:
>
> I was thinking about having the module itself defined in the controller
> for example (or some other standalone .jl source file), completely outside
> the templating engine itself, and then referencing the variables defined
> within this module. Are you saying that in this case, the module itself
> would not be compiled?
>
It has nothing to do with "compiling" a module. I'm just saying it's not
the right API. A sane interface should allow the user to pass in parameters
as arguments. Using a single module like this will also block any kind of
concurrency since calling the template with different parameters will
either be impossible or have to modify globals.
> In the module, and `include_string()` reference those globals.
>
> If I have
>
> module TplVars
> const var1 = "foo"
> const var2 = "bar"
> const var3 = 42
> end
>
> and then from the template file I reference them
>
> ejl"""
> <html>...
> <p>
> $(TplVars.var1)
> </p>
> </html>
> """
>
> would that still be in the global scope?
>
Yes.
> How would I know that "lang" is the name of one of the vars, without
rolling my own julia-like parser?
(At template compilation time) Parse the expression using the julia parser,
iterate through the result object, check if the type of expression is
supported and pull out the external references.
You can see what the expression object is with
```
julia> dump(:(lang == "en"))
Expr
head: Symbol call
args: Array{Any}((3,))
1: Symbol ==
2: Symbol lang
3: String "en"
typ: Any
```
FWIW, what you want to implement is a julia-like parser anyway.
> Right. So if I execute "eval()" and "include_string()" within a module
other than Main (currently doing this into a dedicated Render module) would
that be ok?
It's always global scope, if that's what you mean by OK.
