I just pushed support for Mako within flask. The idea is to replace the current "render_template" function with another one that renders Mako templates instead of Jinja2 ones. The calling convention remains unchanged from the current render_template and all the goodies you get in the Jinja2 context (g, request, etc.) are passed to the context in Mako as well. https://github.com/tzellman/flask-mako/ Please provide feedback! Thanks, Tom P.S. I use Jinja2 as well, but I wanted to have the flexibility of also using Mako with flask.
Hi,
On 2011-03-03 5:37 PM, Tom Zellman wrote:
> Please provide feedback!
Something else I forgot: in extensions please adhere to the Flask code
guide. eg: makoLookup -> mako_lookup. For non approved extensions it
does not matter too much, but if you want the sign for approval make
sure that at the very least the public API follows it :)
Regards,
Armin
Sure, thanks for all the feedback Armin. I agree with your suggestions and will update accordingly. -Tom On Thu, Mar 3, 2011 at 1:27 PM, Armin Ronacher <armin.ronacher@active-4.com>wrote: > Hi, > > On 2011-03-03 5:37 PM, Tom Zellman wrote: > > Please provide feedback! > Something else I forgot: in extensions please adhere to the Flask code > guide. eg: makoLookup -> mako_lookup. For non approved extensions it > does not matter too much, but if you want the sign for approval make > sure that at the very least the public API follows it :) > > > Regards, > Armin >
Hi, On 2011-03-03 5:37 PM, Tom Zellman wrote: > I just pushed support for Mako within flask. The idea is to replace the > current "render_template" function with another one that renders Mako > templates instead of Jinja2 ones. The calling convention remains > unchanged from the current render_template and all the goodies you get > in the Jinja2 context (g, request, etc.) are passed to the context in > Mako as well. Very nice indeed. However two things I would recommend. If you want to support per-request looksup like you currently do, attach the lookup to flask._request_ctx_stack.top instead of g. 'g' should not be used by extensions. If you don't plan on using per request lookups, use the app.extensions dictionary which is the intended place for extensions to put their data in. Regards, Armin
> 'g' should not be used by extensions. This is actually a conclusion I came to myself while working with the Flask-CouchDB extension this last week, which pushes a couchdb database onto the g object. In my case, this ended up causing problems when working with Flask-Script. Armin: I'd be interested to hear your thoughts on why keeping g out of extensions is a best practice. (I'll be at pycon this next week, and I'm expecting to focus some time on extensions.) Matthew Frazier: if you're following this thread, I'd like to talk to you about Flask-CouchDB - specifically alternatives to using the g.couchdb pattern. I'm more than willing to put time into some refactoring if you're amenable. Matt ps - Forgive me for hijacking this thread. On Thu, Mar 3, 2011 at 1:24 PM, Armin Ronacher <armin.ronacher@active-4.com> wrote: > Hi, > > On 2011-03-03 5:37 PM, Tom Zellman wrote: >> I just pushed support for Mako within flask. The idea is to replace the >> current "render_template" function with another one that renders Mako >> templates instead of Jinja2 ones. The calling convention remains >> unchanged from the current render_template and all the goodies you get >> in the Jinja2 context (g, request, etc.) are passed to the context in >> Mako as well. > Very nice indeed. However two things I would recommend. If you want to > support per-request looksup like you currently do, attach the lookup to > flask._request_ctx_stack.top instead of g. 'g' should not be used by > extensions. > > If you don't plan on using per request lookups, use the app.extensions > dictionary which is the intended place for extensions to put their data in. > > > Regards, > Armin >
Outstanding! On Mar 3, 2011, at 11:37 AM, Tom Zellman <tzellman@forthought.net> wrote: > I just pushed support for Mako within flask. The idea is to replace the current "render_template" function with another one that renders Mako templates instead of Jinja2 ones. The calling convention remains unchanged from the current render_template and all the goodies you get in the Jinja2 context (g, request, etc.) are passed to the context in Mako as well. > > https://github.com/tzellman/flask-mako/ > > Please provide feedback! > > Thanks, > Tom > > > P.S. I use Jinja2 as well, but I wanted to have the flexibility of also using Mako with flask.
I wouldn't know the technicalities but why would one choose Mako of Jinja2? Bob
Hi,
On 2011-03-03 6:08 PM, sigzero wrote:
> I wouldn't know the technicalities but why would one choose Mako of Jinja2?
Sometimes it's quite nice to have actual Python code in templates.
Especially if your applications in general are quite small (which is one
of the most common use cases for Flask) it's convenient to move some
logic into templates.
Regards,
Armin
On Mar 3, 2011, at 1:25 PM, Armin Ronacher wrote: > Hi, > > On 2011-03-03 6:08 PM, sigzero wrote: >> I wouldn't know the technicalities but why would one choose Mako of Jinja2? > Sometimes it's quite nice to have actual Python code in templates. > Especially if your applications in general are quite small (which is one > of the most common use cases for Flask) it's convenient to move some > logic into templates. You might use also Mako on a huge project, without any non-trivial Python code in 99% of its templates, as I do. There's several features I think make it invaluable, though I don't know Jinja well enough to say that Jinja doesn't have some equivalent (defs-with-content, calling defs directly from other templates/controllers). Mako's goal is to remove the need for any HTML to ever appear outside of a template, and to allow the construction of "tag libraries" that also are written in the template language, instead of concatenating HTML strings in a .py file somewhere. Python is allowed for views such as those that represent some intricate reformatting of data passed from a controller. Such logic would best be factored into a %def that can then be called upon by page-oriented templates. It's always fascinating what resistance there is to a template language that is open ended in how it may be used. I've never felt that I needed a template language to force me into effective layout and clean coding patterns. That should be the job of your brain. > > > Regards, > Armin
Hi, On 3/5/11 11:01 PM, Michael Bayer wrote: > You might use also Mako on a huge project, without any non-trivial > Python code in 99% of its templates, as I do. There's several > features I think make it invaluable, though I don't know Jinja well > enough to say that Jinja doesn't have some equivalent > (defs-with-content, calling defs directly from other > templates/controllers). I hope you don't take offense in what I wrote. I love Mako and I was using it on the first large project I was ever involved with (plurk.com). The "especially" was just placed there to point out that Mako is especially nice in these situations which it certainly is. > It's always fascinating what resistance there is to a template > language that is open ended in how it may be used. I've never felt > that I needed a template language to force me into effective layout > and clean coding patterns. That should be the job of your brain. I think we're both fighting the same problems with Mako and Jinja2. To quote DHH in slightly modified version: "Jinja/Mako are template languages for consenting adults" :-) Regards, Armin
I second Armin's statement. I also have used Mako on several large projects. It doesn't take much for me to persuade other developers to use it. That being said, I have no resounding resentment for Jinja2 (or any other templating toolkits) - I just usually end up using Mako when all is said and done - it really does seem to do anything you'd imagine needing to do. Using flask, coupled with other best-of-breed libraries/technologies (Mako, SQLAlchemy, etc.) makes development easy, fun, fast and scalable. Thanks goes to everyone involved for their contributions. -Tom On Sat, Mar 5, 2011 at 7:49 PM, Armin Ronacher <armin.ronacher@active-4.com>wrote: > Hi, > > On 3/5/11 11:01 PM, Michael Bayer wrote: > > You might use also Mako on a huge project, without any non-trivial > > Python code in 99% of its templates, as I do. There's several > > features I think make it invaluable, though I don't know Jinja well > > enough to say that Jinja doesn't have some equivalent > > (defs-with-content, calling defs directly from other > > templates/controllers). > I hope you don't take offense in what I wrote. I love Mako and I was > using it on the first large project I was ever involved with > (plurk.com). The "especially" was just placed there to point out that > Mako is especially nice in these situations which it certainly is. > > > It's always fascinating what resistance there is to a template > > language that is open ended in how it may be used. I've never felt > > that I needed a template language to force me into effective layout > > and clean coding patterns. That should be the job of your brain. > I think we're both fighting the same problems with Mako and Jinja2. To > quote DHH in slightly modified version: "Jinja/Mako are template > languages for consenting adults" :-) > > > Regards, > Armin >
All benchmarking aside (I honestly don't have opinions/results here) I think the main difference between the two comes down to the paradigm you prescribe to. Jinja2 maintains a clean separation between templates/UI/presentation and the code that drives it. Mako on the other hand allows for JSP-like abilities, meaning you can embed chunks of Python code into the templates; since Mako compiles templates to Python code, your code gets injected directly in. Besides that, I believe both have very similar feature sets. I've used a variety of templating engines/languages (Django, Mako, Jinja2, to name a few) and resolved that each have their pros/cons and lovers/haters. I try not to discriminate. What do I currently use? Mako. This is primarily due to familiarity and the need to inject code into my templates (for rapid prototyping purposes). -Tom On Thu, Mar 3, 2011 at 12:08 PM, sigzero <sigzero@gmail.com> wrote: > I wouldn't know the technicalities but why would one choose Mako of Jinja2? > > Bob >
Thanks Tom, I am pretty template agnostic myself. -- Bob On Thu, Mar 3, 2011 at 12:29 PM, Tom Zellman <tzellman@forthought.net> wrote: > All benchmarking aside (I honestly don't have opinions/results here) I think > the main difference between the two comes down to the paradigm you prescribe > to. Jinja2 maintains a clean separation between templates/UI/presentation > and the code that drives it. Mako on the other hand allows for JSP-like > abilities, meaning you can embed chunks of Python code into the templates; > since Mako compiles templates to Python code, your code gets injected > directly in. Besides that, I believe both have very similar feature sets. > > I've used a variety of templating engines/languages (Django, Mako, Jinja2, > to name a few) and resolved that each have their pros/cons and > lovers/haters. I try not to discriminate. What do I currently use? Mako. > This is primarily due to familiarity and the need to inject code into my > templates (for rapid prototyping purposes). > > -Tom > > On Thu, Mar 3, 2011 at 12:08 PM, sigzero <sigzero@gmail.com> wrote: >> >> I wouldn't know the technicalities but why would one choose Mako of >> Jinja2? >> >> Bob > >