Multiple template engines for components / preview templates (e.g. by file extension) #191

Open
jkphl opened this Issue Dec 11, 2016 · 2 comments

Projects

None yet

2 participants

@jkphl
jkphl commented Dec 11, 2016

I'm about connecting Fractal and TYPO3 (a PHP based CMS). While TYPO3 doesn't have a dedicated component concept, one can well organise his work appropriately and export component-like entities to Fractal. I'm using a custom Fractal CLI command for this, reading the components from a custom CLI interface to TYPO3 and setting up Fractal's component directory structure accordingly. (At the moment, both modules are proof of concept / work in progress so please excuse the lack of documentation etc.).

TYPO3 provides several different ways of rendering output which are likely to be used side by side. There's e.g. Fluid — a "real" templating engine — and also TypoScript, which is TYPO3's very own configuration syntax capable of creating output as well. They all have in common that they rely heavily on TYPO3 as rendering context (e.g. they might need to access the global TYPO3 configuration, use some of the many view helpers or rely on a HTTP request being made) so Fractal has to delegate component rendering back to TYPO3 as a "templating engine" (which I made already work for one of the component types).

However, calling TYPO3 is a comparably costly thing in terms of rendering time, so I would like to keep the calls down to a minimum — which makes me wish there was a way to register multiple rendering engines so that they could get picked e.g. by template file extension or component configuration. This seems related to what @paulrobertlloyd was calling for in #26. It would be super nice to be able to

  • use e.g. Handlebars for the preview layout (which is simple enough) but use something different for the component itself,
  • use different templating engines for different component types.

Please let me know what you think or if there's something I could contribute!

@allmarkedup
Member

@jkphl yes a few people have asked for this and it would be great, but unfortunately would actually be very tricky (impossible?) to implement with the current model of filesystem parsing that Fractal uses. That parser is due for a major re-write at some point in the near-future however, and part of that work will include adding support for being able to register multiple component-format renderers.

Very cool to see the stuff you are doing here though and once I get started on the new parser implementation it would be really great to get your feedback on whether it would help address your requirements.

@jkphl
jkphl commented Dec 16, 2016

@allmarkedup Alright, I see. I will try to work around this restriction for the time being, but it would be really nice to see it working anytime soon. I'm planning to spend some fulltime days on my open-source projects between Christmas and New Year, so maybe I'll try to come up with something for Fractal. My biggest obstacle will probably be that I'm not too familiar with ES6 syntax & features so far though, ha! Will be a good lesson for me ...

Happy to give you feedback once you're on to it. Keep up the good work, it's really inspiring! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment