[Catalyst] Re: Controllers vs Models
jtocci at tocci.org
Mon Jun 6 05:54:26 CEST 2005
Hi all. I don't think MVC is adequate. Catalyst works something like
--> request from browser
--> http handler (e.g. apache)
--> http handler
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
--> request from browser
--> view handler (e.g. apache)
--> Controller <--> bus. logic expressions component
--> view handler
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!
fort wayne, in
More information about the Catalyst