[Catalyst] Getting Started

Marcello m.romani at spinsoft.it
Mon Aug 8 11:35:24 CEST 2005


Christopher H. Laco ha scritto:
> David Storrs wrote:
> 
>>
>> On Aug 5, 2005, at 4:06 PM, Christopher H. Laco wrote:
>>
>>> First, is it a correct assumption to make that the interaction  
>>> between Model and View is just a matter of the Controller stuffing  
>>> things into the stash?
>>
>>
>>
>> It is just a question of SOMETHING stuffing things in the stash.   
>> What does the stuffing is open to question...there was a long thread  
>> on this recently.  It is summarized briefly here:
>>
>>     http://dev.catalyst.perl.org/wiki/NecessaryBackgroundKnowledge
>>
>> along with a bunch of other information that should help you out.
>>
>>> Lastly, [trying to get a mental handle on whatcodes goes where in a  
>>> conversion], is it really just a matter of moving all of the non  
>>> presentation logic of the TT based site (cookie reads/writes, form  
>>> posts, redirects) into a Controller and leaving the presentation  
>>> code in the templates?
>>
>>
>>
>> Mostly.  As with everything, it can be argued in multiple ways.   
>> Here's how I do it:
>>
>> - Presentation logic is mostly in the templates
>> - Views mostly just set which template to display
>> - Models are a thin wrapper over the database
>> - Controllers manage the business logic
>>
>>
>> --Dks
>>
>>
> 
> What about things (data) that are needed for every page on a site, like 
> cart count for example. It would seem that the easiest way would be to 
> make a plugin instead of having every controller set a count in its sub.
> 
> Is there some sort of guideline of when things need to be plugins vs. 
> Models?

Plugins add functionality to the framework, models encapsulate the logic 
for retrieving/modifying the data (IMHO).

If you need something displayed across every page, I think you should 
put it in a 'header' template and have your app's View setup to always 
include it. Like this:

package MyApp::V::TT;
use base 'Catalyst::View::TT';
use strict;
use warnings;
sub new {
         my $self = shift;
         $self->config->{PRE_PROCESS} = "header";
         $self->config->{POST_PROCESS} = "footer";
         $self->config->{TRIM} = 1;
         return $self->SUPER::new(@_);
}
1;

In this header you could have code that calls the "global" controller, 
or, perhapse better, displays the "global" properties set by the global 
controller called in the end() method (as per Adam's suggestion).

> 
> -=Chris
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Catalyst mailing list
> Catalyst at lists.rawmode.org
> http://lists.rawmode.org/mailman/listinfo/catalyst

HTH

Marcello



More information about the Catalyst mailing list