[z3c_pt] Re: File cache
2008/8/20 Hanno Schlichting <[EMAIL PROTECTED]>: > 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. > 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? > 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 z3c_pt@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/z3c_pt?hl=en -~--~~~~--~~--~--~---
[z3c_pt] Re: File cache
Wichert Akkerman wrote: > Malthe Borch wrote: >> 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). > > 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 z3c_pt@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/z3c_pt?hl=en -~--~~~~--~~--~--~---
[z3c_pt] Re: File cache
Malthe Borch wrote: > 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). > 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<[EMAIL PROTECTED]>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 z3c_pt@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/z3c_pt?hl=en -~--~~~~--~~--~--~---
[z3c_pt] Re: File cache
2008/8/20 Chris McDonough <[EMAIL PROTECTED]>: > +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 z3c_pt@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/z3c_pt?hl=en -~--~~~~--~~--~--~---
[z3c_pt] Re: File cache
On Aug 19, 2008, at 7:06 PM, Malthe Borch wrote: > > 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. +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 z3c_pt@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/z3c_pt?hl=en -~--~~~~--~~--~--~---
