Global partial dir

[fidian]

Split from #28 by @sc0ttj:

Partials seem not to work very well for me.. I think having an env var set like $MO_PARTIAL_DIR would be great - cos mo struggles to find the partials without defining full paths when used in more complex programs.. "Complex" means they may have scripts that live in different dirs, away from mo itself, outside of $PATH, changing $PWD a lot, etc..

Can mo be made to use a $MO_PARTIAL_DIR env var, so that templates can be made as below, and will work:

{{>my_file}}

^ should work regardless of where mo is lives, or is called from, or where the template lives... the file my_file could actually be at ${MO_PARTIAL_DIR}/myfile[.mustache]..

[fidian]

I was thinking about this but I am uncertain if this is a good idea. While it makes your instance significantly easier, I would have to explicitly define behavior so that it doesn't break for others. Imagine a folder structure like this:

• templates
  • file.tpl
  • file2.tpl
• private
  • file2.tpl
• secret
  • (no files)

Also, imagine file.tpl uses {{>file2.tpl}}. Existing behavior would load templates/file2.tpl if executed in templates/, or private/file2.tpl if it's ran in private. The partial would result in an empty string if it runs in secret/. I'm not sure if that's a good scenario, but I believe that's where we are starting. If I add the setting for a global partial directory, I assume it would be honored only if the file was not found and if the environment variable is set to a non-empty value.

The second aspect I think about is if you allow a variable name or another way to determine where the templates are so you could be more explicit.

{{> $GLOBAL_PARTIAL_DIR/partial.tpl }}

And that, I think, brings up the part where I believe the paths are wrong inside templates. Let's say I was in private/ and ran echo "{{> ../templates/file.tpl}}" | mo. It should load the file in templates/file.tpl and that says {{> file2.tpl}}, which would load up the one in private/. I'm questioning if this behavior even makes sense and maybe the paths should be relative to the file that's doing the inclusion.

Mustache spec kinda leaves this open, as though all templates are registered with the engine in advance with unique names. I could do that instead, but that would defeat some of the flexibility of this tool.

What are your thoughts?

[sc0ttj]

My first thoughts are that I really want to avoid putting the path inside the templates, even as a variable, for the reasons you outlined.

I also see the issues you mention with relative directories.. Just FYI - I would use realpath (or whatever) to set $MO_PARTIAL_DIR as a full path - just to make sure it "just works" when i'm using it in my project..

So for mo itself, my thoughts would be ...

Support a $MO_PARTIAL_DIR env variable, use it only if its a valid dir and not empty, else use current behaviour... But of course, it's totally up to you..

For me the above would work cos if I need to keep a large number of partials in different dirs, I could set $MO_PARTIAL_DIR to a few different places as needed, before runing mo.. so even for a larger project it would probably work fine..

[fidian]

Would you want to check out the search-path branch? I've added a --path parameter where you can specify the search path to use. The search path will only be used if filenames do not have a / in them, like how PATH and CDPATH work.

Example:

mkdir templates
echo "This is the file I want" > templates/wanted
echo "{{>wanted}}" | ./mo --path=templates

Using --path will automatically change relative paths into absolute ones. Multiple paths can be specified by using a colon. You can also use MO_SEARCH_PATH environment variable, and these really should be absolute paths, not relative.

# Bad
MO_SEARCH_PATH=../templates:other_folder
# Good
MO_SEARCH_PATH=/home/user/mo/templates:/home/user/mo/amazing/other_folder

Without the absolute paths, the search paths will be applied to where the templates are located, which would probably produce unexpected results.

[sc0ttj]

Sounds great, I'll have a look soon.. Sorry for the late reply.

[fidian]

My life has certainly been busy this summer, and I can easily understand if your time was consumed by more pressing things. Were you able to give the branch a test to see if it solves the problems you were reporting?