RE: [OT] MVC soup (was: separating C from V in MVC)

[Vuillemot, Ward W]

Wow!  I kept deleting the MVC Soup mailings wihtout reading...I saw "Soup",
thought Soap. . .and just deleted.

>From what I have read thusfar of the archives on MVCyes!  I agree.  I
want to read MORE!!!  I have been a practicing "wannabe" programmer for
sometime, and I have been working out the issues of "MVC" on my own time as
a learning experience for mod_perl, sql, html, et cetera.  I figured the
rest of the world already had all this figured out, and I outta catch up
with the curve.

The one thing I have been thinking over of recent is my basic templating
system.  I have content broken into sheets that can be infinately nested
through programming the controller.  (I am trying to use this new lingo, so
I apologize if I mutilate my own words in the process).  I have broken the
langugae (e.g. English, Japanese, German) into separate config files.  Each
"CGI" is a separate application/module that can be added to the main
authentication controller (includes restrictions/access to users, user
levels (admin/guest/user), and groups of users).  Anything worth controlling
of any application can be done through TEXT config files.  Nothing new here,
I think.

What I would really like to hear is how people handle their own templating.
Is XML'izing (more pointedly XSLT'izing) the process worth the effort?  I
want to develop a system similar to how AxKit does things.  It identifies
the user's display, user's preferred language, et cetera and grabs the
correct content branch (e.g. html, pdf, wml, text).  Any of this can be
overridden by the user (e.g. give me this URL as PDF, or send this URL via
email to this address).

I know that there are a LOT of templating systems out there. . .N+1 for N
perl programmers.

And there is the issue of data checking/integrity/validation.  How
abstracted have people made this process, too?

Before I babble more than necessary...what about perl.apache.org taking on
this whole MVC issue as a part of the site?  Like someone else mentioned, we
have a lot of "tactical" information, but little "strategic" information
available.  Becauese there are so many ways to do things. . .it can be
frustrating. . . since while there are N ways to do it, IMHO there are only
n solutions worth considering.  And where n <<< N.  I would like to get to
that n ways before I die.  :)

Cheers,
Ward

   :  -Original Message-
   :  From: Lyle Brooks [mailto:[EMAIL PROTECTED]]
   :  Sent: Friday, June 07, 2002 4:49 PM
   :  To: Bill Moseley
   :  Cc: [EMAIL PROTECTED]
   :  Subject: Re: [OT] MVC soup (was: separating C from V in MVC)
   :  
   :  
   :  Quoting Bill Moseley ([EMAIL PROTECTED]):
   :  > I, like many, find these discussion really interesting. 
   :   I always wish
   :  > there was some write up for the mod_perl site when all 
   :  was said and done.
   :  > But I guess one of the reasons it's so interesting is 
   :  that there's more
   :  > than one correct point of view.
   :  
   :  I also find this thread extremely interesting.  I didn't 
   :  really know 
   :  what MVC coding was before reading this thread, or that 
   :  by trial and error 
   :  what I had coded had gradually evolved to be more 
   :  "MVC-like", but I'm
   :  really glad this thread came up.
   :  
   :  To me, the eagle book, "the guide", and the cookbook all 
   :  help produce 
   :  great tactical coding techniques, but this discussion 
   :  helps fill in a 
   :  framework for what I've found somewhat missing to date, 
   :  and that is
   :  the employing of "strategic" coding techniques.
   :  
   :  I wish I had more to offer to the discussion, but I echo Bill's 
   :  sentiments that a write-up would be much appreciated and 
   :  I hope the
   :  the "OT" won't take the discussion off list, because I 
   :  think it's has
   :  a great bearing on developing quality mod_perl enabled 
   :  applications.
   :  

Re: [OT] MVC soup (was: separating C from V in MVC)

[Perrin Harkins]

> What I didn't like about this is I then had to adjust the so-called
> controller code that decoded the user input for my request object to
> include these new features.  But really that data was of only interest
to
> the model.  So a change in the model forced a change in the
controller.

No, a change in the user interface forced a change in the controller,
which is fine.  Your user interface now supports parameters of starting
page and page size, so the controller has to know how to handle those
parameters and translate them for the model.  (Incidentally, it's not
such a good idea to make page size a query arg.  Better to put it in
some config file on the server.)

For example, you might have controller code like this:
my $query = $apr->param('query');
my $page  = $apr->param('page');

my $search = Model::Search->new(
query => $query,
page  => $page,
   );

The controller is tightly coupled to parsing and handling user input,
but knows nothing about what that model object will do with it.  It is
basically translating HTTP requests into sets of method calls on model
objects.

> So now I just have been passing in an object which has a param()
method
> (which, lately I've been using a CGI object instead of an
Apache::Request)
> so the model can have full access to all the user input.  It bugs me a
bit
> because it feels like the model now has intimate access to the user
input.

I agree, this is not good.  The controller is supposed to be parsing
that stuff and abstracting it from the model.  The model shouldn't care
if you decide to start encrypting some parameters, or getting them from
the user's session, or using different names for them on different
forms.

> My second, reasonably unrelated question is this: I often need to make
> links back to a page, such as a link for "page next".  I like to build
> links in the view, keeping the HTML out of the model if possible.  But
for
> something like a "page next" link that might contain a bunch of
parameters
> it would seem best to build href in the model that knows about all
those
> parameters.

I don't think it makes a huge difference, but I would probably assemble
these either in the controller or in the view.  The model would just
provide the data.  If they are simple links (i.e. same params always, no
logic) you should be able to use any templating system to build them.
Template Toolkit has a URL plugin for convenience:
http://www.template-toolkit.org/docs/default/Modules/Template/Plugin/URL
.html

- Perrin

RE: [OT] MVC soup (was: separating C from V in MVC)

[Jeff]

> From: Bill Moseley [mailto:[EMAIL PROTECTED]] 
> Sent: 08 June 2002 20:48

> I've gone full circle on handling user input.  I used to try to
abstract
> CGI input data into some type of request object that was then passed
onto
> the models.  But then the code to create the request object ended up
> needing to know too much about the model.

> For example, say for a database query the controller can see that
there's a
> query parameter and thus knows to pass the request to the code that
knows
> how to query the database.  That code passes back a results object
which
> then the controller can look at to decide if it should display the
results,
> a "no results" page and/or the query form again.

So in pseudo code-speak, how about something like:

# Note that I am ignoring Exceptions for the sake of dealing with the
# Controller / Model interaction question.

# $param is a ref to an Apache::Table that contains all the user
submitted
# parameters from the request. The main job of cleanupParams() is to do
# things like URDDecode() etc, and marshal all the user input into a
simple
# structure.
my $param = cleanupParams($r);

# Instantiate Model. Pass it ALL user parameters - Model can cherry pick
only
# the ones it is interested in, and ignore the others. Adding new
parameters
# in the preceeding View that gave rise to this request makes no
difference
# to the Controller - only the Model and View needed to change.
my $Model = My::Model->new( %$param );

# And which View should we instantiate? Well, you might choose one in
the 
# Controller, but I only do this if there was a major Model meltdown.
For
# no result searches, the usual search View should be able to handle
things
# with a nice message.



> Now, what happens is that features are added to the query code.  Let's
say
> we get a brilliant idea that search results should be shown a page at
a
> time (or did Amazon patent that?).  So now we want to pass in the
query,
> starting result, and the page size.

As shown above, the Controller doesn't really care about any new
parameters, it passes them all, including new ones through transparently
to the model.

The model I like for paginated results is straight-forward. When the
Model is instantiated, it does NOT find a query_id field in the passed
parameters, so it assumes a brand new query, and returns the first N
results. A brand new, unique query_id is issued, and becomes a property
of the Model. In the paginated View, this query_id is inserted into a
hidden field (or cookied if you prefer). A session is created using the
query_id that contains all of the parameters that the Model considers
important. The paginated View contains First, Last, Next, Prev links
that just call the same URL with an action=>next, last, prev etc.

When the Model is instantiated for a subsequent page, it sees a
query_id, loads all the query details in from the session storage, and
retrieves the appropriate set of records for the this-time-round View.

> What I didn't like about this is I then had to adjust the so-called
> controller code that decoded the user input for my request object to
> include these new features.  But really that data was of only interest
to
> the model.  So a change in the model forced a change in the
controller.

I think covered above? 

> So now I just have been passing in an object which has a param()
method
> (which, lately I've been using a CGI object instead of an
Apache::Request)
> so the model can have full access to all the user input.  It bugs me a
bit
> because it feels like the model now has intimate access to the user
input.

I don't like this either, but probably need a concrete example of
exactly what Request properties you find it necessary to use in your
Model. The way I see it is that the Controller is interested in the gory
details of the Request object, after all it is a Web Controller, but the
Model should only be interested in the parameters. The Controller uses
the Request object context, and sometimes basic parameters to decide
which Model to instantiate, it doesn't care about Model parameter
requirements - the Model must validate itself.


> links back to a page, such as a link for "page next".  I like to build
> links in the view, keeping the HTML out of the model if possible.  But

> for something like a "page next" link that might contain a bunch of 
> parameters it would seem best to build href in the model that knows 
> about all those parameters.

As described above, I like to use a session to store Model state over
multiple executions / pagination of a collection type Model.


Regards
Jeff

RE: [OT] MVC soup (was: separating C from V in MVC)

[Bill Moseley]

At 12:13 PM 06/08/02 +0100, Jeff wrote:
>The responsibility of the Controller is to take all the supplied user
>input, translate it into the correct format, and pass it to the Model,
>and watch what happens. The Model will decide if the instruction can be
>realised, or if the system should explode.

I'd like to ask a bit more specific question about this.  Really two
questions.  One about abstracting input, and, a bit mundane, building links
from data set in the model.

I've gone full circle on handling user input.  I used to try to abstract
CGI input data into some type of request object that was then passed onto
the models.  But then the code to create the request object ended up
needing to know too much about the model.

For example, say for a database query the controller can see that there's a
query parameter and thus knows to pass the request to the code that knows
how to query the database.  That code passes back a results object which
then the controller can look at to decide if it should display the results,
a "no results" page and/or the query form again.

Now, what happens is that features are added to the query code.  Let's say
we get a brilliant idea that search results should be shown a page at a
time (or did Amazon patent that?).  So now we want to pass in the query,
starting result, and the page size.

What I didn't like about this is I then had to adjust the so-called
controller code that decoded the user input for my request object to
include these new features.  But really that data was of only interest to
the model.  So a change in the model forced a change in the controller.

So now I just have been passing in an object which has a param() method
(which, lately I've been using a CGI object instead of an Apache::Request)
so the model can have full access to all the user input.  It bugs me a bit
because it feels like the model now has intimate access to the user input.

And for things like cron I just emulate the CGI environment.

So my question is: Is that a reasonable approach?

My second, reasonably unrelated question is this: I often need to make
links back to a page, such as a link for "page next".  I like to build
links in the view, keeping the HTML out of the model if possible.  But for
something like a "page next" link that might contain a bunch of parameters
it would seem best to build href in the model that knows about all those
parameters.

Anyone have a good way of dealing with this?

Thanks,

P.S. and thanks for the discussion so far.  It's been very interesting.


-- 
Bill Moseley
mailto:[EMAIL PROTECTED]

RE: [OT] MVC soup (was: separating C from V in MVC)

[Jeff]

> From: Jesse Erlbaum [mailto:[EMAIL PROTECTED]] 
> Sent: 07 June 2002 18:58

> The purpose of the controller is to validate input and construct 
> valid arguments into these model methods.

Jesse, maybe its just semantics coming between us - if so, I apologise
in advance!

I think that the purpose of the Controller is to map User Input onto
Model properties and methods. The validation of any of the properties,
Model parameter calls etc must be in the Model, otherwise every
Controller that uses a Model must duplicate all the validation.

Let's say for example that I have a generic page with lots of fields,
that lets you create a Payment Instruction from your bank account.
Payment Instructions can be domestic or international. When you fill in
the details and hit submit, our Controller gets poked in the belly.

It is not reasonable for the Contoller to know that when creating an
International Payment, that the instruction dates for Italy must be at
least five working days in the future, and must not fall on an Italian
bank holiday. This is information that the Payment Instruction Model
should validate.

It is also not reasonable for a Controller to know that when creating
Swiss Blue Slip International Payments, that in addition to all the
other usual required fields, a 15 digit creditor reference number is
also required. 

The responsibility of the Controller is to take all the supplied user
input, translate it into the correct format, and pass it to the Model,
and watch what happens. The Model will decide if the instruction can be
realised, or if the system should explode.

The only type of validation that a controller _might_ perform would be
data type - e.g. is this a recognisable date? but even then it may may
more sense for the Model to interpret it. For example, a US Payment
Instruction might interpret 04/15/02 [15th April] as valid, but a UK
Payment Instruction might consider this a bad joke [4th day of 15th
month?]. 

Such basic type validation is often pushed to the Client in JavaScript,
to make for a 'richer user experience', but in any case would still need
to be checked - either in the Controller or Model.

It is a valid job of the controller to TRANSLATE input parameters into
an acceptable format for the Model. For example, it is valid to URL
Decode a string before passing it to a Model. The URL decoding is a
direct consequence of the way in which the user is interacting with the
Model, and hence a valid thing for a Web Controller to do. URL decoding
should not be in the Model, as it would have no relevance when the Model
is used in a cron job. There is a difference between translation and
validation.


> The controller is also responsible for catching any exception from the
> methods it calls ... and relaying that to the output view in a
reasonable
> fashion.  By reasonable I do *not* mean "pretty HTML".  A "500
Internal
> Server Error" is perfectly reasonable in some situations.

I agree that this is a problematic area that needs some careful advance
thought, and a protocol whereby the Controller is told that something
went wrong - the Controller might well choose to instantiate a different
View after an exception.


> As I said in my first message on the topic, the model should be
thought 
> of in the context of being used from a variety of interfaces besides 
> the web ("cron", for instance).  A "controller" between a cron process

> and your model, for example, would be responsible for ensuring that 
> valid arguments are passed into the model methods

Maybe I am miss-understanding your 'valid arguments'? Because I disagree
- Models must validate themselves. You DON’T want to duplicate
validation code and tests in both the Web Controller and the cron job
Controller.

£0.2

Regards
Jeff

Re: [OT] MVC soup (was: separating C from V in MVC)

[Perrin Harkins]

> I wish I had more to offer to the discussion, but I echo Bill's
> sentiments that a write-up would be much appreciated

There really are a lot of articles about MVC for web applications.  It
sounds like Jesse has a new one coming out soon.  I covered the basics
of it here:
http://perl.apache.org/release/docs/tutorials/apps/scale_etoys/etoys.htm
l#Code_Structure

And the templating tools we've discussed are all covered in my
templating tutorial.  It's getting a little long in the tooth, but I
think it does a good job of conveying the angle that each of the tools
has taken.

Rob and I talked about writing something, but honestly I have a hard
time thinking of what more there is to say.  The best thing to do is go
and look at the many examples of MVC frameworks for Perl (bOP,
OpenInteract, CGI::Application, etc.) and dive into their sample code.

- Perrin

Re: [OT] MVC soup (was: separating C from V in MVC)

[Rob Nagler]

John Siracusa writes:
> The details have been heavily simplified above, but that's the general idea.
> I'm not sure how this all fits into MVC, but it works very well for my
> purposes.

I think it fits very well into MVC.  The flow you described is similar
to what we do in "pure" MVC.

To my mind the controller's job is to translate parameter formats and
to control flow.  For example, the controller in bOP abstracts
multipart/form-data and www-url-encoded forms with a class which
returns the raw key/value data.  If the basic HTTP protocol is not
observed, an exception is raised.  Otherwise, it is up to the form to
validate the data.

One of the things we've worked hard on is understanding the
HTTP form abstraction.  The first thing we noticed is that a form can
be treated like any other model.  It has fields, types, and values.

We've boiled FormModel execution down to four modes:

empty - the user visits the form for the first time.  You may want
to fill in default values.

validate_and_execute - the validation and execution phases are
separate.  The basic field validation is performed by the base
class (FormModel) which asks the field types to parse the
data.  The form itself cross validates the fields, and has the
opportunity to clear any errors found by the field validation.

other button - this might be cancel or "symbol lookup" or any
other nonstandard button.  You can call validate_and_execute
or any other method (clear button might call execute_empty).

unwind - allows the form to handle any data returned from a "call"
to another form.  It's like using the value from a subroutine
return. 

By default, the form falls through on empty, unwind, and invalid data.
It can "redirect" through the use of exceptions.  If
validate_and_execute leaves "errors" on the form (invalid data state),
it falls through to the view so the errors can be rendered.

All errors are bound to a form field and have a value (TypeError)
which has a default rendering, e.g. NULL renders as "you must supply a
value".  The presentation layer can override the default string with a
value which is looked up based on the tuple (from, field, error) with
varying degrees of qualification.  Without a TypeError abstraction,
the model doesn't give enough data to the view.

Rob

Re: [OT] MVC soup (was: separating C from V in MVC)

[Lyle Brooks]

Quoting Bill Moseley ([EMAIL PROTECTED]):
> I, like many, find these discussion really interesting.  I always wish
> there was some write up for the mod_perl site when all was said and done.
> But I guess one of the reasons it's so interesting is that there's more
> than one correct point of view.

I also find this thread extremely interesting.  I didn't really know 
what MVC coding was before reading this thread, or that by trial and error 
what I had coded had gradually evolved to be more "MVC-like", but I'm
really glad this thread came up.

To me, the eagle book, "the guide", and the cookbook all help produce 
great tactical coding techniques, but this discussion helps fill in a 
framework for what I've found somewhat missing to date, and that is
the employing of "strategic" coding techniques.

I wish I had more to offer to the discussion, but I echo Bill's 
sentiments that a write-up would be much appreciated and I hope the
the "OT" won't take the discussion off list, because I think it's has
a great bearing on developing quality mod_perl enabled applications.

Re: [OT] MVC soup (was: separating C from V in MVC)

[Perrin Harkins]

Jesse Erlbaum wrote:
>>You could also just punt and push this out to the 
>>controller.  (Not very "pure" but simple to implement.)  
> 
> 
> This is exactly what I had in mind.  (Perhaps you can explain what you mean
> by "not very pure".)

Only that ideally you would want to keep this kind of knowledge just in 
the model objects, so that it is only expressed in one place.  The 
controller shouldn't have to know that the "email" property of the 
Person model object needs to be a valid e-mail address; it should only 
be responsible for reading that in with $r->args() or something and 
passing it to the Person object, which knows how to check if its 
arguments are valid.  However, I found it to be a real pain to code it 
that way and try to give nice error messages, which is why I now think 
that the simplicity of using standard form validation techniques makes 
up for the redundancy in most cases.

- Perrin

RE: [OT] MVC soup (was: separating C from V in MVC)

[Jesse Erlbaum]

Hey Perrin & Bill --

> You could also just punt and push this out to the 
> controller.  (Not very "pure" but simple to implement.)  

This is exactly what I had in mind.  (Perhaps you can explain what you mean
by "not very pure".)  The methods in any model module I would write would
have expectations that input is already valid.  Invalid input to a model
method should throw an exception of some sort (maybe die() -- but something
clearly documented in POD, whatever it is).  The purpose of the controller
is to validate input and construct valid arguments into these model methods.

The controller is also responsible for catching any exception from the
methods it calls (model methods, Perl core methods, other module methods --
they're ALL the same!), and relaying that to the output view in a reasonable
fashion.  By reasonable I do *not* mean "pretty HTML".  A "500 Internal
Server Error" is perfectly reasonable in some situations.

This fits into my general feeling that the role of the controller is to
interface between the UI and the model.  As I said in my first message on
the topic, the model should be thought of in the context of being used from
a variety of interfaces besides the web ("cron", for instance).  A
"controller" between a cron process and your model, for example, would be
responsible for ensuring that valid arguments are passed into the model
methods and that errors are thrown back to cron in such a way that cron can
do something useful with them (such as invoke "Vixie" cron's capability to
email the process owner).


> Either way you 
> can use one of the convenient form validation packages on CPAN.

The members of the CGI::Application mailing list seem particularly fond of
the Data::FormValidator module.


TTYL,

-Jesse-

Re: [OT] MVC soup (was: separating C from V in MVC)

[John Siracusa]

On 6/7/02 1:04 PM, Perrin Harkins wrote:
> For example, if you have a form for registering as a user which has
> multiple fields, you want to be able to tell them everything that was
> wrong with their input (zip code invalid, phone number invalid, etc.),
> not just the first thing you encountered.
> 
> Putting that into a model object is awkward, since coding your
> constructor or setter methods to keep going after they've found the
> first error feels wrong.  You can write a special validate_input()
> method for it which takes all the input and checks it at once returning
> a list of errors.  You could also just punt and push this out to the
> controller.  (Not very "pure" but simple to implement.)  Either way you
> can use one of the convenient form validation packages on CPAN.

I use my form objects to do this.  For example, to process a "create user"
form, the controller creates the form object:

$form = My::Form::User::Edit->new;

Initializes it based on the form submission:

$form->init($form_params);

runs the form object's validate() method:

unless($form->validate)
{
  ...

and then (if the validation fails) passes the initialized form objects to
back to the view:

  $app->edit_user_page(form => $form);

There are per-field and per-form errors which are set during the validate()
step.  The view decides where, how, and if to display these.

Going in the reverse direction (say, editing an existing user), the
controller creates the form again:

$form = My::Form::User::Edit->new;

gets the user object (and handles errors, yadda yadda):

$user = My::Users->get_user(id => $id) || ...;

initializes the form with the model object:

$form->init_with_user($user);

and then passes the form to the view:

$app->edit_user_page(form => $form);

The details have been heavily simplified above, but that's the general idea.
I'm not sure how this all fits into MVC, but it works very well for my
purposes.

-John

Re: [OT] MVC soup (was: separating C from V in MVC)

[Perrin Harkins]

Bill Moseley wrote:
> My MVC efforts often fall apart in the C an M separation.  My M parts end
> up knowing too much about each other -- typically because of error
> conditions e.g. data that's passed to an M that does not validate.  And I
> don't want to validate too much data in the C as the C ends up doing M's work.

I agree that this is one of the thornier problems.  For simple things 
you can just throw exceptions, as Jesse mentioned.  This is all you need 
to do for system-level problems like failing to connect to the database. 
  The difficult part is when you need to provide feedback to users on 
their incorrect input.

For example, if you have a form for registering as a user which has 
multiple fields, you want to be able to tell them everything that was 
wrong with their input (zip code invalid, phone number invalid, etc.), 
not just the first thing you encountered.

Putting that into a model object is awkward, since coding your 
constructor or setter methods to keep going after they've found the 
first error feels wrong.  You can write a special validate_input() 
method for it which takes all the input and checks it at once returning 
a list of errors.  You could also just punt and push this out to the 
controller.  (Not very "pure" but simple to implement.)  Either way you 
can use one of the convenient form validation packages on CPAN.

> Anyone have links to examples of MVC Perl code (mostly controller code)
> that does a good job of M and C separation, and good ways to propagate
> errors back to the C?  

You could look at the OpenInteract code.  It includes some good examples.

- Perrin

RE: [OT] MVC soup (was: separating C from V in MVC)

[Ged Haywood]

Hi all,

On Fri, 7 Jun 2002, Valerio_Valdez Paolini wrote:

> 
> On Thu, 6 Jun 2002, Jeff wrote:
> 
> > We can take the discussion off-line if the list feels it will be too OT.
> 
> No, please :)

Yes, please.

73,
Ged.

Re: [OT] MVC soup (was: separating C from V in MVC)

[Rob Nagler]

Bill Moseley writes:
> Anyone have links to examples of MVC Perl code (mostly controller code)
> that does a good job of M and C separation, and good ways to propagate
> errors back to the C?  

I humbly (do believe that ;-) submit http://petshop.bivio.biz
Every page contains the control logic which is dynamically parsed from
the Task configuration.  Here's an example:

http://petshop.bivio.biz/pub/products?p=BIRDS

The configuration for this task is:

[qw(
PRODUCTS
500
GENERAL
ANYBODY
Model.ProductList->execute_load_all_with_query
View.products
)],

The name of the task which is used for all internal linkages is
PRODUCTS.  The number is a convenience for FormContext, i.e. our
"closure" mechanism for holding state between HTTP forms.

The "realm" is GENERAL, i.e. there is no particular owner.  You might
have a USER realm or CLUB (group) realm, which have owners.

Permission bit is ANYBODY.  You can have multiple permission bits,
e.g. DATA_WRITE&DATA_READ.

The rest of the list are "items" which are executed serially.  The
syntax is ..  A class map allows you to configure
where your models are loaded from.

Here's another example:

[qw(
LOGIN
517
GENERAL
ANYBODY
Action.UserLogout
Model.UserLoginForm
View.login
next=CART
MISSING_COOKIES=MISSING_COOKIES
)],

The '=' elements (which is not "strictly" perl, but hey, we all have
are inconsistencies ;-) map events to other tasks.  For example, if
you get a MISSING_COOKIES exception you go to the MISSING_COOKIES
task.  next=CART says that the next task on an OK on the form is the
CART task.

All tasks can be found in
http://petshop.bivio.biz/src?s=Bivio::PetShop::Agent::TaskId

This is all you need to know about the controller if you use bOP.  You
list your tasks and bOP's Agent does the rest.  BTW, the tasks might
be executed via e-mail or HTTP or the command line.  The controller
abstracts this away, too.  (We actually removed our Bivio::Agent::Mail
implementation, because it made more sense to implement everything via
Apache instead of custom servers.)

The interface for Views, Actions, and Models is called "execute".
You'll be passed a Bivio::Agent::Request object which holds the
context for the transaction.

Rob

RE: [OT] MVC soup (was: separating C from V in MVC)

[Valerio_Valdez Paolini]

On Thu, 6 Jun 2002, Jeff wrote:

> We can take the discussion off-line if the list feels it will be too OT.
No, please :)

Valerio

 Valerio Paolini, 
--
 what is open-source about? Learn, and then give back

RE: [OT] MVC soup (was: separating C from V in MVC)

[Jeff]

> From: Bill Moseley [mailto:[EMAIL PROTECTED]] 
> Sent: 06 June 2002 19:06
> To: [EMAIL PROTECTED]


> My MVC efforts often fall apart in the C an M separation.  
> My M parts end up knowing too much about each other -- typically 
> because of error conditions e.g. data that's passed to an M that 
> does not validate.  And I don't want to validate too much data 
> in the C as the C ends up doing M's work.

This sounds like an interesting area to explore - I would quite like to
get down to some specifics, for example to work through some concrete
examples and bounce some designs around. Can we take a real instance
where you have a problem, and see if we can develop an
understanding? 

Will you be willing to post some descriptions of [possibly simplified]
cases where you want to review your current MVC split? 

Or should we take a simple example and see what happens? For example, we
could model a basic internet banking site - the
data strunctures, range of events, presentation etc are simple and
generally well understood.

We can take the discussion off-line if the list feels it will be too OT.

Regards
Jeff

RE: [OT] MVC soup (was: separating C from V in MVC)

[Jeff]

> From: Jesse Erlbaum [mailto:[EMAIL PROTECTED]] 
> Sent: 06 June 2002 19:34
> To: 'Bill Moseley'; [EMAIL PROTECTED]

> First off, it is less of an "MVC crime" to combine your Model and 
> Controller than it is to combine your Controller and View.  

I disagree - coupling Controller and Model contradicts the fundamental 
tenet of MVC which is separation of Model from the Controller and View
UIs.
As I understand it, the main benefit of MCV is that the Model knows the 
minimal possible about the Controller and View UIs.

Most pundits indicate that the only relationship between a Model and
View
is that of the weakly typed observer pattern.

I should point out that the mod_perlish MVC as described so far in these
threads is only loosely based on the MVC pattern, which was originally
designed for more traditional stateful user interfaces than web
browsing.

Here are some MVC pages that indicate Models should NOT be closely
linked
to Controller, and that in fact the relationship between the two user
interface components [ie Controller and View] may be stronger.
  http://ootips.org/mvc-pattern.html

And the MVC relationships are covered, esp on page 5 of this
  http://www.cs.indiana.edu/~cbaray/projects/mvc.html

and there are some good pictures on this link
  http://www.object-arts.com/EducationCentre/Overviews/MVC.htm 

which also says:
'What we really want, though, is a tight coupling between AM and View
but a 
loose coupling between Domain Model and View'

I parse this as 'tight coupling between Controller and View but a loose 
coupling between Model and View'

£0.02

Regards
Jeff

Re: [OT] MVC soup (was: separating C from V in MVC)

[Rafiq Ismail (ADMIN)]

> On Thu, 6 Jun 2002, Bill Moseley wrote:
>
> > Anyone have links to examples of MVC Perl code (mostly controller code)
> > that does a good job of M and C separation, and good ways to propagate
> > errors back to the C?

I'm working on my own impelmentation at the moment and am planning to have
a mechanism in my unoverridden forms controller subclass which hosts
methods which can validate data based on types derrived from the form's
input names, together with a set of valid fields.  For more complex
validation I'm planning on subclassing and overloading these methods.

The validation routines get called if there is a '_validate' field and
these in turn generate an errors structure which gets fed to the View's
view of the model.  I have a seed method in my controller which determines
the execution order, however what it does is call other seeds in the model
layer.  If all is cool, it does an internal redirect to the next page as
supplied in a hidden field - or determined at runtime.

You'll have to excuse me for the mubling, but my face is currently being
stuffed full of falafal. :)  Try some?

Fiq.

RE: [OT] MVC soup (was: separating C from V in MVC)

[Jesse Erlbaum]

Hi Bill --


> I, like many, find these discussion really interesting.  I always wish
> there was some write up for the mod_perl site when all was 
> said and done.
> But I guess one of the reasons it's so interesting is that 
> there's more
> than one correct point of view.

I expect to complete an article on this exact topic in the next month which
is scheduled to appear in one of the major Perl-related publications.  I'll
try to keep my typically unyielding and vitriolic opinions in check.  :-)


> My MVC efforts often fall apart in the C an M separation.  My 
> M parts end
> up knowing too much about each other -- typically because of error
> conditions e.g. data that's passed to an M that does not 
> validate.  And I
> don't want to validate too much data in the C as the C ends 
> up doing M's work.

First off, it is less of an "MVC crime" to combine your Model and Controller
than it is to combine your Controller and View.  In fact, on a small
application which is not going to be used in a radically different way
anytime soon it makes very good sense to do so!  Investing in writing
reusable code without a (re)use-case in mind is a waste of time and money.
Don't build it -- you won't need it!

Assuming you have a (re)use-case in mind for your Model, handling errors is
pretty easy.  If some code calls a method in your model with invalid
arguments just throw an exception!  Handle errors just like you would in any
method!  Don't get hung up on the fact that this is the "Holy Model".  It's
just a method.  Don't be afraid to croak() if the situation deserves it.
This is basic exception handling, and all the usual techniques (or, in Perl,
the lack thereof) apply.


TTYL,

-Jesse-

Re: [OT] MVC soup (was: separating C from V in MVC)

[Rafiq Ismail (ADMIN)]

On Thu, 6 Jun 2002, Bill Moseley wrote:

> Anyone have links to examples of MVC Perl code (mostly controller code)
> that does a good job of M and C separation, and good ways to propagate
> errors back to the C?

"http://pagekit.org,"; might be interesting.

Fiq

[OT] MVC soup (was: separating C from V in MVC)

[Bill Moseley]

I, like many, find these discussion really interesting.  I always wish
there was some write up for the mod_perl site when all was said and done.
But I guess one of the reasons it's so interesting is that there's more
than one correct point of view.

My MVC efforts often fall apart in the C an M separation.  My M parts end
up knowing too much about each other -- typically because of error
conditions e.g. data that's passed to an M that does not validate.  And I
don't want to validate too much data in the C as the C ends up doing M's work.

Anyone have links to examples of MVC Perl code (mostly controller code)
that does a good job of M and C separation, and good ways to propagate
errors back to the C?  


-- 
Bill Moseley
mailto:[EMAIL PROTECTED]