[Catalyst] Re: Controllers vs Models

[David Storrs]

On Jun 6, 2005, at 12:57 PM, Justin Tocci wrote:
> Actually I'd rather see the rules in a simple file than in the  
> database.

Out of curiosity, why?  It is easier to attach metadata to the rules  
in a DB.


>> In this case, the problem is that either (A) the Controller will  
>> need to have enough knowledge of the business logic to know what  
>> to fetch (at which point you might as well have just put the  
>> business logic directly in the Controller and saved a DB access),  
>> or (B) the Controller must simply dispatch the request to the  
>> business logic component and say "here, I got this...figure out  
>> what to do with it."  Option B is exactly what Catalyst does now,  
>> so this just adds a redundant dispatch cycle.
>
> (B) is definitely what I'm looking for. The controller fetches an  
> object that has some variable built into it, it checks the rule  
> file for how to evaluate it, fills it in, then sends the component  
> off.

>>> 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.
>>>
>>
>> Another would be to use a template (c.f. Template Toolkit,  
>> HTML::Mason, etc), where the title is filled in from a variable.   
>> This is the way Catalyst currently does it.  I think this is  
>> exactly what you're looking for--the "business logic" (i.e., what  
>> title to use) is in the template file on disk, not in the View (or  
>> Controller, or Model) class.
>
> I'm trying to factor that out of the template to make the template  
> a strictly generic reusable object. I'm trying to imagine one place  
> where all the logic of how to determine the values for those  
> variables would be stored, and if necessary, manually overridden.
>

Ok, two points:  1) 'strictly generic reusable objects' are useless.   
Only when something acquires a certain degree of specificity does it  
become useful.  I'm not being sarcastic here...think about it.  You  
can't have a 'strictly generic' document that is useful.  Simply by  
putting words on the page, you give it some sort of specificity (is  
it a report? a novel? a play?), and that specificity is what makes it  
useful.  The trick is deciding what your universe of discourse is for  
this object and then making it as reusable as possible within that  
universe.

2) I think you should review the Template Toolkit docs (http:// 
www.template-toolkit.org).  The difference between TT and what you  
are looking for seems to be that, instead of having the templating  
engine know how to fill in variables and evaluate code, you want that  
knowledge to be in a separate file.

Right now, you can do something like this in TT:

     [% title %]

And that will be replaced with the contents of the 'title' variable.   
It sounds like you are saying that you don't want this kind of  
directive in the template...that you would rather the template had  
some actual text there which would be magically replaced by the  
business rules.  If this is true, how do the business rules know  
where the title begins and ends?

TT can also do this (assuming the EVAL_PERL option is set on your  
installation of TT):

     [% PERL %]
        print $context->include('myfile');
     [% END %]

It sounds like you are saying that you want to extract this code from  
the template and put it in a business rules file.  In that case, how  
do the business rules know where in the template to insert 'myfile'?   
There needs to be some sort of marker there...which is exactly the  
point of the templating directive.



Also, how do you see your rendering system being structured?  Right  
now, the sequence goes like this:

     - Apache (or other web server) receives request, passes it to  
Catalyst
     - Catalyst calls the relevant action, which happens to reside in  
a View class, passing it certain context
     - the action picks which template to use
     - Catalyst renders that template, filling in appropriate values  
from the context

     Note that the only code you have to write here is the action.   
Everything else is built into Catalyst.


If I understand what you're saying, you want it to go like this:

     - Apache (or other web server) receives request, passes it to  
Catalyst
     - Catalyst calls the relevant action, which happens to reside in  
a Controller class, passing it certain context
     - the Controller loads certain business rules (from cache or  
from disk)
     - the Controller selects which View should be used
     - the Controller passes the request to the View, along with  
context and business rules
     - the View chooses the template
     - the View populates the template based on the business rules  
(or would this still be done by Catalyst?)
     - Catalyst renders that template

Is this right?


>> This is called (logically enough) "rules-based programming" and  
>> there are entire languages written around it...e.g. Prolog.
>>
>> Based on my limited experience of it, RBP is really, really hard.
>>
>> The problem is that there is no clear control flow; the easiest  
>> way to think of it (for me) is from a quantum mechanical  
>> standpoint:  every rule represents a probability of some  
>> particular outcome.  The rules engine takes all the rules,  
>> superimposes them into a unified waveform, and then collapses that  
>> waveform into a single outcome.
>
> You're a good writer you know that? Many couldn't have explained  
> such a concept so succinctly.
>

Thanks.  I didn't go to college as an English major for nothing, you  
know--I payed thousands and thousands of dollars!


>> How exactly you got that particular outcome is hard to track.   
>> Which rules fired?  In what order?  For example, in your list  
>> above, you have 'easy_money' display as 'Easy Money' because the  
>> 'substitute underscore' and 'capitalize name' rules fired in that  
>> order.  If they had fired in the opposite order, then 'easy_money'  
>> would display as 'Easy money'.  How do you ensure that these rules  
>> fire in the correct order?
>
> Sorry, you are right. The capitalization rule should have had a  
> higher priority than the under bar rule:
>
> Example default rules:
> 10 column name should substitute under bars with spaces
> 10 IF column type is 'date' THEN display format is 'mm-dd-yy'
> 15 column name should be capitalized

And there you see the prime problem with RBP: getting the priorities  
right.  This was a tiny example...try to imagine what it's like in a  
system with thousands or tens of thousands of rules.  My last two  
corporate jobs involved engines that did RBP (one was for natural  
language processing on classified ads, the other was for financial  
software).  Both were nightmares.


>> If you want to get a taste of RBP, you might try playing around  
>> with the CLIPS expert system a bit... http://www.pst.com/clpbro.htm
>
> Will do. Thank you again.


Just to be fair...I'll warn you that I worked with CLIPS in college  
(long, long ago) and it drove me insane.  You Have Been Warned. :>

--Dks