2012-09-05 13 views
6

El sitio webapp2 (http://webapp-improved.appspot.com/api/webapp2_extras/jinja2.html) tiene un tutorial sobre cómo usar webapp2_extras.jinja2, y el código está a continuación.por qué decorar las instancias de Jinja2 con @ webapp2.cached_property

Mi pregunta es: ¿por qué caché la instancia webapp2_extras.jinja2.Jinja2 return by return jinja2.get_jinja2(app=self.app)? Comprobé el código de @webapp2.cached_property y encontré que almacena en caché la instancia Jinja2 en una instancia de BaseHandler, que se destruirá después de la solicitud, ¿por qué molestarse en almacenarla en caché? ¿Me perdí algo aquí?

 
import webapp2 

from webapp2_extras import jinja2 

class BaseHandler(webapp2.RequestHandler): 

    @webapp2.cached_property 
    def jinja2(self): 
     # Returns a Jinja2 renderer cached in the app registry. 
     return jinja2.get_jinja2(app=self.app) 

    def render_response(self, _template, **context): 
     # Renders a template and writes the result to the response. 
     rv = self.jinja2.render_template(_template, **context) 
     self.response.write(rv) 
+0

Es curioso que hayas preguntado eso ... solo eché un vistazo a lo mismo y tampoco entiendo el punto ... Hay un punto en cached_property por supuesto para cosas usadas más de una vez en una solicitud ... – thomasf1

Respuesta

1

Here se puede encontrar la documentación sobre cached_property.

La clase BaseHandler se llamará más tarde con frecuencia. Tengo entendido que para evitar la sobrecarga de llamar al jinja2.get_jinja2(app=self.app) cada vez, dicha referencia se evalúa solo la primera vez y luego se devuelve muchas veces más tarde, es decir, cada vez que se invoca una vista.

Para ver esto en código, vea this ejemplo, donde cada vista se deriva de la misma clase BaseHandler.

Cuestiones relacionadas