[Catalyst] Re: Re: Controllers vs Models

[Justin Tocci]

Thanks David for replying.

You are right, my diagram was rough. Thank you for your clarification.

> I am not sure that you are really familiar with the MVC pattern.

Ouch.

> The  Platonic ideal MVC system has all business logic in the  
> Controller,
> all state in the Model, and all presentation is handled by the View.

I disagree. I think the controller should control program flow in a  
generic way, and that business logic is best factored out of it.

> How much more separated out can the business logic get? Or are you
> saying that it could be stored off in a config file (or DB)
> somewhere?

This is exactly what I'm saying. Ideally, the controller should go to  
a different component to get the business logic, where all the  
business logic and only the business logic lives. I don't want this  
to get political, so... consider the example below.

> If so, you program needs to interact with those business
> rules somehow, so who's job is it to pull those rules in and
> interpret them?

The controller.

Example:

You have a View component that should act a little differently  
sometimes. For instance, a list page component should have a  
different title depending on which table it is displaying. One way to  
do it would be to have a separate component for each, another might  
be to put logic in the View that picks a different title based on the  
name of the table it is displaying. Another might be to put the logic  
in the controller.

What I am proposing is to set the business logic off to the side,  
separate it from the controller. This way you have all your business  
logic in one easy to read place. You have no duplicate components,  
and your logic isn't in the view. Most people (I think) would put it  
in the controller, and that means it gets caught up in with the logic  
for program flow, making the code harder to read, write and maintain.  
So pull it out. Program flow to the left, business logic to the  
right. You start with a default set of rules with low priorities and  
override them with your rules by giving them higher priorities. When  
your rules don't override the default, the default rule wins and is  
used.

Example default rules:
10 column name should substitute under bars with spaces
10 column name should be capitalized
10 IF column type is 'date' THEN display format is 'mm-dd-yy'

Custom rules:
100 IF column name is 'nasa' THEN display 'NASA'
100 IF column name is 'describes' THEN display 'Description'
100 IF column type is date and user type is government THEN display  
format is 'yyyy-mmm-dd'

Result:
column name 'easy_money' displays as 'Easy Money'
column name 'nasa' displays 'NASA'
column name 'describes' displays 'Description'
user type is 'commercial' and column type is date, format is 'mm-dd-yy'
user type is 'government' and column type is date, format is 'yyyy- 
mmm-dd'

Advantages:
Rules promote re-use of your basic components by allowing easier on- 
the-fly customization.
The scope side of the rules is very powerful. It allows you to write  
rules that affect your whole app, a very particular situation, or  
anything in between.
Format is clear. Easy to read, write and maintain.
Rule file could be re-used in applications with completely different  
program flow, in effect, it becomes a re-usable component for that  
organization or company.

> Catalyst breaks this out into separate files.  Those files happen to
> be the various Models and Controllers.  I don't understand what you
> are trying to gain that isn't already there.

I'm a beginner and it shows.
Sorry, at this point I'm looking for confirmation that Catalyst is  
the right tool to attempt this with, and perhaps tips on how. You are  
the second person to respond like this and that gives me confidence  
I'm in the right place. Thank you.

> Localization is the job of the View.

Sorry, you are right of course. I was imagining a particular view  
file that has the proper localization might be chosen by the business  
logic if the localization preference was stored in the database. It  
is admittedly a contrived example, but at the time I was trying to  
contrive examples.

>> 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.
>>
>
> http://search.cpan.org/~msergeant/Apache-Reload-0.07/Reload.pm

Understood.

> 1) Feel free to contribute the Catalyst::Model and
> Catalyst::Controller classes to do these things; I would probably use
> them.

Cool. I'll take that as a compliment.

> You go, then!  Let me know how it works out...personally, I'm pretty
> happy with Catalyst thus far.
>
> --Dks

I hope you feel I was responsive to your questions. I'm going to try  
to implement, but I'm not sure how yet. I also am very happy with  
Catalyst, it is very professionally done in my opinion--it certainly  
doesn't need my help. Thank you for writing.

justin