78a79,80
> [Excellent as this diagram is, it needs to be broken up into screenfulls]
> 
95,97c97,101
< First, remember we are talking about the standard, unmodified Maypole here. 
< It is possible, and common, to override some or all of this stage and build a 
< customised model.
---
> First, remember we are talking about the standard, unmodified Maypole
> here.  It is possible, and common, to override some or all of this
> stage and build a customised model. [Should be able to illustrate how
> to do this in a three-liner or point to a place in the docs explains
> this.]
112,115c116,120
< Finally, the relationships among these tables are set up. Either do this
< manually, perhaps with the help of L<Class::DBI::Relationship>, or use
< L<Maypole::Plugin::Relationship>. In the latter case, you need to set up the
< relationships configuration before calling C<setup()>.
---
> Finally, the relationships among these tables are set up. Either do
> this manually, perhaps with the help of L<Class::DBI::Relationship>
> (for simple, almost-trivial applications), or use
> L<Maypole::Plugin::Relationship>. In the latter case, you need to set
> up the relationships configuration before calling C<setup()>.
122,123c127,128
< Maypole is a framework, and you can replace different bits as you wish. So what 
< follows is one example of good practice, other people may do things differently. 
---
> Maypole is a framework, and you can replace different bits as you
> wish. That's the neat thing about the MVC architecture.
125,135c130,155
< We assume this application is being built from the ground up, but it will often
< be straightforward to adapt an existing L<Class::DBI> application to this
< general model.
< 
< The main idea is that the autogenerated Maypole model is used as a layer on top
< of a separate L<Class::DBI> model. I am going to refer to this model as the
< 'Offline' model, and the Maypole classes as the 'Maypole' model. The idea is
< that the Offline model can (potentially or in actuality) be used as part of
< another application, perhaps a command line program or a cron script, whatever.
< The Offline model does not know about the Maypole model, whereas the Maypole
< model does know about the Offline model.
---
> Essentially making a usable MVC architecture is about compromise.  An
> MVC that can do everything conceivably possible is not going to
> satisfy anyone.  An MVC that doesn't let you re-define your
> application at anything except the lowest possible level is called a
> procedural program.
> 
> What follows is one example of good practice, other people may do
> things differently.
> 
> We assume this application is being built from the ground up, but it
> will often be straightforward to adapt an existing L<Class::DBI>
> application to this general model.
> 
> To start we want our model to be under the application programmer's
> control, not the MVC programmers' control.  To this end we will use
> L<Class::DBI::Plain> rather than L<Class::DBI::Loader>.  The main idea
> is that the autogenerated Maypole model is used as a layer on top of a
> separate L<Class::DBI> model. [Check sentence 1 and 2 are consistent
> with sentence 3 please.]  I am going to refer to this model as the
> 'Offline' model, and the Maypole classes as the 'Maypole' model. The
> idea is that the Offline model can (potentially or in actuality) be
> used as part of another application, perhaps a command line program or
> a cron script, whatever.  The Offline model does not know about the
> Maypole model, whereas the Maypole model does know about the Offline
> model. [I'm leaving my edits in here, as it may well illustrate a
> substantial pitfall].
146a167,169
> [Is this mutually exclusive from the previous section, or is it a
> progression.  I think you need to make your intention clear]
> 
158c181
<     
---
> 
161c184
<     
---
> 
247c270
< does not itself need to inherit from L<Class::DBI>.
---
> does not itself need to inherit from L<Class::DBI>. [Look, an alternative approach here might be to use WWW::Mechanize how relevant is that?]
251c274
< model base class (C<Offline>). 
---
> model base class (C<Offline>). [This is good because ...]
256c279
< 5. The Maypole model has full access to the underlying Offline model. 
---
> 5. The Maypole model has full access to the underlying Offline model.