[Catalyst] Controllers, Models and flow control

[Justin Tocci]

'Business Logic' is a more ambiguous phrase than I thought. After  
some thought, I think I would have been better off using the term  
'business rules', but not by much.

David Storrs had this to say to Dominique:

> Business logic is just the set of rules that
> describe what operations should be carried out on the data, and how
> the state should change.  "When selling to a customer in Europe, add
> VAT tax to the price" is a business rule.  These things have nothing
> to do with widgets...there may be widgets onscreen which are involved
> in gathering information for, or expressing the results of, or
> triggering, business rules, but those widgets are not part of the
> business rule per se.

I agree with David that the business rules are not the widgets and  
vice versa, but I think they are related. To me, they are a  
substitute for methods. Sometimes the method is overridden and a  
value is assigned directly, but its still a method. Sometimes the  
method will change a data format, sometimes it could modify your  
view, like prettying up column names. As David pointed out, it might  
figure your tax. I think rules are best used to configure your  
components. Methods that work on your data I would put in the model  
and I'm not referring to them at all.

Figuring your tax might work as a method in your model, but the  
information for which tax to apply is likely to be in your session,  
whereas a method in the model would be more appropriate when the  
input has to be found on disk. I reason, figure the tax when the  
session is in hand, then send out to view or commit to disk.  
Additionally, to put a method in your model to change a data format  
for some customers and not others could be wasteful. It doesn't  
concern the database, and might incur a performance hit due to a  
change in data type, higher in the model would be better, but it  
would also need logic to determine when to show one format, and when  
to show the other. This is again information that should be in the  
session, hence it would make more sense to decide when your session  
is available.

A widget may be reusable in the sense that more than one customer can  
use it, but this should be taken for granted. Reusability should be  
more about using the same widget in more situations. Rules allow you  
to configure widgets so that they can fit more situations. In David's  
example above, three rules about figuring tax would allow you to  
reuse your tax page for three tax situations, and you wouldn't have  
to change the code for the page to add a fourth. That's my definition  
of a reusable widget.

I would argue that without rules, you can't have reusable widget at  
all. If you have an object, say a page view, hard coded to display a  
list of items, it has to be re-written to display a different list.  
That isn't a reusable widget. Now if you can tell it what category of  
items to display when you call it, then its reusable, and the  
configuration information you sent constitutes a rule to me.

Now, I advocate putting all such rules in one place. Separately, I  
advocate giving rules a 'scope' so that you can assign properties to  
more that one widget at a time. I also like the idea of having a  
priority level so that you can have a base of default rules and build  
on them for more and more specific situations. But, a rule, to me, is  
something every OO program uses every time it configures an object.  
I'm not talking about instantiation, but configuration, and they  
don't belong in the model for practical reasons.

justin tocci
Fort Worth, Texas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rawmode.org/pipermail/catalyst/attachments/20050609/2eb29359/attachment.html