sebastienros/fluid

{% render "filename" %} with custom extensions

Opened this issue · 5 comments

brmassa commented

Currently, {% render "filename" %} will only look for a file called filename.liquid. However, would be great to make it use the IFileProvider to figure out the proper file, allowing users to customize this behavior.

It's particularly good if the liquid template is actually creating a known format in IDE, like HTML, CSS. Using the destination format extension like filename.html, filename.css, filename.liquid.html would allow the IDE to highlight the code properly.

it's somewhat related to #357

probable targets:

  • Fluid/Ast/RenderStatement.cs
  • Fluid/Ast/IncludeStatement.cs
hishamco commented

I think it's fine to keep it as its. In your case, you can customize FluidMvcViewOptions

brmassa commented

but this implies using MvcViewEngine, right? My app is a console one. when creating the parser, we already provide a IFileProvider to mostly inform the "root" path.

the proposed solution is to implement some kind of virtual method to search for and resolve the right filename. If the MVC already provides a bit of this, would be great to migrate the core into the parser itself.

In short: there is a use case for using kinda some of the MVC functionality without the need for the full-blown MVC framework.

  • 👍1
mihail-brinza commented

Bumping this topic,
I was trying to use Fluid and wanted to store all my templates in the cloud, and having an IFileProvider would allow us to customize how the file is fetched.
I could open a PR to implement this if anyone would be interested to take a look.

sebastienros commented

There is already an IFileProvider in the general options:

https://github.com/sebastienros/fluid/blob/main/Fluid/TemplateOptions.cs#L19-L22

So you can set it as default options or per template (in TemplateContext). You can provide a custom implementation of IFileProvider to return the stream you want to use for any filename. Can you try them and let us know if that works?

mihail-brinza commented

Thank you, that'll work. For some reason I missed the usage file provider in Ast/IncludeStatement.cs but it's there.
The only minor downside is that the interface is not prepared for async I/O operations.

I'll post an update after I finish the implementation.