From: Simon Cozens <simon@simon-cozens.org>
Date: Fri, 16 Apr 2004 13:03:55 +0000 (+0000)
Subject: This *really* ought to be a recipe.
X-Git-Tag: 2.10~225
X-Git-Url: https://git.decadent.org.uk/gitweb/?a=commitdiff_plain;h=b90c6e146c423746001d304953b6b136acc666db;p=maypole.git

This *really* ought to be a recipe.


git-svn-id: http://svn.maypole.perl.org/Maypole/trunk@137 48953598-375a-da11-a14b-00016c27c3ee
---

diff --git a/doc/Request.pod b/doc/Request.pod
index fc51d1b..1782cd5 100644
--- a/doc/Request.pod
+++ b/doc/Request.pod
@@ -17,6 +17,38 @@ These hacks deal with changing the way Maypole relates to the outside world;
 alternate front-ends to the Apache and CGI interfaces, or subclassing chunks
 of the front-end modules to alter Maypole's behaviour in particular ways.
 
+=head3 Separate model class modules
+
+You want to put all the C<BeerDB::Beer> routines in a separate module,
+so you say:
+
+    package BeerDB::Beer;
+    BeerDB::Beer->has_a(brewery => "BeerDB::Brewery");
+    sub foo :Exported {}
+
+And in F<BeerDB.pm>, you put:
+
+    use BeerDB::Beer;
+
+It doesn't work.
+
+B<Solution>: It doesn't work because of the timing of the module
+loading. C<use Beer::Beer> will try to set up the C<has_a> relationships
+at compile time, when the database tables haven't even been set up,
+since they're set up by
+
+    BeerDB->setup("...")
+
+which does its stuff at runtime. There are two ways around this; you can
+either move the C<setup> call to compile time, like so:
+
+    BEGIN { BeerDB->setup("...") }
+
+or move the module loading to run-time (my preferred solution):
+
+    BeerDB->setup("...");
+    BeerDB::Beer->require;
+
 =head3 Debugging with the command line
 
 You're seeing bizarre problems with Maypole output, and you want to test it in