[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