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

zarquon at dev.catalyst.perl.org zarquon at dev.catalyst.perl.org
Sat Dec 13 10:40:18 GMT 2008


Author: zarquon
Date: 2008-12-13 10:40:17 +0000 (Sat, 13 Dec 2008)
New Revision: 8855

Modified:
   trunk/examples/CatalystAdvent/root/2008/pen/13.pod
Log:
minor edits, mostly 72 char word wrap

Modified: trunk/examples/CatalystAdvent/root/2008/pen/13.pod
===================================================================
--- trunk/examples/CatalystAdvent/root/2008/pen/13.pod	2008-12-13 09:54:58 UTC (rev 8854)
+++ trunk/examples/CatalystAdvent/root/2008/pen/13.pod	2008-12-13 10:40:17 UTC (rev 8855)
@@ -1,27 +1,29 @@
 =head1 Day 12.  Using XHTML Strict mode during application development.
 
-I have a confession to make, I hate HTML - I hate validating it, 
-I'm very bad at creating well formed markup, and I hate the
-annoying display bugs you find which are due to mis-matched tags.
+I have a confession to make, I hate HTML - I hate validating it, I'm
+very bad at creating well formed markup, and I hate the annoying
+display bugs you find which are due to mis-matched tags.
 
 Therefore the prospect of a way to make my browser refuse to render my
-documents unless they were perfect HTML was very appealing, as it stopped
-me from having to spend time fixing my awful markup at the end of a project,
-as it forces me to do it as I go along.
+documents unless they were perfect HTML was very appealing, as it
+stopped me from having to spend time fixing my awful markup at the end
+of a project, as it forces me to do it as I go along.
 
-In this article I'm going to show you a simple CPAN module, L<Catalyst::View::TT::XHTML>,
-which can be used during development to force your browser to strictly interpret xhtml.
+In this article I'm going to show you a simple CPAN module,
+L<Catalyst::View::TT::XHTML>, which can be used during development to
+force your browser to strictly interpret xhtml.
 
-I'm the paranoid sort, so I don't use this module in production as, whilst I don't 
-I<expect> to generate invalid markup, I'd rather a client browser tried to render the page
-than it failed.
+I'm the paranoid sort, so I don't use this module in production as,
+whilst I don't I<expect> to generate invalid markup, I'd rather a
+client browser tried to render the page than it failed.
 
 =head1 What does this module do?
 
-The module is a very simple subclass of L<Catalyst::View::TT>, which delegates to
-its parent for templating, and then, if the content type of the response is C<'text/html'>,
-and the client's C<Accept> header includes C<application/xhtml+xml>, changes the
-content type to C<pplication/xhtml+xml>, which causes browsers to turn on a strict,
+The module is a very simple subclass of L<Catalyst::View::TT>, which
+delegates to its parent for templating, and then, if the content type
+of the response is C<'text/html'>, and the client's C<Accept> header
+includes C<application/xhtml+xml>, changes the content type to
+C<pplication/xhtml+xml>, which causes browsers to turn on a strict,
 xml validating mode.
 
 =head1 How do I use it?
@@ -32,33 +34,34 @@
     use strict;
     use warnings;
     use base qw/Catalyst::View::XHTML MyApp::View::TT/; 
-    
+
     1;
-    
-Note that adding your current TT view to B<the right hand side> of the inheritance
-causes the configuration from your normal TT view (assumed to be C<MyApp::View::TT> 
-in the example above) to be inherited, but C<Catalyst::View::XHTML> needs to be on 
-the left hand side so that its C<process> method gets called first.
 
-Then, assuming that you are using L<Catalyst::Action::RenderView>, you can just
-set the C<default_view> configuration parameter as appropriate to change
-the response headers output as appropriate.
+Note that adding your current TT view to B<the right hand side> of the
+inheritance causes the configuration from your normal TT view (assumed
+to be C<MyApp::View::TT> in the example above) to be inherited, but
+C<Catalyst::View::XHTML> needs to be on the left hand side so that its
+C<process> method gets called first.
 
-Personally I configure the Xhtml view in C<MyApp.pm>, but I have a commented out entry
-setting it to the original TT view in C<myapp.conf>, which is un-commented
-as my application is deployed.
+Then, assuming that you are using L<Catalyst::Action::RenderView>, you
+can just set the C<default_view> configuration parameter as
+appropriate to change the response headers output as appropriate.
 
-=head1 That is kinda neat, but your module is like, 5 lines of code..
+Personally I configure the Xhtml view in C<MyApp.pm>, but I have a
+commented out entry setting it to the original TT view in
+C<myapp.conf>, which is un-commented as my application is deployed.
 
-Yes, it is. 
+=head1 That is kinda neat, but your module is only, 5 lines of code..
 
-And I had the same 5 lines of code in every application I'd ever written,
-with a conditional on the C<$c->debug> setting, quite often without the 
-relevant C<Accept> header checking. Using this module means you end up 
-with 5 lines in a different view, but there is B<no logic to get wrong>, 
-and it's much easier to be flexible about when you turn the functionality 
-on and off.
+Yes, it is.
 
+And I had the same 5 lines of code in every application I'd ever
+written, with a conditional on the C<$c->debug> setting, quite often
+without the relevant C<Accept> header checking. Using this module
+means you end up with 5 lines in a different view, but there is B<no
+logic to get wrong>, and it's much easier to be flexible about when
+you turn the functionality on and off.
+
 =head1 SEE ALSO
 
 L<Catalyst>, L<Catalyst::View::TT>, L<Catalyst::Action::RenderView>.




More information about the Catalyst-commits mailing list