2 =head1 Introduction to Maypole
4 This chapter serves as a gentle introduction to Maypole and setting up
5 Maypole applications. We look at what Maypole is, how to get it up and
6 running, and how to start thinking about building Maypole applications.
8 =head2 What is Maypole?
10 Presumably you have some idea of what Maypole is all about, or otherwise
11 you wouldn't be reading this manual. But Maypole is good at many
12 different things, and you may have accidentally focussed on one aspect
13 of Maypole while missing the big picture.
15 For instance, you may know that Maypole is extremely good at putting web
16 front-ends onto databases. This is true, but it's only a part of what
17 Maypole does. You may have heard that Maypole is a web application
18 framework, which is true, but it doesn't mean very much. There are a
19 huge number of things that Maypole can do, because it's very much a
20 blank slate. You can make it do what you will. In this manual, we'll be
21 making it act as a front-end to a database, as a social network site, as
22 an intranet portal, and many other things besides. It is a framework.
24 I like to think that Maypole is a way of going from a URL to a method
25 call to some output. If you have a URL like C</product/order/12>,
26 Maypole is a way of having it load up product number 12, call an
27 C<order> method, and produce a page about what it's just done. The
28 reason Maypole is such a big deal is because it does all this for you.
29 You no longer have to care about your web server. You hardly have to
30 care about your database. You don't have to care about templating
31 modules, parsing CGI parameters, or anything else. You only need to care
32 about business logic, and the business logic in this instance is how you
33 C<order> a product, and what you need to display about it once you've
34 done so. This is what programming should be: only caring about the work
35 that distinguishes one program from another.
37 It does this using a technique called MVC for web applications.
39 =head2 What is MVC for web applications?
41 Maypole was originally called C<Apache::MVC>, reflecting its basis in
42 the Model-View-Controller design pattern. (I had to change it firstly
43 because Maypole isn't tied to Apache, and secondly because
44 C<Apache::MVC> is a really dull name.) It's the same design pattern that
45 forms the foundation of similar projects in other languages, such as
46 Java's Struts framework.
48 This design pattern is found primarily in graphical applications; the
49 idea is that you have a Model class which represents and manipulates
50 your data, a View class which is responsible for displaying that data to
51 the user, and a Controller class which controls the other classes in
52 response to events triggered by the user. This analogy doesn't
53 correspond precisely to a web-based application, but we can take an
54 important principle from it. As Template Toolkit author Andy Wardley explains:
56 What the MVC-for-the-web crowd are really trying to achieve is a clear
57 separation of concerns. Put your database code in one place, your
58 application code in another, your presentation code in a third place.
59 That way, you can chop and change different elements at will,
60 hopefully without affecting the other parts (depending on how well your
61 concerns are separated, of course). This is common sense and good practice.
62 MVC achieves this separation of concerns as a by-product of clearly
63 separating inputs (controls) and outputs (views).
65 This is what Maypole does. It has a number of database drivers, a number
66 of front-end drivers and a number of templating presentation drivers.
67 In common cases, Maypole provides precisely what you need for all of
68 these areas, and you get to concentrate on writing just the business
69 logic of your application. This is one of the reasons why Maypole lets
70 you develop so rapidly: because most of the time, you don't need to do
71 any development at all.
73 =head2 Installing Maypole
75 The first thing you're going to need to do to get Maypole running is to
76 install it. Maypole needs an absolute shedload of Perl modules from CPAN
77 to do its job. I am unrepentant about this. Maypole does a lot of work,
78 so that you don't have to. This is called code re-use, and if we're
79 serious about code re-use, then Maypole should be re-using as much code
80 as possible in terms of Perl modules. In another sense, this gives the
81 impression that Maypole doesn't actually do all that much itself,
82 because all it's doing is gluing together already-existing code. Well,
83 welcome to code re-use.
85 The downside of code re-use is, of course, that you then have to install
86 a shedload of Perl modules from CPAN. If you're using OpenBSD or
87 FreeBSD, the wonderful ports system will be your friend. There's a
88 Maypole port in C<p5-Maypole>. Just type C<make install>.
90 Debian users, hang in there. There's a package coming.
92 For other Unices, the L<CPANPLUS> or C<CPAN> modules will help with
93 this. If you don't have C<CPANPLUS> installed, my recommendation is to
94 use C<perl -MCPAN -e install CPANPLUS> to install it and then throw
95 C<CPAN.pm> away. In any case, one of these two should get all that
98 % perl -MCPANPLUS -e 'install Maypole'
99 % perl -MCPAN -e 'install Maypole'
101 I don't know if Maypole works on Windows. I'm not sure I care.
103 You're also going to need a database server and a web server. For
104 databases, I recommend SQLite (if you install the C<DBD::SQLite> module,
105 you get the SQLite library for free) for prototyping and mysql for
106 production; heavier duty users should use Postgresql or Oracle - Maypole
107 should be happy with them all. Maypole is happiest when running under
108 Apache C<mod_perl>, with the C<Apache::Request> module installed, but as
109 I said, it is a blank slate, and everything is customizable. There is a
110 C<CGI::Maypole> frontend available to run as a standalone CGI script.
112 As well as the documentation embedded in the Perl modules the distribution
113 also includes the manual, of which this is a part. You can access it using the
114 perldoc command, the man command, or by browsing CPAN.
116 =head2 The Beer Database example
118 Throughout this manual, we're going to be referring back to a particular
119 application so that we can give concrete examples for the concepts we're
120 talking about. We could say "C<related_accessors> returns a list of
121 accessors which can be called to return a list of objects in a has-a
122 relationship to the original", or we could say "if we call
123 C<related_accessors> while viewing a C<brewery>, it returns C<beers>,
124 because we can call C<beers> on a C<brewery> object to get a list of
125 that brewery's beers."
127 Because Maypole is all about beer. If you look carefully, you can
128 probably see men playing cricket on the village green. The first
129 ever Maypole application was written to help me keep track of the many
130 different ales available in my area - their styles, their tastes, their
131 breweries, prices and so on. Then the more I thought about it, the more
132 I thought it was a particularly good data model for demonstrating
133 different kinds of database relationships.
135 We have a C<brewery> table, which has several C<beer>s. We'll call this
136 a has-many relationship. The beers each have a C<style>; styles are
137 stored in a separate table, so C<beer> has-a C<style>. Beers are in
138 several pubs and a pub has several beers, so beers and pubs are in a
139 many-to-many relationship. We use a link table called C<handpump> to
140 relate pubs to beers.
142 All in all, this gives us a schema like the following:
144 create table brewery (
145 id int not null auto_increment primary key,
152 id int not null auto_increment primary key,
163 create table handpump (
164 id int not null auto_increment primary key,
170 id int not null auto_increment primary key,
177 id int not null auto_increment primary key,
182 If you have C<DBD::SQLite> available, then a database like this will
183 be created when Maypole was installed. Let's now see how to set it up
184 with a web interface.
186 =head2 Setting up Maypole
188 The first thing we need for a Maypole interface to a database is to
189 have a database. If you don't have one, now would be a good time to
190 create one, using the schema above. If you're creating a database
191 by hand, don't forget to grant permissions for your Apache server to
192 access it as well as yourself (typically a user name like C<www-data>
195 The next thing we need is a module which is going to do all the work.
196 Thankfully, it doesn't need to do B<all> the work itself. It's going to be a
197 subclass of C<Maypole> or a Maypole front-end like C<Apache::MVC>.
198 It roughly corresponds to the controller in an MVC design, and is
199 also referred to as the driver, handler or request.
201 Here's the driver class for our beer database application. We're not
202 going to go into much detail about it here; we'll do that in the
203 L<Beer Database|Maypole::Manual::Beer> chapter.
204 For now, simply admire its brevity, as you realise this is all the code
205 you need to write for a simple database front-end:
208 use Maypole::Application;
209 BeerDB->setup("dbi:SQLite:t/beerdb.db");
210 BeerDB->config->uri_base("http://localhost/beerdb");
211 BeerDB->config->template_root("/path/to/templates");
212 BeerDB->config->rows_per_page(10);
213 BeerDB->config->display_tables([qw[beer brewery pub style]]);
214 BeerDB::Brewery->untaint_columns( printable => [qw/name notes url/] );
215 BeerDB::Style->untaint_columns( printable => [qw/name notes/] );
216 BeerDB::Beer->untaint_columns(
217 printable => [qw/abv name price notes/],
218 integer => [qw/style brewery score/],
222 use Class::DBI::Loader::Relationship;
223 BeerDB->config->{loader}->relationship($_) for (
224 "a brewery produces beers",
225 "a style defines beers",
226 "a pub has beers on handpumps");
229 There's a version of this program in the F<ex/> directory in the Maypole
230 files that you downloaded in the F<~root/.cpan/> build area.
231 This defines the C<BeerDB> application.
232 To set it up as a mod_perl handler, just tell the Apache configuration
236 SetHandler perl-script
240 To use it as a CGI script, put it in your F<cgi-bin> directory,
241 together with a small file called F<beer.cgi>:
249 and change one line in C<BeerDB.pm>:
251 BeerDB->config->uri_base("http://localhost/cgi-bin/beer.cgi");
253 And now we need some templates. As we'll see in the chapter on
254 L<views|Maypole::Manual::View>, there are several types of template.
256 the whole lot from the F<templates/> directory of the Maypole source
257 package into the F</beerdb> directory under our web root.
258 Make the C<template_root> in C<BeerDB> agree with your path.
260 And that's it. We should now be able to go to C<http://localhost/beerdb/>
261 or C<http://localhost/cgi-bin/beer.cgi/>
262 and see a menu of things to browse; C<http://localhost/beerdb/beer/list>
263 will give a list of beers. There might not be any yet. There's a box
264 that lets you add them.
266 If you have any problems getting to this point, you might want to look at
267 L<http://maypole.perl.org>. There's a FAQ and a link to a mailing
270 Play about with the site. Add some beers. Maybe go out and buy some beers
271 to review if you need some inspiration. Don't be ill on my carpet.
273 =head2 Phases of a Maypole request
275 Now you should have a feel for what Maypole can do. The important thing
276 to know at this point is that this is by no means B<all> that Maypole
277 can do. What you've seen in the beer database example is all that Maypole
278 can do if you don't customize it at all.
280 Remember that, for instance, we don't ever tell Maypole what tables our
281 database has, or what columns each table has. We don't tell Maypole what
282 those tables should be called or how to display them. We don't tell Maypole
283 what to do - that we want to list, search, edit and delete beers and breweries.
284 Maypole just works that out for itself. We can customize it and have Maypole
285 do all sorts of interesting things with our database, and most of the rest
286 of this manual will be about how to do that.
288 In order to do that, we need to look at what Maypole's actually doing.
289 Here's a quick overview, there's more detail in the
290 L<Workflow|Maypole::Manual::Workflow> chapter.
292 As mentioned, Maypole is responsible for turning a URL into an object, a
293 method call, and some templated output.
296 Here's a handy diagram to explain how it does that:
299 <IMG SRC="maypole_process2.png">
301 Maypole's process revolves around the concept of the Maypole request
302 object. This is a little like Apache's request object, but at a much
303 higher level - in fact, in C<mod_perl>-based Maypole front-ends, the
304 Apache request object is incorporated in the Maypole request object. All
305 that Maypole does is gradually flesh out this object until it contains
306 something in the C<output> member, and then it is dispatched back to the
307 front-end for output.
309 So to start with, we take the Apache request (or CGI object, or other
310 way of isolating what's going on) and break it down. For instance, we
311 turn the URL C</beer/view/1> into
319 Then Maypole will check that C<beer> is a real table, and find the class
320 that models it. It also checks whether or not we're allowed to call the
321 C<view> method over the network:
327 model_class => "BeerDB::Beer"
330 Then there's a user-defined authentication method, which by default just
331 lets us do anything. Now we hand over to the model class, which loads up
332 the object, and decides what template we want to use:
338 objects => [ BeerDB::Beer->retrieve(1) ],
339 model_class => "BeerDB::Beer",
343 Then it calls C<BeerDB::Beer-E<gt>view>, passing in the request object
344 as a parameter, and passes the whole lot to the view class for templating.
345 In the next two chapters, we'll look at how Maypole's default model and
346 view classes generally do what you want them to do.
350 L<Contents|Maypole::Manual>,
351 Next L<Maypole Model Classes|Maypole::Manual::Model>