[Catalyst] Re: Controllers vs Models

[Justin Tocci]

Hi all. I don't think MVC is adequate. Catalyst works something like  
this:

  *start*
  --> request from browser
    --> http handler (e.g. apache)
      --> Controller
        <--> Model
      --> Controller
    --> http handler
  --> browser
  *end*

Real quick and simple, I'd like to see Catalyst take a step in the  
direction of separating out the business logic from the entire  
design. What's wrong with MVC is that business logic has to go  
somewhere, some will make room in the model, some in the controller,  
probably all three in a large application, but it could be separated  
out entirely.

  *start*
  --> request from browser
    --> view handler (e.g. apache)
      --> Controller   <--> bus. logic expressions component
        <--> Model
      --> Controller
    --> view handler
  --> browser
  *end*

Since business logic rightly involves model, view and controller,  
it's ok to put code in the business logic that says to display a date  
a certain way, or multiply a certain field by pi before displaying  
it. Some examples of business logic I'd like to see separated out  
into a separate file would work like this; "if user type is admin,  
then allow delete action" (this would affect all pages for admin  
users), "if page type is edit and user type is sales then show edit  
record button", "if country is usa, then date format is mm-dd-yy".

You could quickly write a base set of rules for admin, sales, office,  
accounting, etc... giving groups permissions on what tables they can  
and can't see, edit, or administer. Or, write a base set of rules for  
display by the user's language. What's "edit" in Spanish anyway?

One beauty of this scheme is that you could probably work out a way  
to re-load the rules on the fly, allowing for lightning-quick  
development and testing. Another is that you could go many miles  
further on standard CRUD views with a good base of default rules.  
Default rules would come up with good display names for columns by  
changing under-bars to spaces and capitalizing words. On top of that  
you could single out exceptions by writing rules that would override  
the default, for instance, acronyms would need to have rules like,  
"if column name is nasa, then display name is 'NASA'", note that a  
rule like this is good for any page or situation. Some rules will  
start "if user is sales" but they don't all have to. Therein lay the  
power of rule-based rapid application development, a rule has the  
scope you give it. It can affect the entire application or just a  
single component in a very particular situation.

Perhaps the rules should be separated out further. One rule file each  
for model, view and controller? This might speed development by  
allowing different formats. Not that anyone's interested.

The adept may recognize that I miss my rule file from WebObjects, but  
the truth is, he who can deliver this functionality in a simple way  
with Perl would gain fame, fortune and honor before all. I have  
abandoned WebObjects because of all the things wrong with it, but  
this one feature kept me at it for a very long time.

I will commit 100 hours to the project over the next 90 days, a two  
page summary of how it could work in 14 days, coordinate the  
development of the default set of rules, and whatever else I can fit  
into my schedule if a project were to take on a design goal like  
this. I'll, yes, I'll even, yes, I'll even write documentation! Ugh!


justin tocci
fort wayne, in