Consider pluggable rendering engines

[seancorfield]

Based on the experiment on the mustache branch, it would be reasonable to standardize a file extension list and mapping to a renderer, to allow views -- and layouts -- to be written in a number of different styles.

For example, the .cfm renderer needs no initialization and just includes the viewPath in the context of the internalView(), internalLayout() functions' local scope.

A .mustache renderer would build a Mustache factory at initialization, and then in the render, it would compile and execute the template.

This would also allow the list of acceptable file extensions to be provided (right now we check for CFML and Lucee -- but no one is using Lucee so we could make that configurable).

[jmohler1970]

Let me see if I understand.

The views could be .mustache files. Would these be processed via a CF Mustache engine? A Java Mustache engine?

Would FW/1 distribution include the files to do this setup?

Is mustache the only alternative rendering engine to be support? Is JSTL possible?

[seancorfield]

The idea behind this ticket is that you could specify different rendering engines based on file extensions and FW/1 would look for all those file extensions, in order, and use the specified engine. The API would be deliberately simple so it would be easy to write new rendering engines, packaging whatever template tech you want.

The mustache branch happens to use the Java engine for rendering templates (because it's very fast and it's well-maintained). Someone could probably wrap the CF Mustache engine instead if they wanted. I would expect additional rendering engines to come from the community -- I don't know what would "ship" with the framework vs what would be in separate repos / libraries. I'll probably create a Selmer wrapper for folks using FW/1 with Clojure code at some point.

FW/1 5.0 is a long way off -- 4.0 is Alpha at the moment and there will be a 4.5 release to pave the way for the re-architecture of FW/1's "Application" lifecycle methods (see #397).

[cybersonic]

Is the moustache branch comited? Can't see it in the repo.

We are looking at implementing moustache. What would a Moustache adapter look like to FW/1? Would it basically be a CFC with a .render(contextdata) function that returns a string?

[ddspringle]

@cybersonic As far as I know this is on the develop branch (for 4.5.0). There is an example application here: https://github.com/framework-one/fw1/tree/develop/examples/mustache. That said I haven't tried it myself yet ;)

[seancorfield]

The mustache example shipped with 4.1.0 -- see http://framework-one.github.io/documentation/4.1/changes.html

This issue as a whole isn't addressed fully. The mustache example led to some new extension points in the core FW/1 file but the file extension issue was side-stepped completely for that.

[seancorfield]

This is one of those enhancements that I really like the idea of but I seem in a minority: almost no CFML developers who use FW/1 have said they need this functionality, and only a handful of people have expressed interest, even out of curiosity.

[dnando]

I would be interested in this enhancement down the line, as it would make my views more portable.

Aria Media Sagl +41 (0)76 303 4477 cell skype: ariamedia

On Thu, Sep 14, 2017 at 7:34 AM, Sean Corfield notifications@github.com wrote:

This is one of those enhancements that I really like the idea of but I seem in a minority: almost no CFML developers who use FW/1 have said they need this functionality, and only a handful of people have expressed interest, even out of curiosity.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/framework-one/fw1/issues/428#issuecomment-329378444, or mute the thread https://github.com/notifications/unsubscribe-auth/AAh2n4uDpJql4mYBPoSs9Qp5mRLNB6q5ks5siLrygaJpZM4H5V4V .

[seancorfield]

What templating engines do you think you'd use @dnando ? Also, would the current hooks added in 4.1 to support Mustache be sufficient?

[dnando]

Hi Sean,

To be honest, I haven't thought this through or done the needed research. It just struck me as a useful means to make views more portable when I first saw it, to Selmer for instance or https://github.com/fotoetienne/cljstache.

Is that the intention of this feature, or am I missing something?

Thanks!

Aria Media Sagl +41 (0)76 303 4477 cell skype: ariamedia

On Thu, Sep 14, 2017 at 7:51 PM, Sean Corfield notifications@github.com wrote:

What templating engines do you think you'd use @dnando https://github.com/dnando ? Also, would the current hooks added in 4.1 to support Mustache be sufficient?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/framework-one/fw1/issues/428#issuecomment-329559153, or mute the thread https://github.com/notifications/unsubscribe-auth/AAh2n3IlYmTJf8wRFZ9vWs3xFm44WrD4ks5siWebgaJpZM4H5V4V .

[seancorfield]

Bear in mind that I've pulled Clojure support out of the core (but if folks wanted to use Clojure templating libraries and install cfmljure themselves, that's reasonable).

The question is whether the makeMethodProxies() utility and the customTemplateEngine() extension point are sufficient, or whether more machinery is needed to deal with file extensions (for example).

The mustache example overrides customizeViewOrLayoutPath() to force all paths to have .html extensions and the customTemplateEngine() example pays no attention to the file extension -- but both functions could coordinate on file extensions, based on type/path etc.

[dnando]

Bear in mind that I've pulled Clojure support out of the core (but if folks wanted to use Clojure templating libraries and install cfmljure themselves, that's reasonable).

I need to rewrite a large app to ensure it will work long term, and bring it up to more modern mobile first front end standards.

When you pulled Clojure support out of FW/1, you suggested that FW/1 wasn't providing any value over Compojure. My impression now is that the best way to transition a CFML app to Clojure would be to jump in completely. From your reports, cfmljure seems to only work acceptably on Lucee 4.5, so that's another indicator that it may be best to move completely to Clojure. The thought then is how to make the transition, especially when you need an optimally functioning product during the transition.

While I am reworking the views to mobile first, switching to mustache while I'm there would be simple. My thought is that this may help ease the transition to using a Clojure templating library down the line. I could reuse most of the code in my CFML views. Does this seem reasonable to you?

The question is whether the makeMethodProxies() utility and the customTemplateEngine() extension point are sufficient, or whether more machinery is needed to deal with file extensions (for example).

The mustache example overrides customizeViewOrLayoutPath() to force all paths to have .html extensions and the customTemplateEngine() example pays no attention to the file extension -- but both functions could coordinate on file extensions, based on type/path etc.

The only thought I have is that it would be useful if both cfm and a custom template could be supported within the same application. That way development on an existing app could proceed without breaking the whole thing until all the layouts and views were rewritten. Is that currently possible?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/framework-one/fw1/issues/428#issuecomment-329627941, or mute the thread https://github.com/notifications/unsubscribe-auth/AAh2n_YMAejRzh_jmUQ30AxI7bLnwttDks5siarVgaJpZM4H5V4V .

[seancorfield]

This thread is getting a long way off-topic but I'd be happy to continue it on the mailing list or even in direct email... To address your key questions:

My impression now is that the best way to transition a CFML app to Clojure would be to jump in completely.

This is the approach we are taking now and routing to the legacy app or the new app at the web server level, based on the URI requested. The key thing is being able to maintain user identity across apps (we're using AzureAD on some apps and OAuth2 on others at this point).

My thought is that this may help ease the transition to using a Clojure templating library down the line. I could reuse most of the code in my CFML views.

It would certainly ensure you had lifted all the CFML logic out of your views, which will make the views more reusable, yes.

it would be useful if both cfm and a custom template could be supported within the same application

Definitely possible. customizeViewOrLayoutPath() would need to return either a .cfm path for legacy sections/items or whatever path needed for new templates, and customTemplateEngine() would look at the path and if it's .cfm simply return; (i.e., return null) otherwise process the new template.

[seancorfield]

Also, if you want to switch to Django/Twig style templates and use Java with CFML for the transition, then build the new apps with Clojure and Selmer, this looks like a good starting point for your explorations: https://stackoverflow.com/questions/2990819/django-like-templates-system-for-java

[seancorfield]

At this point, I believe the current machinery in 4.1 is sufficient to support multiple template engines and even the mixed CFML/template scenario that @dnando raised so I'm going to close this. As always, PRs to enhance the functionality are always welcome.