Server Side View Management

55 views
Skip to first unread message

Rockwood

unread,
Feb 10, 2012, 3:40:04 PM2/10/12
to Flatiron
Hi all.

I've been playing around with flatiron the past couple days and it
looks really awesome. I've started running into the limits of
complexity that Express can handel, and Flatiron looks like it will
solve many of those issues.

I'm trying to figure out the best way of managing views server-side.
Express has the convenience of res.render('view.file', {data}), and
I'm wondering how that translates to Plates. Being that Plates needs
to be both client and server compatible, would it be better to create
a separate flatiron plugin that loads a view file and passes that to
Plates along with a map and data object?

Here's a simple gist for illustration https://gist.github.com/1792543.

Joshua Holbrook

unread,
Feb 10, 2012, 10:48:46 PM2/10/12
to flati...@googlegroups.com
Hi Kevin,

Welcome to the mailing list! Glad to hear you're enjoying flatiron.

I haven't done much rendering with plates actually (believe it or
not), but I do know that it's not coupled to anything in particular.

What you're doing will certainly work fine. If you wanted something a
little more like express's .render convenience method, you could write
a plugin that adds a `.render` to your application. I probably
wouldn't try attaching it to res; that seems like the wrong
abstraction to me.

Cheers,

--Josh

--
Joshua Holbrook
Engineer
Nodejitsu Inc.
jo...@nodejitsu.com

Kevin Rockwood

unread,
Feb 13, 2012, 10:18:48 AM2/13/12
to flati...@googlegroups.com
Thanks for the info Josh. I'd like to create a plugin to help with view rendering. Do you know of any already in development. I don't want to duplicate any work that's already been done.

You mentioned that res.render() isn't a good abstraction. What would you suggest as an alternative? 

-Kevin
--
Kevin Rockwood | www.rockwood.me


Charlie Robbins

unread,
Feb 13, 2012, 12:24:43 PM2/13/12
to flati...@googlegroups.com
Kevin,

I disagree with Josh on this one. `res.render()` seems like a fine abstraction. Fundamentally it doesn't do much differently than `res.json()` which already exists. The fundamental problem with current `res.render` implementations is that they tightly couple themselves to the application instead of simply taking more options and using sane defaults.

I've actually been wanting to add `.render` to union. Potentially through consolidate.js (or maybe another lightweight abstraction). We should at least have `res.html` and `res.text`.

--Charlie

jesusabdullah

unread,
Feb 13, 2012, 9:59:25 PM2/13/12
to Flatiron
> I disagree with Josh on this one.

I disagree with me too. I thought about this for a while, and I
decided that `res.render` was pretty good.

> I've actually been wanting to add `.render` to union. Potentially through
> consolidate.js (or maybe another lightweight abstraction). We should at
> least have `res.html` and `res.text`.

This would be pretty sweet.

--Josh

On Feb 13, 9:24 am, Charlie Robbins <charlie.robb...@gmail.com> wrote:
> Kevin,
>
> I disagree with Josh on this one. `res.render()` seems like a fine
> abstraction. Fundamentally it doesn't do much differently than `res.json()`
> which already exists. The fundamental problem with current `res.render`
> implementations is that they tightly couple themselves to the application
> instead of simply taking more options and using sane defaults.
>
> I've actually been wanting to add `.render` to union. Potentially through
> consolidate.js (or maybe another lightweight abstraction). We should at
> least have `res.html` and `res.text`.
>
> --Charlie
>
>
>
>
>
>
>
> On Mon, Feb 13, 2012 at 10:18 AM, Kevin Rockwood <ke...@rockwood.me> wrote:
> > Thanks for the info Josh. I'd like to create a plugin to help with view
> > rendering. Do you know of any already in development. I don't want
> > to duplicate any work that's already been done.
>
> > You mentioned that res.render() isn't a good abstraction. What would you
> > suggest as an alternative?
>
> > -Kevin
>
> > On Fri, Feb 10, 2012 at 10:48 PM, Joshua Holbrook <josh.holbr...@gmail.com
> > > wrote:
>
> >> Hi Kevin,
>
> >> Welcome to the mailing list! Glad to hear you're enjoying flatiron.
>
> >> I haven't done much rendering with plates actually (believe it or
> >> not), but I do know that it's not coupled to anything in particular.
>
> >> What you're doing will certainly work fine. If you wanted something a
> >> little more like express's .render convenience method, you could write
> >> a plugin that adds a `.render` to your application. I probably
> >> wouldn't try attaching it to res; that seems like the wrong
> >> abstraction to me.
>
> >> Cheers,
>
> >> --Josh
>
> >> On Fri, Feb 10, 2012 at 12:40 PM, Rockwood <ke...@rockwood.me> wrote:
> >> > Hi all.
>
> >> > I've been playing around with flatiron the past couple days and it
> >> > looks really awesome. I've started running into the limits of
> >> > complexity that Express can handel, and Flatiron looks like it will
> >> > solve many of those issues.
>
> >> > I'm trying to figure out the best way of managing views server-side.
> >> > Express has the convenience of res.render('view.file', {data}), and
> >> > I'm wondering how that translates to Plates. Being that Plates needs
> >> > to be both client and server compatible, would it be better to create
> >> > a separate flatiron plugin that loads a view file and passes that to
> >> > Plates along with a map and data object?
>
> >> > Here's a simple gist for illustrationhttps://gist.github.com/1792543.
>
> >> --
> >> Joshua Holbrook
> >> Engineer
> >> Nodejitsu Inc.
> >> j...@nodejitsu.com
>
> > --
> > Kevin Rockwood |www.rockwood.me

Rob Koberg

unread,
Feb 15, 2012, 11:50:21 AM2/15/12
to Flatiron
On Feb 13, 6:59 pm, jesusabdullah <josh.holbr...@gmail.com> wrote:
> > I disagree with Josh on this one.
>
> I disagree with me too. I thought about this for a while, and I
> decided that `res.render` was pretty good.

render seems like a pervasive concept in nodejs, so take this fwiw.
Probably too late, but I disagree with you with your disagreement with
yourself. I think of render as what the browser does in a web context.
I think a more semantic way to describe the process and one which
allows for template processing to be decoupled from a response (maybe
you are sending an email or writing a file) would be something like:

templates[Cached]Obj.applyTemplates(dataObj).respond(outStream,
headers)

best,
-Rob

Charlie Robbins

unread,
Feb 15, 2012, 9:33:14 PM2/15/12
to flati...@googlegroups.com
Rob,

I agree with you to an extend. There should definitely be a way to write simple html to a response:

```
  res.html(code, someTemplate.render(data));
```

When you consider how often a user would be writing the above line it would be a "nice to have" to instead write something like:

```
  res.render('someTemplate', data);
```

res.html should definitely exist in union.

--Charlie

jackhq

unread,
Mar 31, 2012, 7:51:22 PM3/31/12
to flati...@googlegroups.com
Hey Everyone,

I don't know if it helps or not, but I have been having some luck with creating a flatiron server side plugin for CoffeeCup Templates.

Using the new `attach` method on flatiron/director, I was able to attach a "bind/render" method to the app.router's object when the plugin is being attached to the application.  

This appears to give the creamer plugin access to the this.res and therefore the this.res.html method inside my plugin method.

So now when I want to render a coffeecup template, I simply do.

app.router.get('/', function() {
  this.bind('index', { data: {} })
})

If you want to see how we are implementing this functionality check out -> https://github.com/twilson63/creamer
(warning: It is in coffee-script)

I would think you could do the same thing with plates or any template engine that you want to use server-side with flatiron.

Flatiron's modularity really shines here, and we have been really enjoying the plug-able aspect of the framework.  

Great Job FlatIronJs team!

-Tom
Reply all
Reply to author
Forward
0 new messages