Store Mako templates in database

[Junya HAYASHI]

Hi,

I'm trying to store Mako templates in database and render them, but can't do
it in smart way.
Would you please give me advises ?

My apploach is following.

# my controller
class PageController(object):
def show(self, id):
page = PageModel.query.get_by(id=id)
if not page:
abort(404)

from pylons import buffet
from mako.template import Template
mako_config = buffet.engines.get('mako')
if not mako_config:
raise Exception("mako engine not found.")
namespace = {}
namespace = buffet._update_names(namespace)

template = Template(page.content, lookup=mako_config['engine'].lookup)
return template.render_unicode(**namespace).encode('utf8', 'replace')

# Actually, I want to write like this,
# but lookup options would not be passed to template with this approach.
class PageController(object):
def show(self, id):
page = PageModel.query.get_by(id=id)
if not page:
abort(404)

from pylons import buffet
- from mako.template import Template
mako_config = buffet.engines.get('mako')
if not mako_config:
raise Exception("mako engine not found.")
namespace = {}
namespace = buffet._update_names(namespace)

- template = Template(page.content, lookup=mako_config['engine'].lookup)
+ template = mako_config['engine'].load_template(
+ templatename=None, template_string=page.template.content)
return template.render_unicode(**namespace).encode('utf8', 'replace')

My questions are following.

1. Are there any good way to render templates, stored in database ?
2. I'm thinking of replacing mako engine "mako.ext.turbogears:TGPlugin" to
another.
To do so, "python.templating.engines" should be overwritten.
Are there any good way to overwrite entry points ?
3. I want to avoid using private method 'buffet._update_names',
are there any another recommended way ?

Thanks in advance.

----
Junya HAYASHI

[Mike Orr]

There's no reason you have to use Buffet. Its purpose is to hide the
differences between template engines for simple cases. But if you
want to use extra features of a particular engine, you can just use
the engine in its native manner, or write your own render function.
The latter would be more convenient. You can define render() in
environment.py to get the options, and import it into your
controllers, or stick it into pylons.g. Since you're getting the
templates from a database you won't need TemplateLookup except for
inheritance and includes. You can create your own TemplateLookup with
whatever options you want, or look through pylons.templating and
pylons.wsgiapp and imitate how it discovers options for Mako.

The next version of Buffet and its plugins will change significantly,
so I wouldn't spend much time looking closely at the code or calling
internal methods, because those will all change.

--
Mike Orr <slugg...@gmail.com>

[junya]

Hi,

Thanks Mike. I took things too seriously, and missed the meaning of
Buffet.
I'll define custom render() without Buffet.

I was thinking of providing same configuration to db stored templates
as one of in file system.
Inheritances and includes are also required.
But configure options are avairable in pylons.config or environ, so
I'll use them.

Thanks a lot !

----
Junya Hayashi

> There's no reason you have to use Buffet. Its purpose is to hide the
> differences between template engines for simple cases. But if you
> want to use extra features of a particular engine, you can just use
> the engine in its native manner, or write your own render function.
> The latter would be more convenient. You can define render() in
> environment.py to get the options, and import it into your
> controllers, or stick it into pylons.g. Since you're getting the
> templates from a database you won't need TemplateLookup except for
> inheritance and includes. You can create your own TemplateLookup with
> whatever options you want, or look through pylons.templating and
> pylons.wsgiapp and imitate how it discovers options for Mako.
>
> The next version of Buffet and its plugins will change significantly,
> so I wouldn't spend much time looking closely at the code or calling
> internal methods, because those will all change.
>
> --

> Mike Orr <sluggos...@gmail.com>

[junya]

Finally, I made render_string() as following,
http://d.hatena.ne.jp/pyxis-dev/20080219

----
Junya Hayashi