On 24 Sep 2008, at 00:34, Dr. Jennifer Nussbaum wrote:
Thanks. I do appreciate this, and its a neat solution, but the
problem wasnt that i dont know how to put common elements in a base
problem is that nowhere in the Cat docs, formal or informal, are
there any examples of doing searches with web apps.
You're making the assumption here that Catalyst and DBIx::Class are
the same thing. I'm not actually a DBIx::Class user myself, and there
are plenty of people who aren't using it..
In practice i tend to have more complicated apps, with difficult
queries, that i do abstract out the query building, and then things
throw together in a few minutes where everythings a mess. Usually
when im just throwing things together, i forget about best
practices and want
to look them up.
However, here you have a good point.
One of the main strengths of Catalyst is that it's so easy to combine
it with whatever set of other technologies you're using - but that
doesn't mean that the documentation or community currently does the
right thing by newer users who are confused by the level/number of
choices open to them.. Also, having made a choice - there is little
documentation about the common / recommended patterns and practices
for combining various components in a non-trivial manor.
It would be fantastic if there were more higher level documentation
about the available components, and when/why you would want to employ
them, combined with a lot more in-depth documentation about patterns
and practices for combining Catalyst with a particular model /
component to form a non-trivial application, accompanied by annotated
demo applications showing the features/patterns in use.
A lot of this knowledge is already buried in Catalyst applications
(for example MojoMojo and Angerwhale both make pretty good reading,
and if you're feeling like you need your brain stretched, Reaction
will certainly do that) - however developing and maintaining
comprehensive documentation / annotated commentary is non-trivial in
itself, keeping it in pace with the applications themselves is
probably a non-starter. Extracting enough of the complexity to show
the patterns to good use into a demo application (and then
maintaining said application) is also nontrivial undertaking. This
isn't any criticism to the Catalyst documentation team - I think that
the docs we do have are great, and well maintained in line with
Another key problem is that it's also extremely hard for people who
are familiar with the code bases in question to write good
documentation - you can only do that as you're learning.
My recommendation to anyone trying Catalyst for the first time, or
trying a new piece of software with Catalyst / trying to find
patterns or examples of prior art would be that once you've been
through the available documentation on CPAN and the wiki, had a play,
and formed your problem domain in your head, is to pop by irc -
#catalyst is one of the most helpful channels I've ever been in, and
whilst the inhabitants can be brusque, I see people wander by and
take great advice away daily. (Note, as you're using DBIx::Class,
they're likely to send you to #dbic). People there will also have no
problem with deconstructing the specific problem you're trying to
solve back to your problem domain, finding the higher level problem,
and then telling you that you're solving it in a non-optimum way (and
the approach they recommend for solving it).
If everyone who came into irc and was helped were to spend the same
time people had donated to helping them in writing up the help /
knowledge they'd just received on the wiki, then all the things which
I dismissed as 'nontrivial' above, would suddenly become possible.
Some dream eh?
P.S. Come ask about what you want in #catalyst / #dbic and get it
written up on the catalyst wiki, plzkthnx?