[Catalyst] Re: Re: Controllers vs Models
jtocci at tocci.org
Mon Jun 6 17:25:01 CEST 2005
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.
> The Platonic ideal MVC system has all business logic in the
> 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)
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?
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
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'
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'
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-
Rules promote re-use of your basic components by allowing easier on-
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
>> 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.
> 1) Feel free to contribute the Catalyst::Model and
> Catalyst::Controller classes to do these things; I would probably use
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.
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.
More information about the Catalyst