[Catalyst] Re: From the beginning...

[Andy Grundman]

LD wrote:
> script/create.pl (which needs a man page!) will allow you to create 
> views, models and controllers separately - great. But the idea of 
> re-usable components is that they are self-contained. So it would be 
> great if script/create.pl allowed the following...
 > ...
 > lib/MyApp/MyComponent.pm
 > lib/MyApp/MyComponent/M/MyComponent.pm
 > lib/MyApp/MyComponent/V/MyComponent.pm
 > lib/MyApp/MyComponent/V/MyComponent.tt
 > lib/MyApp/MyComponent/C/MyComponent.pm

Your entire app might probably only need 1 model and 1 view class, each 
with only a few lines of code.  The model reads your database structure 
and dynamically creates all your database classes/relationships, and the 
view just simply defines how TT will be used.  These things wouldn't 
need to be duplicated in lots of different "components".

The type of class that you will have many of are your controllers.  You 
could fit every action into a single controller, but I prefer to split 
things out in a logical fasion based on what URL it supports.  Cat5 
encourages this by automagically supporting these types of URLs when you 
use a "Local" action.  I'm currently building a little app that manages 
a list of servers and the applications installed on them.  I have a 
structure like this:

MyApp::C::Server (/server/* methods)
MyApp::C::Server::Apps (/server/apps/*)
and so on.

So for example, Catalyst maps the URL /server/apps/view to:
sub view : Local { } within MyApp::C::Server::Apps.  Cat5 has a nice 
ASCII table listing when running in debug mode that displays all of 
these mappings.

Catalyst's directory tree is organized properly IMO.  It is best to 
leave all templates in their own directory (/root) and the controllers 
under /lib.  This lets non-developers work on HTML/TT without having to 
wade through Perl code in nearby files.  Of course, I've never worked 
anywhere that has separate HTML people working this way, but it sounds 
good in theory. :)

> ./script/create/.pl component MyComponent [ parentComponent ]
> ./script/create/.pl component MyComponent [CDBI ...] [TT] [C 
> parentController]

The concept of inheritable controllers is a good one, and while it is 
not mentioned, you can already do this.  In fact, my app takes advantage 
of this to allow the Apps class to access a utility method in the 
Servers class:

MyApp/C/Server.pm:
sub _setServerData {
   # set some stash variables common to all servers
}

MyApp/C/Servers/Apps.pm:
use base 'MyApp::C::Server';
...
$self->_setServerData(...);

The create.pl helper could certainly add that to the list of things it 
can build for you.

I have worked with a legacy WO app before, but only in a "hope it keeps 
running" mode and have never done development with it.  I was 
immediately turned off by WO when I saw the horrid obfuscated URL scheme 
they use.  That, and the fact that I can't stand Java. ;)

--
Andy Grundman