First!
24 views
Skip to first unread message
Matt Todd
Dec 12, 2009, 7:30:49 PM12/12/09
to Guardians of the Temple
Hah, first!
Just now reading http://judofyr.net/posts/temple.html
This is a great quote:
"[T]here isn’t one definite way to go from a Mustache-string to the
core-abstraction, but there is only one way to go from a Mustache-
string to the Mustache-abstraction."
Just now reading http://judofyr.net/posts/temple.html
This is a great quote:
"[T]here isn’t one definite way to go from a Mustache-string to the
core-abstraction, but there is only one way to go from a Mustache-
string to the Mustache-abstraction."
Magnus Holm
Dec 13, 2009, 7:59:07 AM12/13/09
to guardians-o...@googlegroups.com
Heh, it felt a little lonely writing on a mailing list without
members, so I just went to bed instead.
Oh, and btw, diagrammr.com works pretty well to show all these abstractions:
http://img.skitch.com/20091213-bkmqmitg5ij2pe4p2m4y6prk3q.png
//Magnus Holm
members, so I just went to bed instead.
Oh, and btw, diagrammr.com works pretty well to show all these abstractions:
http://img.skitch.com/20091213-bkmqmitg5ij2pe4p2m4y6prk3q.png
//Magnus Holm
Matt Todd
Dec 13, 2009, 4:16:38 PM12/13/09
to guardians-o...@googlegroups.com
That's a great visualization. I hadn't seen that tool before, but we've used http://websequencediagrams.com/ for sequence diagrams before.
You know, I felt like taking a stab at a templating language after reading about Temple. I might give it a whirl, but I think as a whole Temple will influence people to actively participate in the templating world, contributing expertise and opinion.
Matt
--
Matt Todd
Highgroove Studios
www.highgroove.com
cell: 404-314-2612
blog: maraby.org
Scout - Web Monitoring and Reporting Software
www.scoutapp.com
Matt Todd
Highgroove Studios
www.highgroove.com
cell: 404-314-2612
blog: maraby.org
Scout - Web Monitoring and Reporting Software
www.scoutapp.com
Gimi
Dec 13, 2009, 9:39:14 PM12/13/09
to Guardians of the Temple
A great idea! It sounds the rack of template engines. I'm very curious
what will happen if all template engines are written on Temple?
> Just now readinghttp://judofyr.net/posts/temple.html
what will happen if all template engines are written on Temple?
> Just now readinghttp://judofyr.net/posts/temple.html
Magnus Holm
Dec 14, 2009, 5:59:32 AM12/14/09
to guardians-o...@googlegroups.com
First of all, most of them will be a lot faster, since Temple
encourages compilation (it is of course still possible to turn
everything into render-time method calls).
Secondly, it would be far easier to understand how different engines
works. Boring parsers are separated from code generation. If you want
to improve code generation, you can do that without even looking at
the parser. If you want to make the parser faster, you could for
instance rewrite it in C without thinking about the code generation.
It's easier to rewrite two or three small chunks, than one big. Easier
to test too.
Thirdly, it would be possible to share code, abstractions and
optimizations between engines. More sharing, less work.
--
Matt: Cool, I'd love to hear more about every template engine out
there (inside your minds too). Feel free to post on the mailing list,
and I'll check it out. If you even write something like "because of X
I think it would be difficult to compile it", I'll probably take it as
a challenge. After Tobias' comment
(http://judofyr.net/posts/temple.html#comment-25654446 ) I started
writing the Liquid backend, but I got kinda stuck playing with Ragel
as a tokenizer.
//Magnus Holm
encourages compilation (it is of course still possible to turn
everything into render-time method calls).
Secondly, it would be far easier to understand how different engines
works. Boring parsers are separated from code generation. If you want
to improve code generation, you can do that without even looking at
the parser. If you want to make the parser faster, you could for
instance rewrite it in C without thinking about the code generation.
It's easier to rewrite two or three small chunks, than one big. Easier
to test too.
Thirdly, it would be possible to share code, abstractions and
optimizations between engines. More sharing, less work.
--
Matt: Cool, I'd love to hear more about every template engine out
there (inside your minds too). Feel free to post on the mailing list,
and I'll check it out. If you even write something like "because of X
I think it would be difficult to compile it", I'll probably take it as
a challenge. After Tobias' comment
(http://judofyr.net/posts/temple.html#comment-25654446 ) I started
writing the Liquid backend, but I got kinda stuck playing with Ragel
as a tokenizer.
//Magnus Holm
Dan Kubb (dkubb)
Dec 14, 2009, 10:37:54 PM12/14/09
to Guardians of the Temple
One thing I hope to see more of is a templating engine that can I can
tell to send the output to the socket rather than buffering everything
in memory. Ideally I would like to send everything up to <body>, and
then flush the socket. This would allow the browser to get started
downloading css + images referenced <head> while the rest of the
template being rendered. Is this something that will be possible?
--
Dan
(dkubb)
tell to send the output to the socket rather than buffering everything
in memory. Ideally I would like to send everything up to <body>, and
then flush the socket. This would allow the browser to get started
downloading css + images referenced <head> while the rest of the
template being rendered. Is this something that will be possible?
--
Dan
(dkubb)
Magnus Holm
Dec 15, 2009, 2:40:03 AM12/15/09
to guardians-o...@googlegroups.com
I've been thinking of the exactly same thing. My idea was to compile it like:
yield "Static"
yield dynamic.to_s
and then define the compiled template somewhere as #each. Then pass
that object to Rack as the body, and the server will stream it. Now I
realise that you could also just have the socket in a ivar and call
that... Probably faster, but not Rack-compatible (if you care about
such stuff).
There is however one big drawback with this. If something goes wrong
while you're streaming it, it's nearly impossible to handle it. What
should you do if an exception happens? Somehow you got to gracefully
tell the client/user that something failed. You've already sent the
headers, so you can't redirect. It might work if you have the exact
same layout on both the page and the page that handles errors, but
you'll still serve an error-page as 200.
It shouldn't be very hard to write a Core-filter which handles it, but
I'm not sure if it's worth it. Unfortunately :-(
//Magnus Holm
yield "Static"
yield dynamic.to_s
and then define the compiled template somewhere as #each. Then pass
that object to Rack as the body, and the server will stream it. Now I
realise that you could also just have the socket in a ivar and call
that... Probably faster, but not Rack-compatible (if you care about
such stuff).
There is however one big drawback with this. If something goes wrong
while you're streaming it, it's nearly impossible to handle it. What
should you do if an exception happens? Somehow you got to gracefully
tell the client/user that something failed. You've already sent the
headers, so you can't redirect. It might work if you have the exact
same layout on both the page and the page that handles errors, but
you'll still serve an error-page as 200.
It shouldn't be very hard to write a Core-filter which handles it, but
I'm not sure if it's worth it. Unfortunately :-(
//Magnus Holm
Reply all
Reply to author
Forward
0 new messages