2012-09-05 12 views
6

Witryna webapp2 (http://webapp-improved.appspot.com/api/webapp2_extras/jinja2.html) zawiera samouczek dotyczący korzystania z webapp2_extras.jinja2, a kod znajduje się poniżej.dlaczego dekorować instancje Jinja2 za pomocą @ webapp2.cached_property

Moje pytanie brzmi: dlaczego pamięć podręczna powrotu instancji webapp2_extras.jinja2.Jinja2 przez return jinja2.get_jinja2(app=self.app)? Sprawdziłem kod @webapp2.cached_property i odkryłem, że buforuje instancję Jinja2 w instancji BaseHandler, która zostanie zniszczona po żądaniu, więc po co to robić? Czy tęskniłem za czymś tutaj?

 
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

Zabawne, że zapytałeś, że ... po prostu spojrzał na to samo i nie może zrozumieć, czy ... Istnieje punkt cached_property oczywiście dla rzeczy używanych więcej niż raz w jednym wniosku ... – thomasf1

Odpowiedz

1

Here można znaleźć dokumentację o cached_property.

Klasa BaseHandler będzie później często wywoływana. Rozumiem, że aby uniknąć narzutów związanych z wywoływaniem za każdym razem, odniesienie to jest oceniane tylko za pierwszym razem, a następnie zwracane wiele razy później, tj. Za każdym razem, gdy wywoływany jest widok.

Aby zobaczyć, co dzieje się w kodzie, zobacz przykład: this, gdzie każdy widok pochodzi z tej samej klasy BaseHandler.

Powiązane problemy