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

t0m at dev.catalyst.perl.org t0m at dev.catalyst.perl.org
Sat Dec 13 09:54:59 GMT 2008


Author: t0m
Date: 2008-12-13 09:54:58 +0000 (Sat, 13 Dec 2008)
New Revision: 8854

Added:
   trunk/examples/CatalystAdvent/root/2008/pen/13.pod
Removed:
   trunk/examples/CatalystAdvent/root/2008/pen/xhtml.pod
Log:
Rename

Copied: trunk/examples/CatalystAdvent/root/2008/pen/13.pod (from rev 8853, trunk/examples/CatalystAdvent/root/2008/pen/xhtml.pod)
===================================================================
--- trunk/examples/CatalystAdvent/root/2008/pen/13.pod	                        (rev 0)
+++ trunk/examples/CatalystAdvent/root/2008/pen/13.pod	2008-12-13 09:54:58 UTC (rev 8854)
@@ -0,0 +1,68 @@
+=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.
+
+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.
+
+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.
+
+=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,
+xml validating mode.
+
+=head1 How do I use it?
+
+Add the following code to C<MyApp/View/XHTML.pm>:
+
+    package MyApp::View::XHTML;
+    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.
+
+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.
+
+=head1 That is kinda neat, but your module is like, 5 lines of code..
+
+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>.
+
+=head1 AUTHOR
+
+Tomas Doran (t0m) <bobtfish at bobtfish.net>

Deleted: trunk/examples/CatalystAdvent/root/2008/pen/xhtml.pod
===================================================================
--- trunk/examples/CatalystAdvent/root/2008/pen/xhtml.pod	2008-12-13 09:54:37 UTC (rev 8853)
+++ trunk/examples/CatalystAdvent/root/2008/pen/xhtml.pod	2008-12-13 09:54:58 UTC (rev 8854)
@@ -1,68 +0,0 @@
-=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.
-
-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.
-
-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.
-
-=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,
-xml validating mode.
-
-=head1 How do I use it?
-
-Add the following code to C<MyApp/View/XHTML.pm>:
-
-    package MyApp::View::XHTML;
-    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.
-
-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.
-
-=head1 That is kinda neat, but your module is like, 5 lines of code..
-
-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>.
-
-=head1 AUTHOR
-
-Tomas Doran (t0m) <bobtfish at bobtfish.net>




More information about the Catalyst-commits mailing list