[Catalyst] Begginer's question about application structure
redicaps at gmail.com
Mon Nov 22 14:53:00 GMT 2010
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'?
2010/11/22 Martin Bendix <martinbendix at yahoo.co.uk>
> As a Perl and Catalyst novice, I have recently completed the online
> tutorial, and read the Definitive Guide to Catalyst. However, I have a f=
> questions about the basic structure of a thin controller, fat model
> I'd like to take my learning to the next stage by writing a fully
> application, and the classic CD database seems like a good place to start=
> 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=
> 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
> 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
> 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 =
> application functionality should be exposed via the model, so that the
> controller only needs to make simple calls to the model. To do this, mod=
> 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
> As my models will be primarily concerned with accessing the database, how
> 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 =
> DBIx::Class::ResultSet classes that can add new CDs when supplied with
> 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
> to my application. I assume that I should therefore delegate validation =
> model as well, so that the same validation methods can be used no matter
> the interface?
> Are there any good tutorials out there that cover this sort of thing? At
> 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
> source Catalyst applications that I can look at to help me with this? I'=
> a look at MojoMojo, but it's a little too complicated for me at the momen=
> Many thanks,
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> Dev site: http://dev.catalyst.perl.org/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Catalyst