clean up logging and debug output, minor doc fixes

[catagits/Catalyst-Runtime.git] / lib / Catalyst / Manual / About.pod

diff --git a/lib/Catalyst/Manual/About.pod b/lib/Catalyst/Manual/About.pod
index de2690c..4625eaf 100644 (file)
--- a/lib/Catalyst/Manual/About.pod
+++ b/lib/Catalyst/Manual/About.pod
@@ -1,6 +1,6 @@
 =head1 NAME
 
-Catalyst::Manual::About - Basic explanation of Catalyst
+Catalyst::Manual::About - The philosophy of Catalyst
 
 =head1 DESCRIPTION
 
@@ -94,6 +94,8 @@ It has a very large number of "plugins" that interact with existing Perl
 modules so that you can easily use them from within your
 application. 
 
+=over 4
+
 =item * Interact with a web server? 
 
 Catalyst lets you use a number of different ones, and even comes with a
@@ -130,12 +132,20 @@ Catalyst has detailed logging built-in, which you can configure as
 necessary, and supports the easy creation of new tests--some of which
 are automatically created when you begin writing a new application.
 
+=back
+
 =head3 What B<isn't> Catalyst?
 
 Catalyst is not an out-of-the-box solution that allows you to set up a
 complete working e-commerce application in ten minutes. (There are,
 however, several systems built on top of Catalyst that can get you very
-close to a working app.) 
+close to a working app.)
+
+Catalyst is designed for flexibility and power; to an extent, this comes
+at the expense of simplicity. Programmers have many options for almost
+everything they need to do, which means that any given need can be done
+in many ways, and finding the one that's right for you, and learning the
+right way to do it, can take time. TIMTOWDI works both ways.
 
 Catalyst is not designed for end users, but for working programmers.
 
@@ -171,12 +181,15 @@ A variety of frameworks followed, of which the most widely used is
 probably L<CGI::Application>, which encourages the development of
 modular code, with easy-to-understand control-flow handling, the use of
 plugins and templating systems, and the like. Other systems include
-L<AxKit>, which is designed for use with XML running under mod_perl, and
+L<AxKit>, which is designed for use with XML running under mod_perl;
 L<Maypole>--upon which Catalyst was originally based--designed for the
-easy development of powerful web databases. Is it not the purpose of
-this document to criticize or even briefly evaluate these other
-frameworks; they may be useful for you and if so we encourage you to
-give them a try.
+easy development of powerful web databases; L<Jifty>, which does a great
+deal of automation in helping to set up web sites with many complex
+features; and Ruby on Rails (see L<http://www.rubyonrails.org>), written
+of course in Ruby and among the most popular web development systems. Is
+it not the purpose of this document to criticize or even briefly
+evaluate these other frameworks; they may be useful for you and if so we
+encourage you to give them a try.
 
 =head2 The MVC pattern
 
@@ -200,10 +213,10 @@ well. In most Catalyst applications, each branch of MVC will be made of
 up of several Perl modules that can handle different needs in your
 application.
 
-The purpose of the B<Model> is to access and modify data. Typically
-the Model will interact with a relational database, but it's also
-common to use other data sources, such as the L<Plucene> search
-engine or an LDAP server.
+The purpose of the B<Model> is to access and modify data. Typically the
+Model will interact with a relational database, but it's also common to
+use other data sources, such as the L<Xapian|Catalyst::Model::Xapian>
+search engine or an LDAP server.
 
 The purpose of the B<View> is to present data to the user. Typical Views
 use a templating module to generate HTML code, using L<Template