[Catalyst-commits] r8898 - trunk/examples/CatalystAdvent/root/2008/pen

[jayk at dev.catalyst.perl.org]

Author: jayk
Date: 2008-12-17 07:37:08 +0000 (Wed, 17 Dec 2008)
New Revision: 8898

Modified:
   trunk/examples/CatalystAdvent/root/2008/pen/esi.pod
Log:
a couple of minor wording changes in the esi article

Modified: trunk/examples/CatalystAdvent/root/2008/pen/esi.pod
===================================================================
--- trunk/examples/CatalystAdvent/root/2008/pen/esi.pod	2008-12-17 07:28:23 UTC (rev 8897)
+++ trunk/examples/CatalystAdvent/root/2008/pen/esi.pod	2008-12-17 07:37:08 UTC (rev 8898)
@@ -240,9 +240,9 @@
 (or the designer) decides that they want to show the most recent posts on
 another page, say in a little callout-box on the static 'about us' page? Well
 now we have a problem. If your static page isn't handled by Catalyst, you
-can't call the recent article routine. Let's assume that your static pages
-I<are> handled by Catalyst. The action might look something like this (error
-checking excluded for simplicity):
+can't call the recent article routine at all. Let's assume, though, that your
+static pages I<are> handled by Catalyst. The action might look something like
+this (error checking excluded for simplicity):
 
  package BlogSite::Controller::Page;
  
@@ -274,9 +274,9 @@
 
 Have you spotted the problem yet? There are actually two. The first is that
 now your database is hit for every static page view, whether it displays the
-recent block or not. The second is that now your static pages are forced to
-cache at the very small 5 minute interval that the recent article block
-requires.
+recent articles block or not. The second is that now your static pages are
+forced to cache at the very small 5 minute interval that the recent article
+block requires.
 
 The particularly experienced among you are thinking of ways to avoid putting
 the recentarticles call into every page. Calling the routine from within the
@@ -396,10 +396,10 @@
  }
 
 This tells Varnish that if the content-type of the data being received from
-the web server is html, we should process it with ESI. We need to put this
-test in place because we do not want to run esi processing on binary files.
-You can expand the content-type match if you want to use ESI in other files,
-like CSS or JSON responses.
+the web server is some form of html, we should process it with ESI. We need to
+put this test in place because we do not want to run esi processing on binary
+files. You can expand the content-type match if you want to use ESI in other
+files, like CSS or JSON responses.
 
 And that's it. Enable the above in your Varnish config and you get ESI
 instantly.