[Catalyst] Refactoring question

Thu May 27 13:18:35 GMT 2010

Oops, sorry ; I accidentally hit =AB send =BB too fast  !

 =

Since you=92re using DBIC, I suggest you take a look at the cat tutorial
section on CPAN about =93exploring the power of DBIC=94  : =

 =

http://search.cpan.org/~hkclark/Catalyst-Manual-5.8004/lib/Catalyst/Manual/T
utorial/04_BasicCRUD.pod#EXPLORING_THE_POWER_OF_DBIC

 =

You=92ll learn how to create your own resultset  classes, thus allowing you=
 to
use clean & concise method calls in your controllers, instead of ever
growing DBIC queries.

 =

If you were to use your other (non dbic) classes as catalyst model, I would
suggest you use Catalyst ::Model ::Adaptor,

Which allows you to do things like =

 =

package MyApp::Model::SomeClass;

use base 'Catalyst::Model::Adaptor';

 =

__PACKAGE__->config( =

            class =3D> 'NotMyApp::SomeClass',

            args =3D> { foo =3D> bar },

);

 =

Which I, for one, find to be pretty neat.

 =

http://search.cpan.org/~bobtfish/Catalyst-Model-Adaptor-0.08/lib/Catalyst/Mo
del/Adaptor.pm

 =

Have fun J

 =

Regards, =

 =

Morad IGMIR

 =

 =

De : Morad IGMIR [mailto:migmir at alliancemca.com] =

Envoy=E9 : jeudi 27 mai 2010 15:00
=C0 : 'The elegant MVC web framework'
Objet : RE: [Catalyst] Refactoring question

 =

 =

If you=92re using DBIC, =

 =

 =

De : Steve [mailto:steve at matsch.com] =

Envoy=E9 : jeudi 27 mai 2010 14:38
=C0 : The elegant MVC web framework
Objet : Re: [Catalyst] Refactoring question

 =

On 5/27/2010 3:51 AM, Morad IGMIR wrote: =

Hello Steve,
 =

I think your business logic should be moved to the model, not the
controller.
The model does the heavy lifting.
  =

My model is currently comprised only of my DBIC Result and ResultSet
classes.  Are you suggesting that some of the logic in my controllers should
be moved into my DBIC classes, or should I create new Moose classes.  If
Moose, how do I 'hook up' those classes to Catalyst?

 =

Your controllers would be easier to maintain if they only did simple tasks
like
dispatching, calling models and forwarding to views,  as said on the
catalyst wiki : =

 =

"Decouple as much as possible. If you have to fire up your web application
in order to test database insertion, that's wrong. Build the model so that
you can use Perl one liners to manipulate data through it."
 =

http://wiki.catalystframework.org/wiki/best_practices#Follow_the_Catalyst_di
et:_thin_controller.2C_fat_model.
 =

I know it's easier said than done when you've spent time building huge
controllers,
but it really pays off.
  =

Your comments are appreciated, as I'd like to learn some lessons before
moving on to my next application, which is going to be much more involved.

Thanks!

 =

Regards,
 =

Morad IGMIR
 =

-----Message d'origine-----
De : Steve [mailto:steve at matsch.com] =

Envoy=E9 : mercredi 26 mai 2010 22:39
=C0 : The elegant MVC web framework
Objet : [Catalyst] Refactoring question
 =

Hi all,
 =

I'm searching for general advice on Catalyst app design.  I've been studying
all the banter on this list for almost a year, and have finally gotten to
the point where a real live application is underway.  Being a newcomer to
web dev in general, and also that this application wasn't originally
supposed to go into production, I didn't give app design much of a thought
(controllers in particular).
 =

The app I'm writing generates HTML invoices/statements for individual
subscribers.  The database consists only of 4 tables: users, roles,
user_roles, and invoice_data.  Don't laugh too hard, but I called my first
controller 'WebUsers', and a second one 'ViewStmt'.  The authentication is
remarkably similar to the examples I've seen :)  As you might imagine, the
WebUsers controller is starting to bloat as it has to maintain users, log
them in/out, and basically handle all the 'heavy-lifting' for the
application.  The ViewStmt controller basically handles the rendering of a
statement, and is quite manageable.
 =

There are only two roles: administrator, and individual.  Individuals can
log in/out, and view their own statements - period.  Administrators on the
other hand need to administer the users, so basic CRUD for that part.  They
also can view statements for anyone, so I've got a nifty list that gets
presented, and links to individual statements.  All of the logic for
handling this functionality is in the WebUsers controller.
 =

I'm wondering if I should refactor all of the user maintenance stuff out of
WebUsers, and into its own controller, or just deal with it as * this
application won't ever be expanded on * .
 =

Thoughts, advice, wise-cracks are all welcome :-[
 =

Ce message entrant est certifi=E9 sans virus connu.
Analyse effectu=E9e par AVG - www.avg.fr
Version: 9.0.819 / Base de donn=E9es virale: 271.1.1/2880 - Date: 05/26/10
08:25:00
 =

 =

_______________________________________________
List: Catalyst at lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
 =

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100527/79bca=
f46/attachment.htm