incubator-bloodhound-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Apache Bloodhound" <bloodhound-...@incubator.apache.org>
Subject Re: [Apache Bloodhound] #330: Lazy evaluation of req.chrome
Date Thu, 24 Jan 2013 23:01:44 GMT
#330: Lazy evaluation of req.chrome
--------------------------+--------------------
  Reporter:  peter        |      Owner:  nobody
      Type:  enhancement  |     Status:  closed
  Priority:  minor        |  Milestone:
 Component:  dashboard    |    Version:
Resolution:  fixed        |   Keywords:
--------------------------+--------------------

Comment (by olemis):

 Replying to [comment:10 rjollos]:
 > Replying to [comment:9 olemis]:
 > > > I invoked the !TracError by replacing `data` with `None` in
 `trac.wiki.web_ui._render_view`. I wanted to force an exception when the
 template was rendered.
 > >
 > > That's not the kind of errors we are tracking in this ticket . Indeed
 , its goal is not to instantiate `req.chrome` **IF** there is no template
 processing involved .
 >
 > Your comment was ''Otherwise error pages seem not to get the proper
 styling info ... First we should check whether error pages will be broken
 after r1437967.'', therefore I thought that as a side issue we needed to
 look at whether !TracError pages were rendering correctly.

 Yes , you are right . There was a lot of implicit knowledge in my previous
 statement .

 Let's focus on `trac.web.chrome.Chrome.render_template` method . In there
 `_post_process_request` is called in three places .

   1. after request handler contributes any data to expand a given
      template (invoked with args `template, data, content_type` )
   2. when request handler sends data on its own
      (invoked with `None, None, None` )
   3. when an error is detected (invoked with `None, None, None`
      inside `except` block)

 `req.chrome` needs to be instantiated only in case **1** and **3** and
 that's what this ticket is for . The way it is now , it's only taking into
 account **1** . Basic theme style will be there , but further items added
 while post processing the request will not . That was what I meant .
 ;)

 > This seemed relevant since I had noticed recently that they were not
 rendering correctly.
 >

 maybe yes , maybe not ...

 > > AFAICT if there's an error rendering a Genshi template then you'll get
 a plain-text error message.
 >
 > My test case results in a genshi template rendering error, and in that
 case my screen capture shows that the !TracError page is rendered.

 In that case `req.chrome` should be instantiated along the way .

 > However, in other cases I only see a plain-text error message. I don't
 understand what conditions lead to the different views.

 Yes , I guess that depends on the exact point where the error happens e.g.
 while expanding variables , you'll get the error page (... but you'll get
 a plain text error if ''Genshi'' template cannot be found ? ) . It's a bit
 non-deterministic ; or at least it is beyond my current understanding .

-- 
Ticket URL: <https://issues.apache.org/bloodhound/ticket/330#comment:11>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker

Mime
View raw message