Proposal: add mustache.js as template engine

[Sebastien]

In parallel to XRX, I thought it would be nice to have mustache.js
stored inside of persevere to get HTML output straight from the REST
interface. Any thoughts on this?

[mat taylor]

you can use persevere as a backend to sproutcore, which is a client side Mvc framework that supports moustache templates (1.5 pre 4)

Thanks,
Mat

(on phone so pls xcsuse spelligs)

> --
> You received this message because you are subscribed to the Google Groups "Persevere" group.
> To post to this group, send email to persevere...@googlegroups.com.
> To unsubscribe from this group, send email to persevere-frame...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/persevere-framework?hl=en.
>

[Dean Landolt]

On Wed, Mar 9, 2011 at 11:26 AM, mat taylor <mat.t...@gmail.com> wrote:

you can use persevere as a backend to sproutcore, which is a client side Mvc framework that supports moustache templates (1.5 pre 4)

IIRC Sproutcore uses handlebars, which they created, but it's based on mustache.\

 

On Mar 9, 2011, at 6:58 AM, Sebastien <wsh...@gmail.com> wrote:

> In parallel to XRX, I thought it would be nice to have mustache.js
> stored inside of persevere to get HTML output straight from the REST
> interface. Any thoughts on this?

It's absolutely possible to create your own html representations of objects. You can override the current html handler and have it spit out whatever you want, globally or on a per-model basis. As part of this you could certainly wire in mustache, or any template engine available as a CommonJS module. There are quite a few ways to do this -- if you spell out what you're trying to do I'll try and give you more information. Even if you use the html template engine that's there I think you can incorporate mustache as the renderer -- Dustin, correct me if I'm wrong...

Dean

[Wouter Hager]

Cheers, but not my cup of tea. I'm too fond of dojo plus I see an advantage to using mustache serverside. Perhaps I should consider node.js? Anyone has any experience in that field yet?

2011/3/9 mat taylor <mat.t...@gmail.com>

--

W.S. Hager
Lagua Web Solutions
http://lagua.nl

[Wouter Hager]

Ah very good. I will have a look at CommonJS and the templater. For now I just wish to have very plain JSON key/value lists to render as HTML to load with Ajax, for example when I consider it faster to render them serverside instead of clientside. I'm trying to work towards some sort of standard way to reducing unnecessary parsing on the client. IMHO the JS toolkits can take quite some time putting things into place.

Thanks!

2011/3/9 Dean Landolt <de...@deanlandolt.com>

--
You received this message because you are subscribed to the Google Groups "Persevere" group.
To post to this group, send email to persevere...@googlegroups.com.
To unsubscribe from this group, send email to persevere-frame...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/persevere-framework?hl=en.

[Vladimir Dronnikov]

With recent success of commonjs patterns server-side interface
generation is quickly becoming outdated, imho. Client-side generation
scales better, requires less data (in general) to be transmitted,
allows for offline apps and moremoremore.

Plus, in pintura, for "Accept: text/html" request an HTML serializer
is required which is (was, at least) not so easy configurable to use
various templating engines. Plus plus, pintura is positioned to be
"more a library than a framework", so the best imho to keep pintura
thin JSON server.

Best regards,
--Vladimir

[Dean Landolt]

On Wed, Mar 9, 2011 at 12:00 PM, Vladimir Dronnikov <dron...@gmail.com> wrote:

With recent success of commonjs patterns server-side interface
generation is quickly becoming outdated, imho. Client-side generation
scales better, requires less data (in general) to be transmitted,
allows for offline apps and moremoremore.

 

I don't think you'll get any argument that client side generation is better in a lot of ways. But that's no reason to completely forgo server side generation where it's necessary, and sometimes it's just easier or makes more sense to xhr for html.

 

Plus, in pintura, for "Accept: text/html" request an HTML serializer
is required which is (was, at least) not so easy configurable to use
various templating engines. Plus plus, pintura is positioned to be
"more a library than a framework", so the best imho to keep pintura
thin JSON server.

As more a library than a framework it's unopinionated about what templating engine you should use and how it should be configured. It's not all that complex to set one up, and configuring it to use any templating engine you want is the easy part -- in my experience the more complex part is handling various kinds of query results elegantly.

[W.S. Hager]

In addition:
Accept:text/html to serialize would actually be what I'm looking for. I have already put most of the weight in the browser, but I would very much like to see benchmarks of clientside vs serverside serialization.

2011/3/9 Dean Landolt <de...@deanlandolt.com>

--

You received this message because you are subscribed to the Google Groups "Persevere" group.
To post to this group, send email to persevere...@googlegroups.com.
To unsubscribe from this group, send email to persevere-frame...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/persevere-framework?hl=en.

[Dean Landolt]

On Wed, Mar 9, 2011 at 12:45 PM, W.S. Hager <wsh...@gmail.com> wrote:

In addition:
Accept:text/html to serialize would actually be what I'm looking for.

Okay, well then just have a look at the media handlers in pintura [1] and do the same thing in your application with a text/html handler.

 

I have already put most of the weight in the browser, but I would very much like to see benchmarks of clientside vs serverside serialization.

It's not something you can really benchmark -- at least, I cant think of a good way. Most likely, in isolation at least, applying any given template on the server will be faster than applying it in the client, but significantly less scalable -- one server applying 1000 templates will be a lot slower than 1000 clients applying 1 template. That's what Vlad meant by more scalable, but I wouldn't concern myself too much with it.

[1] https://github.com/kriszyp/pintura/tree/master/lib/media

[Dean Landolt]

I should also add -- you could probably accomplish what you're looking for with the current html serialization, but I don't know enough about it to be able to tell you how. But it wouldn't hurt you to poke around it and see, even hacking out the renderer and replacing it with a mustache lib.

[Vladimir Dronnikov]

>
> I don't think you'll get any argument that client side generation is better
> in a lot of ways.

I don't need any since I guarded the sentense with "imho".

> But that's no reason to completely forgo server side
> generation where it's necessary, and sometimes it's just easier or makes
> more sense to xhr for html.

Sure

>>
>> Plus, in pintura, for "Accept: text/html" request an HTML serializer
>> is required which is (was, at least) not so easy configurable to use
>> various templating engines. Plus plus, pintura is positioned to be
>> "more a library than a framework", so the best imho to keep pintura
>> thin JSON server.
>
>
> As more a library than a framework it's unopinionated about what templating
> engine you should use and how it should be configured. It's not all that
> complex to set one up, and configuring it to use any templating engine you
> want is the easy part -- in my experience the more complex part is handling
> various kinds of query results elegantly.

True. However, IIRC, one can't just render {foo: 'bar'} (arbitrary
object) by means of __provided pristine__ JSGI stack -- this foo
object must come from a Store instance, to make things consistent.
This was the topic of a hot discussion last summer, but i admit things
might have changed since. Agree, that such way of rendering is not
very friendly for those who is accustomed to be able to render
anything by simply call a routine.

[Vladimir Dronnikov]

>>> Accept:text/html to serialize would actually be what I'm looking for.

Pure imho:

Pintura (Persevere 2.0) is brilliant at 2 points -- RQL and intrinsic
Object Capability -- and thus excellent choice for robustly serving
_data_. The remainder -- HTML rendering included -- is what other
"vanilla" pieces of software do may be better (at least easier to use
OOTB). These two points are what makes pintura a huge step forward
other frameworks which are mostly headless "renderers" and "routers",
no more.

[W.S. Hager]

Sorry about that benchmark remark...

Couldn't it be "just" serialization? What if you would want xml or rdf or what have you (you will need those at some point)? And let the transformation do whatever it does? Moreover, I consider anything that runs in a webapp container pretty well-suited to serve html.

2011/3/9 Vladimir Dronnikov <dron...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Persevere" group.
To post to this group, send email to persevere...@googlegroups.com.
To unsubscribe from this group, send email to persevere-frame...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/persevere-framework?hl=en.

[Vladimir Dronnikov]

> Couldn't it be "just" serialization?

The point is _what_ to serialize. As Dean said, to couple
serialization stuff per se is easy.
Can you elaborate on what you want to get in response to what? Say, I
want to get a prefilled HTML form to edit an item in my Foo Store? Or,
I want to render the current user profile? As I said -- these two are
_very_ different...

[W.S. Hager]

Hi Vladimir,

Thanks for your input. I see your point. I will get back on this.

2011/3/9 Vladimir Dronnikov <dron...@gmail.com>