X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FCatalyst%2FManual%2FAbout.pod;fp=lib%2FCatalyst%2FManual%2FAbout.pod;h=0000000000000000000000000000000000000000;hb=2c06eadbcdb872417d0106893ad851324d3b3bd1;hp=4625eafe50a03657863d28766b25adc51245a5b2;hpb=ccbc27bfb76a4c41cd4df9ed6a53928ffbb9eae3;p=catagits%2FCatalyst-Runtime.git diff --git a/lib/Catalyst/Manual/About.pod b/lib/Catalyst/Manual/About.pod deleted file mode 100644 index 4625eaf..0000000 --- a/lib/Catalyst/Manual/About.pod +++ /dev/null @@ -1,317 +0,0 @@ -=head1 NAME - -Catalyst::Manual::About - The philosophy of Catalyst - -=head1 DESCRIPTION - -This document is a basic introduction to the I of Catalyst. It does -not teach you how to write Catalyst applications; for an introduction to -that please see L. Rather, it explains the -basics of what Catalyst is typically used for, and why you might want -to use Catalyst to build your applications. - -=head2 What is Catalyst? The short summary - -Catalyst is a web application framework. This means that you use it to -help build applications that run on the web, or that run using protocols -used for the web. Catalyst is designed to make it easy to manage the -various tasks you need to do to run an application on the web, either by -doing them itself, or by letting you "plug in" existing Perl modules -that do what you need. There are a number of things you typically do -with a web application. For example: - -=over 4 - -=item * Interact with a web server - -If you're on the web, you're relying on a web server, a program that -sends files over the web. There are a number of these, and your -application has to do the right thing to make sure that your program -works with the web server you're using. If you change your web server, -you don't want to have to rewrite your entire application to work with -the new one. - -=item * Do something based on a URI - -It's typical for web applications to use URIs as a main way for users to -interact with the rest of the application; various elements of the URI -will indicate what the application needs to do. Thus, -C will -add a person named "John" whose title is "President" to your database, -and C will go to a "display" -of item 23 in your catalog, and -C will display the status of -order 7582, and C will -display a form to add a comment to page 8. Your application needs to -have a regular way of processing these URIs so it knows what to do -when such a request comes in. - -=item * Interact with a data store - -You probably use a database to keep track of your information. Your -application needs to interact with your database, so you can create, -edit, and retrieve your data. - -=item * Handle forms - -When a user submits a form, you receive it, process it to make sure it's -been filled in properly, and then do something based on the -result--submit an order, update a record, send e-mail, or return to the -form if there's an error. - -=item * Display results - -If you have an application running on the web, people need to see -things. You usually want your application displayed on a web browser, in -which case you will probably be using a template system to help generate -HTML code. But you might need other kinds of display, such as PDF files, -or other forms of output, such as RSS feeds or e-mail. - -=item * Manage users - -You might need the concept of a "user", someone who's allowed to use -your system, and is allowed to do certain things only. Perhaps normal -users can only view or modify their own information; administrative -users can view or modify anything; normal users can only order items for -their own account; normal users can view things but not modify them; -order-processing users can send records to a different part of the -system; and so forth. You need a way of ensuring that people are who -they say they are, and that people only do the things they're allowed to -do. - -=item * Develop the application itself - -When you're writing or modifying the application, you want to have -access to detailed logs of what it is doing. You want to be able to -write tests to ensure that it does what it's supposed to, and that new -changes don't break the existing code. - -=back - -Catalyst makes it easy to do all of these tasks, and many more. It is -extremely flexible in terms of what it allows you to do, and very fast. -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 -built-in server for testing or local deployment. - -=item * Do something based on a URI? - -Catalyst has extremely flexible systems for figuring out what to do -based on a URI. - -=item * Interact with a data store? - -Catalyst has many plugins for different databases and database -frameworks, and for other non-database storage systems. - -=item * Handle forms? - -Catalyst has plugins available for several form creation and validation -systems that make it easy for the programmer to manage. - -=item * Display results? - -Catalyst has plugins available for a number of template modules and -other output packages. - -=item * Manage users? - -Catalyst has plugins that handle sessions, authentication, and -authorization, in any way you need. - -=item * Developing the application? - -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 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.) - -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. - -=head2 Web programming: The Olden Days - -Perl has long been favored for web applications. There are a wide -variety of ways to use Perl on the web, and things have changed over -time. It's possible to handle everything with very raw Perl code: - - print "Content-type: text/html\n\n

Hello - World!

"; - -for example, or - - my @query_elements = split(/&/, $ENV{'QUERY_STRING'}); - foreach my $element (@query_elements) { - my ($name, $value) = split(/=/, $element); - # do something with your parameters, or kill yourself - # in frustration for having to program like this - } - -Much better than this is to use Lincoln Stein's great L module, -which smoothly handles a wide variety of common tasks--parameter -parsing, generating form elements from Perl data structures, printing -http headers, escaping text, and very many more, all with your choice of -functional or object-oriented style. While L was revolutionary and -is still widely used, it has various drawbacks that make it unsuitable -for larger applications: it is slow; your code with it generally -combines application logic and display code; and it makes it very -difficult to handle larger applications with complicated control flow. - -A variety of frameworks followed, of which the most widely used is -probably L, 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, which is designed for use with XML running under mod_perl; -L--upon which Catalyst was originally based--designed for the -easy development of powerful web databases; L, which does a great -deal of automation in helping to set up web sites with many complex -features; and Ruby on Rails (see L), 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 - -MVC, or Model-View-Controller, is a model currently favored for web -applications. This design pattern is originally from the Smalltalk -programming language. The basic idea is that the three main areas of an -application--handling application flow (Controller), processing -information (Model), and outputting the results (View)--are kept -separate, so that it is possible to change or replace any one without -affecting the others, and so that if you're interested in one particular -aspect, you know where to find it. - -Discussions of MVC often degenerate into nitpicky arguments about the -history of the pattern, and exactly what "usually" or "should" go into -the Controller or the Model. We have no interest in joining such a -debate. In any case, Catalyst does not enforce any particular setup; you -are free to put any sort of code in any part of your application, and -this discussion, along with others elsewhere in the Catalyst -documentation, are only suggestions based on what we think works -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 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 -search engine or an LDAP server. - -The purpose of the B is to present data to the user. Typical Views -use a templating module to generate HTML code, using L