[z3c_pt] Re: File cache

2008-08-20 Thread Malthe Borch

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

2008-08-20 Thread Hanno Schlichting

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

2008-08-20 Thread Wichert Akkerman

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-08-20 Thread Malthe Borch

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

2008-08-19 Thread Chris McDonough


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
-~--~~~~--~~--~--~---