[Catalyst] Is Catalyst large enough to sustain a book?

Len Jaffe lenjaffe at jaffesystems.com
Fri Apr 28 19:20:12 CEST 2006



--- Nilson Santos Figueiredo Junior <acid06 at gmail.com>
wrote:

> On 4/28/06, Yuval Kogman <nothingmuch at woobling.org>
> wrote:
> > That's DBIC's job - while it can be coverred e.g.
> under a hybrid
> > Catalyst and DBIx::Class book, a Catalyst book on
> it's own should
> > not really consider this a show stopper.
> 
> You see, that's one of the issues. Frameworks should
> be consistent. A
> Catalyst book should adhere to a single ORM. Of
> course it should also
> state that Catalyst is flexible and that other ORMs
> are available,
> etc.

I think that part of the attraction of RoR, (and to an
extent Django, and Turbo Gears) is the fact that it
provides for their users, the one true ORM and
templating package. RoR goes beyond this and holds the
developers hand with naming conventions every place
possible.  I think that NOT having to make many of
these decision is part of what is attractive to the
lay person.

If railscoder is at all represntative, people are
flocking to RoR because of the all of the things they
don't have to know to be moving forward quickly.

If there's one raisl way to to ORM, and templating,
then you have book fodder.

Catalyst is a frame work. We get configuration, param
parsing, dispatch and plug-ins.  We have to choose our
ORM, and view engine.

So there's a Rails way to do it, and there's more than
one way to do it in Catalyst. Which do you write
about?

Three Model chapters? DBIC, CDBI, and Vanilla BDI.
How many View Chapters? TT, Mason, HTML::Widget?

Interesting exercise. Design an application, build
three models, show the differences in developer
effort, and maintenance effort between the model
choices.
Likewise with the views. Which develops faster? Which
is easier to maintain? Which runs faster?  Discus the
balancing act.

But, you know, since Catalyst is Model and View
agnostic, chapters that do more than discuss how
Catalyst interacts with its models and views, aren't
talking about Catalyst anymore. but you can't write a
book about MVC with out concrete examples of models
and views.

We're left, with the decision of covering multiple
views and models, and declaring this the catalyst way,
and trying to convince people that making decisions
that they are ill equipped to make is a good thing, or
writing a book like "Catalyst applications with
Template Toolkit and DBIx::Class, using FastCGI on
Apache 2" and preaching One True Path to Catalyst.

There's probabaly a middle ground, something like
"Catalyst and DBIC" with digressions about deployment,
and views.

Not for nothing, I'd be using RoR myself but for a
ruby/mysql connectivity bug on win32 that the ruby
community doesn't seem in a hurry to fix. But there's
some instructions on how to recompile one library to
fix the problem, I might try that now that I have a
compiler.

On the other hand, I'm about to attempt my upteenth
try at getting Catalyst and all its supporting modules
inatlled on my notebook.

I have a clean reinstall of Activeperl 5.8.7, I've got
nmake, and dev-c++. I'm going to get Matt's install
script and give it another go. maybe tonight, maybe
tomorrow.  So far, I have one clean install, on
Solaris.  My linix installs have all been a little
squirrely, and I could never get windows to install
everything I wanted. Something always won't come in
from CPAN, something fails to compile, or returns a
string that the test script wasn't looking for. For
exmaple I could have Static, but not Static::Simple.

Sorry for the whine-fest.  I feel better now.

Len.



More information about the Catalyst mailing list