[Catalyst-commits] r8860 - in
trunk/examples/CatalystAdvent/root/2008: . pen
t0m at dev.catalyst.perl.org
t0m at dev.catalyst.perl.org
Sat Dec 13 11:13:06 GMT 2008
Author: t0m
Date: 2008-12-13 11:13:06 +0000 (Sat, 13 Dec 2008)
New Revision: 8860
Added:
trunk/examples/CatalystAdvent/root/2008/13.pod
Removed:
trunk/examples/CatalystAdvent/root/2008/pen/13.pod
Modified:
trunk/examples/CatalystAdvent/root/2008/pen/cat5.80.pod
Log:
And make live
Copied: trunk/examples/CatalystAdvent/root/2008/13.pod (from rev 8859, trunk/examples/CatalystAdvent/root/2008/pen/13.pod)
===================================================================
--- trunk/examples/CatalystAdvent/root/2008/13.pod (rev 0)
+++ trunk/examples/CatalystAdvent/root/2008/13.pod 2008-12-13 11:13:06 UTC (rev 8860)
@@ -0,0 +1,79 @@
+=head1 Day 13. Using XHTML Strict mode during application development.
+
+I have a confession to make, I hate HTML - I'm very bad at creating
+well formed markup, I hate validating it, and I really hate the
+annoying display bugs you find which are due to mis-matched tags.
+
+Therefore a way to make my browser refuse to render my documents unless
+they were perfect HTML was very appealing, as it stops
+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 when not in
+development.
+
+=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>, performs C<RFC2616> Content
+Negotiation with a strong preference for the C<application/xhtml+xml>
+Content Type. If the client's C<Accept> header supports this, it
+changes the content type to C<application/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 View.
+
+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 only, 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.
+
+Shortly after uploading this awful hack to CPAN, lots of people
+pointed out how much it sucked, sent me failing tests, and made
+suggestions, so the implementation is now much better than what
+I was using previously.
+
+=head1 SEE ALSO
+
+L<Catalyst>, L<Catalyst::View::TT>, L<Catalyst::Action::RenderView>,
+L<http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html>,
+L<http://www.w3.org/TR/xhtml-media-types/>.
+
+=head1 AUTHOR
+
+Tomas Doran (t0m) <bobtfish at bobtfish.net>
+>
+
Deleted: trunk/examples/CatalystAdvent/root/2008/pen/13.pod
===================================================================
--- trunk/examples/CatalystAdvent/root/2008/pen/13.pod 2008-12-13 11:12:10 UTC (rev 8859)
+++ trunk/examples/CatalystAdvent/root/2008/pen/13.pod 2008-12-13 11:13:06 UTC (rev 8860)
@@ -1,79 +0,0 @@
-=head1 Day 13. Using XHTML Strict mode during application development.
-
-I have a confession to make, I hate HTML - I'm very bad at creating
-well formed markup, I hate validating it, and I really hate the
-annoying display bugs you find which are due to mis-matched tags.
-
-Therefore a way to make my browser refuse to render my documents unless
-they were perfect HTML was very appealing, as it stops
-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 when not in
-development.
-
-=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>, performs C<RFC2616> Content
-Negotiation with a strong preference for the C<application/xhtml+xml>
-Content Type. If the client's C<Accept> header supports this, it
-changes the content type to C<application/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 View.
-
-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 only, 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.
-
-Shortly after uploading this awful hack to CPAN, lots of people
-pointed out how much it sucked, sent me failing tests, and made
-suggestions, so the implementation is now much better than what
-I was using previously.
-
-=head1 SEE ALSO
-
-L<Catalyst>, L<Catalyst::View::TT>, L<Catalyst::Action::RenderView>,
-L<http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html>,
-L<http://www.w3.org/TR/xhtml-media-types/>.
-
-=head1 AUTHOR
-
-Tomas Doran (t0m) <bobtfish at bobtfish.net>
->
-
Modified: trunk/examples/CatalystAdvent/root/2008/pen/cat5.80.pod
===================================================================
--- trunk/examples/CatalystAdvent/root/2008/pen/cat5.80.pod 2008-12-13 11:12:10 UTC (rev 8859)
+++ trunk/examples/CatalystAdvent/root/2008/pen/cat5.80.pod 2008-12-13 11:13:06 UTC (rev 8860)
@@ -75,12 +75,6 @@
=item *
-Automatic profiling
-
-FIXME
-
-=item *
-
Component introspection for code generation in devel.
FIXME
More information about the Catalyst-commits
mailing list