Matthew Pitts (m...@a3its.com)

I've been working on some new projects that have pulled me away from my
Catalyst/Perl duties and, as a result, we're seeking a direct hire
contractor that can help us support a couple of Catalyst apps and a
legacy CGI app. See the job posting at http://jobs.perl.org/job/8822 for
more info. We're hoping to find someone in the North Carolina area
(Greensboro, specifically), but any Cata-listers will be given strong
consideration.



My thanks to all of those folks that keep the non-reinvented wheel
spinning.



v/r



-matt pitts

I've been using Perl for many years with the last two being professional
and I'm just now becoming somewhat aware of what the "enlightened"
libraries are. I stumble in this area a lot.

A book into this area as a whole would be very nice.

v/r

-matt pitts

I never met a "matt" I didn't like :)

I had thought for awhile that it was generic enough to be useful to
others, but just hadn't spent the time to publish it.

Let me talk to my boss about committing it publically - he and I are the
only FOSS lovers in an M$ Gold certified shop :). Makes for interesting
office talk.

v/r

-matt pitts

Unless one is specifically looking to white-label an app, different
functionality across different domains means "two apps" to me. What
happens when domain1.com gets bought out and they want to rebrand, or
worse just a tarball of all the code behind their site? Yucky stuff if
you're running in the 'same app' as domain2.com.

> You're making a valid design point, but then jumping from there to an
> invalid one by ... well, handwaving so far as I can see.

I would add the caveat that if the two domains are for the same client
or are *completely* internal to my company, then I'd consider running it
as "one app". Otherwise, I'd rather maintain two separate apps and some
common Models than do a lot of dispatch kludging to provide different
functionality.

v/r
-matt pitts

functionality.
> > The
> > > meat of the app should be in the Models, then you can just run
> > multiple
> > > Cat apps - one with Cart controllers and one without - that use
the
> > > same
> > > "shared" Models.
>
> Absolutely right, my controllers are much, much too heavy. This all
> came
> from "learning as I went" and I distinctly remember the point at which
> I
> gave up trying to put business logic in the model. At the time there
> seemed to be minimal if any examples that illustrated the model being
> anything other than an adaptor for DBIx::Class::Schema so I just
> figured
> I was mistaken in my attempt to do so.
>
> So could I ask, now I know a little more than I did then, Does
everyone
> here subclass DBIx::Class::Resultset (a-la
> http://catalyst.perl.org/calendar/2007/16) for their business logic
> specific methods? (Well those that use DBIx::Class as their model
> anyway)
>
> Thanks for the Help Matt, it's certainly made me think.

You're very welcome.

As far as DBIC goes, yes I subclass DBIC::RS - actually I've built out a
common DBIC "library" that I use in my DBIC models that provides common
base classes for DBIC and DBIC::ResultSet, and a standard set of
Exceptions. The library provides come really common filtering facilities
for my apps like "active" flag and "valid_from"/"valid_to" date ranges
for records.

I then use a custom ResultSet class via __PACKAGE__->resultset_class
(that subclasses the library's base RS class) in almost everyone of my
DBIC classes, because eventually I come to a point when I need to
implement custom RS methods.

Something like...

package MyCustomer::Schema::Cart;
use base qw/ MyCompany::DBIC::Base /;

...

__PACKAGE__->resultset_class('MyCustomer::Schema::CartRS');


...

1;

package MyCustomer::Schema::CartRS;
use base qw/ MyCompany::DBIC::ResultSet /;

...

1;

v/r
-matt pitts