Template Snippet Rendering

[ColonelPanics]

Implement a way to include renders of other templates within a master template, for example:

<%= render_template('/path/to/node-network-template') %>
<%= render_template('/path/to/node-resource-template') %>

This ability would allow for some of the more complex templates to be broken down into manageable chunks by passing the current scope into the child templates to be rendered and perhaps optionally taking the scope as an argument

[bobwhitelock]

This is already possible I believe. E.g.:

[root@localhost underware]# cat /tmp/foo
This is foo
<%= alces.render_file '/tmp/bar' %>
[root@localhost underware]# cat /tmp/bar
This is bar
[root@localhost underware]# bin/underware render /tmp/foo
This is foo
This is bar

Is there anything wrong with how this works currently?

[ColonelPanics]

@bobwhitelock I had no idea that that method existed! It doesn't exactly work as I would have expected:

[root@controller ~]# cat /tmp/partial_main
This is a file rendered for <%= node.name %>
<%= alces.render_file '/tmp/partial_part' %>
[root@controller ~]# cat /tmp/partial_part
This is sub-rendered for <%= node.name %>
[root@controller ~]# underware render /tmp/partial_main node01
error: Failed to render template: /tmp/partial_main
Failed to render template: /tmp/partial_part
Error, a Node is not in scope. Use --trace to view backtrace

The scoping really ought to be passed along somehow if that's possible?

[bobwhitelock]

@ColonelPanicks I believe that's because you're rendering against alces rather than the node namespace - every namespace should expose a render_file method to render a template against that namespace, the return value of which is the rendered template. This should be flexible and allows you to always jump back up and e.g. render something against a domain within a template being rendered against a node. But you do need to call the method on the namespace you want to render against, e.g.:

[root@localhost underware]# cat /tmp/partial_main_against_alces
This is a file rendered for <%= node.name %>
<%= alces.render_file '/tmp/partial_part' %>

[root@localhost underware]# cat /tmp/partial_main_against_node
This is a file rendered for <%= node.name %>
<%= node.render_file '/tmp/partial_part' %>

[root@localhost underware]# cat /tmp/partial_part
This is sub-rendered for <%= node.name %>

[root@localhost underware]# bin/underware render /tmp/partial_main_against_alces node02
error: Failed to render template: /tmp/partial_main_against_alces
Failed to render template: /tmp/partial_part
Error, a Node is not in scope. Use --trace to view backtrace

[root@localhost underware]# bin/underware render /tmp/partial_main_against_node node02
This is a file rendered for node02
This is sub-rendered for node02

Aside: there's also render_string for rendering a template from a string rather than a file, which is useful internally and I guess could be useful if you want to dynamically define a template to be rendered within another template being rendered (so you can template while you template).

[ColonelPanics]

@bobwhitelock PEBKAC, that's pretty much what we need then. I don't see this issue as anything that'd provide something different so glad this is sorted!

[bobwhitelock]

@ColonelPanicks OK! I think the underlying issue here is that there's a whole load of features now within Underware which are part of our templating API, and which it would be useful for users to know about, but which the only way to find out about is to either have heard that they exist before, or to view the (sometimes surprising) source location for these features. We should probably better document all of this, and keep this updated as things change (see https://github.com/alces-software/underware/issues/9).

[sierra-tango-echo]

does this work without the full path? eg

[root@localhost underware]# cat /tmp/foo
This is foo
<%= alces.render_file 'bar' %>
[root@localhost underware]# cat /tmp/bar
This is bar

We don't know where the templates are going to end up so full paths in the templates themselves can't be a thing.

[bobwhitelock]

@ste78 nope that won't work atm - relative paths will be resolved relative to where Underware itself is, so that will be looking for /opt/underware/bar. We could make render_file resolve relative paths relative to the current template when within a template instead?

Also related, and possibly worth fixing at the same time: making underware render, which uses render_file internally, render things relative to the current working directory rather than /opt/underware as well (https://github.com/alces-software/underware/issues/5).

[sierra-tango-echo]

relative to the current template makes sense but also look in the default template locations when we have default template locations :) - @ColonelPanicks knows more about those

[bobwhitelock]

From meeting earlier and more thinking:

• hold off on this for now, doesn't seem key and possibly will become irrelevant or we'll know better how this should work once https://github.com/alces-software/underware/issues/19 and related high priority things implemented;
• possibly we can solve the same use case but better by supporting render_file 'partials/foo' or render_partial 'foo' to render a partial template from /opt/underware/data/partials/foo within a top-level template?