Mailing List Archive

Am 13.04.2005 um 01:11 schrieb LD:
> Anyway, I'm wondering about deployment. I've installed Catalyst
> 4.34... (but seeing as version 5 is looking near done from the mailing
> list posts I've seen - I think I'd like to start with it... how?)

Only on svn actually...

>
> The ISP my company uses supports perl, but I'd guess that not many
> ISPs will have Bundle::Catalyst installed. I'm developing on Mac OS X
> 10.3 and after 'install Bundle::Catalyst' it's found at
> /Library/Perl/5.8.1/Catalyst/ but naturally some of its dependencies
> will be elsewhere.
>
> So what I'm hoping is that someone might have (or if not be able to
> suggest) a script that builds a self contained directory containing
> the catalyst app and the necessary dependencies (analogous to creating
> a SSDD [Servlet Single Directory Deployment] project in WebObjects for
> J2EE integration).
>

We've planned PAR support, but actually there are many other things
todo. Maybe someone wants to take that task? :)

> On a side note - is anyone working on documentation? It would be a
> shame for a seemingly great project to miss that mark. I'm thinking of
> writing up a tutorial similar to the WebObjects Web Applications intro
> tutorial once I get my head around a few more things.

perldoc Catalyst::Manual
perldoc Catalyst::Manual::Intro

contributions very welcome!

--
sebastian

Hi again,

On 13/04/2005, at 9:11 AM, LD wrote:

> Coming from WebObjects, which is heavily architected around MVC,
> Catalyst appeals to me. I don't yet know enough about Catalyst to
> really compare the two, no thanks to the sparse Docs. So, one's free
> and been around for a short time with little info; the other's
> relatively inexpensive, is tried and tested and has relatively good
> docs - will have to do for now :-)

Actually there is one thing I've noticed with Catalyst (at least with
v.4.x as I haven't seen v.5 nor been on the mailing list for more than
a few days) that could be improved and it has to do with re-usable
components. Now I've seen that this is being enhanced with v.5 but have
no idea in what way so if this has been done, great.

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...

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

...which rather than creating:
lib/MyApp/M/MyComponent.pm
lib/MyApp/V/MyComponent.pm
lib/MyApp/C/MyComponent.pm

...instead creates:
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

Note: I've put MyComponent.tt in with the View as I think it would be a
good idea to encapsulate the template.tt files in this structure so
that the component is completely self contained (like an object with
its methods providing access to the data).

With such a set up creating sub-components or utilising the components
behaviour elsewhere becomes more manageable, no?

Any thoughts on this and how v.5 compares?

Thanks,
LD

Am 13.04.2005 um 01:52 schrieb LD:

> Any thoughts on this and how v.5 compares?

Well, the built in helpers are again just examples and quite limited,
writing your own helpers is very simple.

package Catalyst::Helper::FooBar;

# mk_stuff will be called from the helper system
sub mk_stuff {
my ($class, $helper, $arg1, $arg2, $arg3) = @_;
# make stuff :)
}


% script/create.pl FooBar arg1 arg2 arg3

--
sebastian

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

LD wrote:

> Hi all,
>
> I've just recently discovered Catalyst, stumbling over it by accident
> actually, whilst looking through the Docs for Class::DBI.
>
> Coming from WebObjects, which is heavily architected around MVC,
> Catalyst appeals to me. I don't yet know enough about Catalyst to
> really compare the two, no thanks to the sparse Docs. So, one's free
> and been around for a short time with little info; the other's
> relatively inexpensive, is tried and tested and has relatively good
> docs - will have to do for now :-)


>
> ...
>
> On a side note - is anyone working on documentation? It would be a
> shame for a seemingly great project to miss that mark. I'm thinking of
> writing up a tutorial similar to the WebObjects Web Applications intro
> tutorial once I get my head around a few more things.
>
I put together the start of a tutorial (its in the Cat5 subversion
repository). I want to try and tidy up and expand the documentation.
If you or anyone else has ideas or suggestions for additions to the
documentation, especially the Catalyst::Manual::XXX pages, then CC me on
any mails and I will try to work them into the documentaion.

Andrew

--

Andrew Ford, Director Pauntley Prints / Ford & Mason Ltd
A.Ford@ford-mason.co.uk South Wing Compton House
pauntley-prints.co.uk Compton Green, Redmarley Tel: +44 1531 829900
ford-mason.co.uk Gloucester GL19 3JB Fax: +44 1531 829901
refcards.com cronolog.org Great Britain Mobile: +44 7785 258278