Fwd: Rendering views using Mustache

[Sean Corfield]

Inspired by a random comment on Slack this afternoon, I wondered what it would take to get FW/1 rendering views using Mustache templates instead of native CFML.

It turned out to be a lot simpler than I expected.

Here’s an example (on the mustache branch off 4.0.0):

https://github.com/framework-one/fw1/tree/mustache/examples/mustache

The controller is a regular controller. It does whatever and sets up rc data as normal.

The view is a simple Mustache template that uses rc as its “context” so {{name}} means rc.name and so on.

The magic all happens in Application.cfc (create Mustache factory object, override internalView() to use Mustache to compile .html files instead of just including .cfm files.

It uses the Java version of Mustache. Here’s the manual for Mustache templates:

http://mustache.github.io/mustache.5.html

Mustache templates are fast to render and deliberately include no logic (they support implicit loops and conditionals based on data). The compilation seems to be cached (so changing a view needs an application reload to be picked up – I haven’t dug into that to see if it could / should automatically recompile changed files).

This could be cleaned up and made somewhat pluggable to allow a variety of rendering engines based on file extension (for example).

If enough folks are interested…?

Sean Corfield -- (904) 302-SEAN
World Singles -- http://worldsingles.com/

[Mark Drew]

Awesome work fella! I did a cfmoustache tag extension for Railo a while back and this looks epic :)

Mark Drew

- Sent by typing with my thumbs. 

--
FW/1 documentation: http://framework-one.github.io
FW/1 source code: http://github.com/framework-one/fw1
FW/1 chat / support: https://gitter.im/framework-one/fw1
FW/1 mailing list: http://groups.google.com/group/framework-one
---
You received this message because you are subscribed to the Google Groups "framework-one" group.
To unsubscribe from this group and stop receiving emails from it, send an email to framework-on...@googlegroups.com.
Visit this group at https://groups.google.com/group/framework-one.
For more options, visit https://groups.google.com/d/optout.

[Mark Drew]

I think I meant markdown actually but still this is pretty epic. 

Mark Drew

- Sent by typing with my thumbs. 

On 26 Mar 2016, at 03:21, Sean Corfield <se...@corfield.org> wrote:

[Richard Tugwell]

Interesting. Would you have to forego things like buildURL() and view()?

--

=================================
Richard Tugwell
http://blog.richardtugwell.com
r.tu...@forthmedia.com

[Mark Drew]

Not sure about in this implementation but you should be able to run functions like:

{{buildUrl "section:action"}}

Mark Drew

- Sent by typing with my thumbs. 

[Sean Corfield]

Good question. Using the Java Mustache library – which is very high performance – the callable functions would actually have to be in Java I believe (or at least callable as closures _from_ Java) and I’m not entirely sure you could engineer a dynamic proxy to make buildURL() callable in the context of the FW/1 object…?

 

Might be worth a try tho’…

 

Sean Corfield -- (904) 302-SEAN

An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[Sean Corfield]

And the answer is: yes you can:

 

https://github.com/framework-one/fw1/blob/mustache/examples/mustache/Application.cfc#L20

 

https://github.com/framework-one/fw1/blob/mustache/examples/mustache/views/main/default.html#L8

 

And here’s the Java 8 Function interface implementation:

 

https://github.com/framework-one/fw1/blob/mustache/framework/BuildURL.cfc

 

(you’d need one of those for each function you wanted to be able to call – or it would need to be generic… and I think it can only take one argument: the text between the open/close function tags)

 

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

 

[Richard Tugwell]

To be honest, in most of the work I'm doing at the moment "view" rendering is mostly done on the client side (angularJS or React e.g). FW1 does initial work on the server side to deliver the web page, with appropriate logic to do stuff like layout and navigation based on business logic, and also provides an API that the front end uses to provide UI/UX stuff and interaction. Views will be partials done through routing mechanisms. Normally I'll have a series of SPA's each of which is delivered by an FW1 section , or even a section.item, depending on complexity. Although I appreciate this development, it just seems to me to complicate matters

[Mark Drew]

That is epic Sean! 

Thank you so much!

Mark Drew

- Sent by typing with my thumbs. 

[Sean Corfield]

Updated so you can call either FW/1’s view() to pull in another Mustache template or use “partials” (includes) in Mustache itself:

 

https://github.com/framework-one/fw1/blob/mustache/examples/mustache/views/main/default.html#L9-L10

 

(note the difference in paths!)

 

The function proxy mechanism is now generic and can be extended to any (single argument) FW/1 function:

 

https://github.com/framework-one/fw1/blob/mustache/examples/mustache/Application.cfc#L20-L26

 

I stuck a “fw1_” prefix in there to avoid conflicts with data in rc.

 

> Although I appreciate this development, it just seems to me to complicate matters

 

Well, this has come from a number of places:

 

·       FW/1 for Clojure uses Selmer for views which is based on Django templates, so it’s a widespread style of handling views;

·       The possibility of “pluggable” alternative templating engines for Lucee (and for ColdFusion, to be honest) has cropped up in a number of forums, multiple times, with Mustache or Django-style templates as one of the possibilities;

·       Carl (Von Stetten) spurred me to try this because he was asking about “how much logic belongs in a view” and he’s fairly new to MVC-structured applications;

·       One of the big problems with CFML is that it allows arbitrary code in the views – indeed in “old-school” CFML apps, there were only views and they contained all the logic: a big ol’ pile of spaghetti! So we moved to more structured approaches (like Fusebox act / dsp file conventions, then full-blown MVC) but we still have the _temptation_ to put too much logic in views… “because we can”…

 

So the (potential) benefit here of using Mustache for views in a FW/1 app is that it actually _simplifies_ the views by restricting what logic you can put in them, and that in turn answers the (common) question about “how much logic” is too much in a view. In addition, I’d be inclined to bet money on a Mustache-driven FW/1 web site being _faster_ than a regular CFML view-based website (because that Mustache engine is highly tuned and is not “a full programming language”).

 

Of course, if you already have almost no logic in your CFML views, this is somewhat moot.

 

Still… think of this as a concept car at an auto show, giving a glimpse of what a future world _might_ look like!

 

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

 

[Matthew Clemente]

Love this idea Sean. Very cool. Will definitely be looking into it further when work allows. 

Keep up the awesome work.

[Richard Tugwell]

Sean - thanks for the response/explanation re. my earlier comment ("complicating things"). Yes, I was just coming from a personal viewpoint. Looking at the latest changes I can see that incorporating native FW1 functions isn't that difficult. As for "simplifying" - I had to smile - yes it does force that constraint on you!

As ever - kudos for the continued development work

--
FW/1 documentation: http://framework-one.github.io
FW/1 source code: http://github.com/framework-one/fw1
FW/1 chat / support: https://gitter.im/framework-one/fw1
FW/1 mailing list: http://groups.google.com/group/framework-one
---
You received this message because you are subscribed to the Google Groups "framework-one" group.
To unsubscribe from this group and stop receiving emails from it, send an email to framework-on...@googlegroups.com.
Visit this group at https://groups.google.com/group/framework-one.
For more options, visit https://groups.google.com/d/optout.

[Sean Corfield]

The thought experiment I did last year has now been merged to *develop* as a “standard” example. It has been tested on ACF 10, 11, 2016, Lucee 4.5, 5.x. I’m going to do a little clean up on it and provide a formal extension point for alternative rendering engines. And maybe document it 😊

 

Not having to support CF9 has made a lot of things easier…

 

Sent from Mail for Windows 10

[Joe Mesot]

Just coming across this now as we are looking to implement templating into our CMS for the front end.

How would I go about testing this out? (not a CF Developer btw).

[Sean Corfield]

If you’re using FW/1 4.1.0 or 4.2.0, this is built in and you can see an example of it here https://github.com/framework-one/fw1/tree/develop/examples/mustache

 

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN

An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

 

---

From: framew...@googlegroups.com <framew...@googlegroups.com> on behalf of Joe Mesot <joe....@gmail.com>
Sent: Wednesday, December 26, 2018 3:24:09 PM
To: framework-one
Subject: [framework-one] Re: FW/1 4.1.0: Rendering views using Mustache

 

--

[larryclyons]

I haven't touched Mustache in a couple of years, but one way would be to make an Ajax request to the controller which returns the data as JSON. Just a thought.

[Sean Corfield]

make an Ajax request to the controller which returns the data as JSON

 

Not sure what Ajax and JSON have to do with rendering views using Mustache (in FW/1)?

 

But then I’m also not sure what Joe is really asking either – if the CMS is written with FW/1, it’s already using CFML as the templating engine for the views. The example integration shown in the 4.1.0 download just replaces the CFML views with Mustache views instead (using the Java library that implements Mustache). If that CMS isn’t written in FW/1 already, then this discussion is moot…

 

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

 

---

From: framew...@googlegroups.com <framew...@googlegroups.com> on behalf of larryclyons <larry...@gmail.com>
Sent: Thursday, December 27, 2018 1:27:38 PM

To: framework-one
Subject: [framework-one] Re: FW/1 4.1.0: Rendering views using Mustache

--