Hi Craig,
On 10/30/2012 12:09 PM, Craig Chant wrote:
> Thanks Ian,
>
> The hierarchy is something that I am finding mind-blowing at the moment,
> "$self->jqgrid->render($self," , you are calling methods jqgrid->render on
> $self, passing in $self, I'm sure it makes sense to you :-)
>
No, he is calling "render" on whatever is returned by $self->jqgrid.
Thats why $self has to be passed to "render". The code above is
equivalent to:
my $jqgrid = $self->jqgrid;
$jqgrid->render($self, ...);
> One thing I would like clarification with if possible.
>
> Where do I put code that requires the use of more than one model?
>
> Do I create a separate model that acts as an interface between the other
> models?
Thats one possibility. Another possibility would be to create a helper
method in Model1, which expects Model2 as a parameter.
Model1.pm:
sub calculate_sth_with_model2{
my ($self, $model2) = @_;
do_crazy_calculations();
}
And in your Controller:
sub calculate :Local :Args(0) {
my ($self, $c) = @_;
my $m1 = $c->model("Model1");
my $m2 = $c->model("Model2");
$m1->calculate_sth_with_model2($m2);
}
>
> You see I have two SQL servers in opposite ends of the country and so I have
> a model built on Model::DBI that can access one server and another Model that
> can access the other, but I have functionality that needs data from both , do
> some calculations and output accordingly.
>
> I assume this does not go in the controller, but I create an interface model
> with the required methods and functionality that the controller uses?
>
> Regards,
>
> Craig.
>
> -----Original Message-----
> From: Ian Docherty [mailto:[email protected]]
> Sent: 30 October 2012 07:22
> To: The elegant MVC web framework
> Subject: Re: [Catalyst] Why is $c undefined?
>
> On 29 October 2012 21:01, Craig Chant <[email protected]> wrote:
> ...
>>
>> I have read and seen frameworks such as Mojolicious encourage a shrinkage of
>> the Model and move alot of functionality to the Controller, so there is a
>> paradigm which seems to imply it is ok to do more stuff in the Controller,
>> but I am leaning towards having the main code in the Model and then bolting
>> it together via the Controller.
>>
> I can understand why you get this impression, I think a lot of people end up
> putting code in the Controller when they first start using MVC (I did so
> myself in the past).
>
> The Model should be external to your Catalyst app (or whatever framework you
> use) so that you can use it in things like cron jobs. It also makes testing
> easier if your Model is separate from your Catalyst app. Look at using
> something like Catalyst::Model::Adaptor as a thin shell to add your external
> Model into Catalyst.
>
> I am moving more and more into making my Controllers as thin as possible.
> Logic that I might have previously put into the Controller, I either put into
> the Model or I create helper functions. Here is an example of a Controller
> (from Mojolicious as it happens but that is not important)
>
> sub user_list {
> my ($self) = @_;
>
> $self->jqgrid->render($self, {
> rs => $self->schema->resultset('User')->search_rs,
> filters => {},
> rows => [qw(id name)],
> });
> }
>
> It's not important to know what is going on here, but this Controller gets a
> list of all users, formats the data for use in the jQuery jqGrid allows for
> sorting and filtering and outputs the data in JSON format. The point being,
> the controller code is kept simple and 'thin'
> and yet it does a lot of work behind the scenes.
>
> _______________________________________________
> List: [email protected]
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/[email protected]/
> Dev site: http://dev.catalyst.perl.org/
> This Email and any attachments contain confidential information and is
> intended solely for the individual to whom it is addressed. If this Email has
> been misdirected, please notify the author as soon as possible. If you are
> not the intended recipient you must not disclose, distribute, copy, print or
> rely on any of the information contained, and all copies must be deleted
> immediately. Whilst we take reasonable steps to try to identify any software
> viruses, any attachments to this e-mail may nevertheless contain viruses,
> which our anti-virus software has failed to identify. You should therefore
> carry out your own anti-virus checks before opening any documents. HomeLoan
> Partnership will not accept any liability for damage caused by computer
> viruses emanating from any attachment or other document supplied with this
> e-mail. HomeLoan Partnership reserves the right to monitor and archive all
> e-mail communications through its network. No representative or employee of
> HomeLoan Partn
ership ha
s the authority to enter into any contract on behalf of HomeLoan Partnership by
email. HomeLoan Partnership is a trading name of H L Partnership Limited,
registered in England and Wales with Registration Number 5011722. Registered
office: 26-34 Old Street, London, EC1V 9QQ. H L Partnership Limited is
authorised and regulated by the Financial Services Authority.
>
> _______________________________________________
> List: [email protected]
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/[email protected]/
> Dev site: http://dev.catalyst.perl.org/
u
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
