[Catalyst] Begginer's question about application structure

[woosley. xu.]

Personally, as a novice too ^^, I like to keep the Model code clean enough,
not to include too much functions like parameters check, which we can just
create a controller action to accomplish.

I got similar questions though: Some common functions, like date
manipulation/formate, what is the popular way to do that in Catalyst? Do we
use  $c->forward('date_manip') or we just call date_manip() to do that?
If the latter one is recommended, so can I conclude it is very common to add
some Modules that don't need to 'extend Catalyst'?


Thanks


2010/11/22 Martin Bendix <martinbendix at yahoo.co.uk>

> Hi,
>
> As a Perl and Catalyst novice, I have recently completed the online
> Catalyst
> tutorial, and read the Definitive Guide to Catalyst.  However, I have a f=
ew
> questions about the basic structure of a thin controller, fat model
> application.
>
> I'd like to take my learning to the next stage by writing a fully
> functioning
> application, and the classic CD database seems like a good place to start=
 -
> it
> will at least be of use to me when it's done.
>
> Given the following basic criteria, I would be grateful for some high-lev=
el
> advice on how best to organise the application:
>
> * I will be using DBIx::Class to access the database.
> * At first, the initial user interface will be web based.
> * I'd like to structure the application so that I can add additional
> interfaces
> with relative ease in future (e.g., command line, web services, etc.).
> * I'd like to create test scripts for as many of the modules/application
> functions as possible.
> * The application will provide the ability to create, search, update and
> delete
> artists, tracks, and CDs.
>
> I think that my understanding of the following is correct, but I would
> appreciate any advice or pointers:
>
> My model should be well separated from the controller.  Most, if not all =
of
> the
> application functionality should be exposed via the model, so that the
> Catalyst
> controller only needs to make simple calls to the model.  To do this, mod=
el
> classes should be created in 'lib/myapp', with simple adapters in
> 'lib/myapp/Model', using Catalyst::Model::Adaptor.
>
> At this point, I am a little less clear on how best to structure my
> application.
>
> As my models will be primarily concerned with accessing the database, how
> much
> database code should go in my model classes, and how much in the
> DBIx::Class::ResultSet classes?  For example, should I write a method in =
my
> DBIx::Class::ResultSet classes that can add new CDs when supplied with
> title,
> artist and a track list?  Or would it be better to put this in my model?
>
> Data validation could be handled by HTML::FormHandler, but any validation
> performed here won't be of much use if I later provide an alternative
> interface
> to my application.  I assume that I should therefore delegate validation =
to
> my
> model as well, so that the same validation methods can be used no matter
> what
> the interface?
>
> Are there any good tutorials out there that cover this sort of thing?  At
> the
> moment, I'm more interested in best practices for structuring a Catalyst
> application than in the details of the code itself.  Are there any good
> open
> source Catalyst applications that I can look at to help me with this?  I'=
ve
> had
> a look at MojoMojo, but it's a little too complicated for me at the momen=
t.
>
>
> Many thanks,
>
> Martin
>
>
>
>
> _______________________________________________
> 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/
>



-- =

Woosley.Xu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20101122/6682e=
994/attachment.htm