Re: [framework-one] FW/1 and Adding Mustache Support.

102 views
Skip to first unread message

Marcin Szczepanski

unread,
May 14, 2013, 8:07:42 PM5/14/13
to framew...@googlegroups.com
At a first glance it doesn't really seem like something that belongs in core FW/1?

Off the top of my head (so could be wrong) you could just define a custom "after" function where you could check for the existence of a mustache template and if it exists you could process it and then use a special / normal view with no layout to render the contents of your mustache template (similar to what people are already doing for JSON).


On Wed, May 15, 2013 at 9:51 AM, Gary Crouch <crou...@gmail.com> wrote:
We are looking at adding support for the Mustache template engine to the processing order in FW/1.

What we are thinking is after the controller has finished and before the views and layouts are processes:
  1. We look up the existence of [item].JSON and [item].HTML files in a /mustache/[section] folder, or over ridden value (methods to be added for this similar to view overrides).
  2. These are then processed and a request.context.mustache struct populated with the hash and template and processed final string.
  3. This can then be output in the view or layout via the request context (rc).
We are thinking of adding a call to process Mustache just after line 712 in the onRequest() method of the original framework.cfc, populating request.context.mustache.

request.context.mustache = processMustache();

and a new method which can be over ridden in the extended framework object.

public string function processMustache() {
return '';
}

Does anyone have any other ideas how we can achieve this, without editing the onRequest() method in the original framework.cfc that would be excellent!

Thanks
Gary

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

--
--
FW/1 on RIAForge: http://fw1.riaforge.org/
 
FW/1 on github: http://github.com/seancorfield/fw1
 
FW/1 on Google Groups: 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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
M.

Sean Corfield

unread,
May 14, 2013, 8:16:31 PM5/14/13
to framew...@googlegroups.com
First rule of frameworks: never modify the framework code.

You can always write a CFC that extends FW/1 and overrides methods,
then have your Application.cfc extend that new CFC. That way you can
have customizations and still upgrade the FW/1 code.

Second, I'm pretty sure you can already do exactly what you need with
the existing FW/1 extension points. The general approach for a single
app is to override these extension points directly in Application.cfc
but if you're planning to build several apps with this extension,
follow the "Application extends a new CFC that extends FW/1" approach
above.

You'll want to override customizeViewOrLayoutPath() to lookup the
templates and return the appropriate path.

Then you'll want to override internalLayout() and internalView(). In
those functions, check the extension of the layoutPath / viewPath
passed in: if it's .json or .html, it's a Mustache template so render
it and return the rendered result as a string, else call
super.internal*() with the original parameters.

Sean
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

Chris Blackwell

unread,
May 15, 2013, 4:01:35 AM5/15/13
to framew...@googlegroups.com
I can see why you might want to code your views with Mustache, but surely if you look up a static json file as the data for your view you might as well just write a static html template and dispense with the rendering step?

Doesn't it make more sense for rc to be the context for the template?

controller
function userlist(rc) {
  rc.users = UserService.getArrayOfUsers();
}

view 
{{#each users}}
<li>{{firstname}} {{lastname}}</li>
{{/each}}


I've got an extension of fw/1 called cyril that overrides internalView and internalLayout to pass extra variables to the views and use a separate renderer.  It would be trivial to adapt it to use a Mustache as the renderer.

I'm not sure Mustache gives you enough features for a complete replacement of cfml view templates though. If I were going to do this i might use Handlebars as it provides a ton more features, and then run it using rhino.. haven't tried it, should work fine though.

Chris

Marcin Szczepanski

unread,
May 15, 2013, 4:55:06 AM5/15/13
to framew...@googlegroups.com
I've had success using a Java implementation of Handlebars (https://github.com/jknack/handlebars.java) with a JavaLoader.  Few dependencies to work out, but once it was implemented it worked pretty well.

I used it in a FW/1 app to render parts of the UI within a CFML view that were also going to be rendered via front-end Javascript (so using the same source templates from CF/Java/Handlebars as Javascript Handlebars).
M.

Chris Blackwell

unread,
May 15, 2013, 9:54:38 AM5/15/13
to framew...@googlegroups.com
oh thats cool, i didn't know there was a java implementation.
I wonder if you can register cf closures/functions as helpers..

Gary Crouch

unread,
May 15, 2013, 6:16:19 PM5/15/13
to framew...@googlegroups.com
Thanks for your comments I'll have a look at cyril, handelbars and rino they may help us, handelbars in particular.

What we are trying to do is not replace the current view renderer but supplement it by allowing the use of a library of snippets of layout that any given view can combine a final view.
In these snippets, typically forms, we would like to separate the prompts and labels so that customers can configure as they please, typical application could be another language.

I implemented a simple extension to fw/1, which I still consider a hack, Ok Ill tell you what I did.

private void function buildViewQueue()
{
// ADDING IN MOSTACHE PROCESSING 
request.context.mustache = processMustache();
// NOW RUN THE ORIGINAL BUILDVIEWQUEUE
super.buildViewQueue();
}

I'm thinking of dispensing with this though and just implementing a getMustache([Action]) and calling this in a standard fw/1 view.

Brian Meloche

unread,
May 16, 2013, 5:32:18 PM5/16/13
to framew...@googlegroups.com
I haven't used it, but have you looked at the Mustache.cfc project? I would think you should be able to use this to get what you need, though I don't know if you would need to fork it for FW/1 or not.

Sincerely,


Brian Meloche
Reply all
Reply to author
Forward
0 new messages