MVC...wrapping (or is warping) my brain

["Vuillemot, Ward W" <wa...@boeing.com>]

Okay, before some yells for all this to stop. . .I was wondering if anyone
could verify/comment on the below.

In understanding MVC, I have been trying to see the forest from the trees (
and other such cliches.)

Part of my problem is I think I munched M with C. . .and I am wondering how
to separate them.

M = MODEL
	I fail to see how this is accomplished.  As an aside, I recently
wrote a shell module that uses nested hashes to create a model of the user
interaction.  if it returns a scalar then know I need to evaluate a
subroutine, otherwise if a hash then I know I have another node of a tree
branch to process.  And so creating nested menus is as simple as editing the
hash...I am sure I simply reinvented the wheel, but it works quite well for
me.  HOWEVER, I do not how to do this easily in a mod_perl environment.
What do people use to model the interactions?  At present, all my modules
default as a "modeller".  That is, if no main() method exists within the
module it inherits this method from the base module.  This base module
creates a menu of options that is defined within the config for that actual
module being called.  Therefore, the model tree is non-centralized.  This
allows me to just build branches in a tree -- at least to the user it looks
like a tree.  BUT, it really does not matter to the module where it exists
in this "tree".  So I have the looks of a tree, but it ain't really a tree.
. .and therefore I gots meself a problem, no?  What I need to do is create a
model within each module. . .at present I just use if statements. . .which I
think is not the best way to do things.  Should I just do what I did with
the shell -- that is to say create a hash of hashes/array.  Then I can
follow along the hash to find out controller to use and what view to use?
Did I just answer my own question?

C = CONTROLLER
	This is simply (in our case) mod_perl. . .?

V = VIEW
	This is a tree that matches node for node the tree in the model, no?
If I am at A-A-B in the model, then get view A-A-B


--- A REAL MOD_PERL QUESTION ----

Does anyone have comments on using one handler or multiple handlers for a
set of related scripts?
At present, I use one handler. (In large part because I understand how this
works. . .)  This lone perl handler invokes a base module that checks
session, asks for login if necessary, and if all things goes well calls the
appropriate controller.  This way all my controllers get the use of these
facilities. . .I guess I could inherit these methods. . .and comments from
P. Harkins re: e-toys has me wondering.  I have the same thoughts/concerns
about pass the request arguments around from Apache.  I hate having commonly
used variables in the subroutine call -- it clutters things too much.  IMHO.

Cheers,
Ward

Re: MVC...wrapping (or is warping) my brain

[Perrin Harkins <pe...@elem.com>]

Vuillemot, Ward W wrote:
> --- A REAL MOD_PERL QUESTION ----

Andy already responded to the other part, so I'm just responding to this 
part.

> Does anyone have comments on using one handler or multiple handlers for a
> set of related scripts?

It works both ways.  I like having separate handlers that share behavior 
through inheritance and common classes.

> At present, I use one handler. (In large part because I understand how this
> works. . .)  This lone perl handler invokes a base module that checks
> session, asks for login if necessary, and if all things goes well calls the
> appropriate controller.

That should work fine.  The only thing that bugs me about the "universal 
handler" approach is that you end up having to rewrite the basic URI -> 
handler mapping functionality that httpd.conf already provides. 
Sometimes there are good reasons to do this (i.e. adding some important 
functionality to the mapping process), but often there are not.

- Perrin

Re: MVC...wrapping (or is warping) my brain

[Andy Wardley <ab...@andywardley.com>]

On Mon, Jun 17, 2002 at 08:28:54AM -0700, Vuillemot, Ward W wrote:
> Part of my problem is I think I munched M with C. . .and I am wondering how
> to separate them.

Think of it like this:

   MODEL: your data
   CONTROLLERS: things that change your data
   VIEWS: things that display your data

Controllers are effectively "inputs" that can change the data in the model
and have other side-effects.  Views are effectively "outputs" that should 
not change things in the model and should not have any side effects.

Typically, your model will be respresented by a set of modules that implement
the basic data functionality (e.g. fetch/add records, search, etc).  Ideally
this should abstract the implementation of the underlying storage system.
For example, you should use methods like add_user(\%user_args) rather than 
sql_query("INSERT INTO user blah blah blah").

Your controllers will be application modules that perform particular tasks 
by making various calls against the model.  For example, read some CGI params,
call add_user() against the model, check result.

Your views will be templates (or otherwise) which display parts of the model
(e.g. page confirming user has been added complete with new user details).

You may also have a high-level request handling module(s) which maps 
requests onto the right combination of controller/model/view for a 
particular page.

That's a bit of an over-simplification, but hopefully that's what you want:
the shape of the forest, not the trees.

A