File cache

[Malthe Borch]

Currently, an option to keep a cache of translated templates is
offered via an environment variable, making application startup
considerably faster. However, it might be more intuitive to follow
Python's behavior of writing a .pyc-file next to the original file.

This could only work for us, if all current "translations" of the
template would be kept in the same file. Hence, instead of using the
canonical symbol ``render`` for the render-method, we'd use
``render_some_signature`` and have them appear one next to the other
in the .pyc file.

The cache would function like so:

1) Try to import the render-method from the file "my_template.pt.pyc"
2) If this fails, compile the template and append it to this .pyc file
(by remarshalling the module contents).

Benefits:

1) Follows common Python behavior
2) Does not require environment variable
3) Plays nice with XIncludes*.

*) As you may know, XIncludes allow including templates by filename,
which may be computed dynamically at render-time.

\malthe

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

[Chris McDonough]

Post by Malthe Borch
Currently, an option to keep a cache of translated templates is
offered via an environment variable, making application startup
considerably faster. However, it might be more intuitive to follow
Python's behavior of writing a .pyc-file next to the original file.
This could only work for us, if all current "translations" of the
template would be kept in the same file. Hence, instead of using the
canonical symbol ``render`` for the render-method, we'd use
``render_some_signature`` and have them appear one next to the other
in the .pyc file.
1) Try to import the render-method from the file "my_template.pt.pyc"
2) If this fails, compile the template and append it to this .pyc file
(by remarshalling the module contents).
1) Follows common Python behavior
2) Does not require environment variable
3) Plays nice with XIncludes*.
*) As you may know, XIncludes allow including templates by filename,
which may be computed dynamically at render-time.

+1 to all of this... with the option of using separate .pym or .pyt
extensions to represent macro vs. direct renderings and keeping a
single "render" in each (which would cut down on compile time
presumably). But either is great by me.

- C


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

[Malthe Borch]

Post by Chris McDonough
+1 to all of this... with the option of using separate .pym or .pyt
extensions to represent macro vs. direct renderings and keeping a
single "render" in each (which would cut down on compile time
presumably). But either is great by me.

It's not even that simple; for every argument signature, a
render-method is generated, too, so we are dealing with both a macro
axis and a argument signature axis.

\malthe

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

[Wichert Akkerman]

Post by Malthe Borch
Currently, an option to keep a cache of translated templates is
offered via an environment variable, making application startup
considerably faster. However, it might be more intuitive to follow
Python's behavior of writing a .pyc-file next to the original file.
This could only work for us, if all current "translations" of the
template would be kept in the same file. Hence, instead of using the
canonical symbol ``render`` for the render-method, we'd use
``render_some_signature`` and have them appear one next to the other
in the .pyc file.
1) Try to import the render-method from the file "my_template.pt.pyc"
2) If this fails, compile the template and append it to this .pyc file
(by remarshalling the module contents).

Kid does something similar I think. It has the nasty side-effect of
requiring an __init__.py in each template directory, but that is
probably just a flaw in its implementation.

The only possible worry I have is that you may not be able to write to
the directory containing the templates. I don't think it is problematic
if that only hurts performance, but it should not break the whole thing.

Wichert.
--
Wichert Akkerman<***@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.


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

[Hanno Schlichting]

Post by Wichert Akkerman

Post by Malthe Borch
Currently, an option to keep a cache of translated templates is
offered via an environment variable, making application startup
considerably faster. However, it might be more intuitive to follow
Python's behavior of writing a .pyc-file next to the original file.
This could only work for us, if all current "translations" of the
template would be kept in the same file. Hence, instead of using the
canonical symbol ``render`` for the render-method, we'd use
``render_some_signature`` and have them appear one next to the other
in the .pyc file.
1) Try to import the render-method from the file "my_template.pt.pyc"
2) If this fails, compile the template and append it to this .pyc file
(by remarshalling the module contents).

Kid does something similar I think. It has the nasty side-effect of
requiring an __init__.py in each template directory, but that is
probably just a flaw in its implementation.
The only possible worry I have is that you may not be able to write to
the directory containing the templates. I don't think it is problematic
if that only hurts performance, but it should not break the whole thing.

It is a very common setup to disallow the Unix user running the
application process to disallow write access to any of the file system
locations. For Python environments that usually means as part of the
installation process of the application all pyc and pyo files (and with
zope.i18n mo files for translations) need to be compiled.

An example of this setup is the buildout based and so called 'unified'
Plone installers.

If we can make sure, there is a way to compile all those cached
templates without the application running, we should be fine. See
precompiler [1] for an example.

If we need the whole application to be running or cannot generate all
cached files upfront, this is not acceptable in my opinion.

The main idea of using environment variables for this kind of
configuration from my point of view is to make those into sys admin
changeable settings.

Cache paths should not be hardcoded by developers, but be available as
sys admin friendly settings. Changing Python code or ZCML is not
something a sys admin should ever need to do. Changing buildout-style
configuration or zope.conf is something sys admins can do.

Hanno

[1] http://pypi.python.org/pypi/plone.recipe.precompiler


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

[Malthe Borch]

Post by Hanno Schlichting
If we can make sure, there is a way to compile all those cached
templates without the application running, we should be fine. See
precompiler [1] for an example.

We can't, because we don't know the argument signatures in advance.

Post by Hanno Schlichting
If we need the whole application to be running or cannot generate all
cached files upfront, this is not acceptable in my opinion.

I think this is jumping to conclusions; people that need this kind of
setup could perhaps live with the delay of recompiling templates on
startup. What are the arguments for disallowing write-access?

Post by Hanno Schlichting
The main idea of using environment variables for this kind of
configuration from my point of view is to make those into sys admin
changeable settings.

I agree on this; if there's a setting needed, it should be using the
system environment.

\malthe

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