--- Rob Kinyon <[EMAIL PROTECTED]> wrote:
> On 7/29/07, John Napiorkowski <[EMAIL PROTECTED]>
> wrote:
> > I think the main idea is to push stuff into a
> > configuration file when it's not code that doing
> > logical work. This way I can push down some
> simple
> > maintenance work to admins. Also I've been
> playing
> > with MooseX::IOC lately and thinking about what
> makes
> > sense to push into a configuration for the
> purposes of
> > being able to manage my applications more easily.
>
> I used to work with Stevan on the application that
> spawned the
> original IOC, so I've seen several apps which were
> fully IOC'ed.
> Frankly, they're ugly and hard to work with. The
> problem isn't when
> you're dealing with several cookie-cutter
> applications. IOC is an
> adequate, if naive, solution to that type of
> problem. The problem is
> when you want to tweak things. You either end up
> tweaking in your IOC
> conf files (code in conf BAD!) or you have
> situations where you have a
> file that just has tweaks to code that is
> auto-generated. This is
> really really bad for people who don't work on that
> auto-generated
> code day-in-day-out.
>
> A better solution for cookie-cutter apps is to treat
> the differences
> as configuration and run off the same code - just
> because your
> application has a different userland name doesn't
> mean that the code
> files need to have different classnames. So, if you
> truly have
> cookie-cutter tables, then use the same tables, just
> in different
> databases. Identically-structured databases for
> different applications
> isn't a bad thing. If you have different tables for
> storing different
> kinds of information, then what are you doing trying
> to put your
> schema into a conf file?
I think the idea that woke me up a few night ago was
more about thinking of ways to reduce the amount of
purely declarative code in my apps. That's what lead
me to think about auto instantiating class files from
a configuration file. I'm less in love with the idea
now, although I am going to try and cut out some time
to gather my thoughts on the SQL:T backend module that
was mentioned earlier in the thread.
Using IOC is definitely spawning a lot of glue code
for me, but right now I feel okay with it. I can see
your
point about it potentially getting messy. Right now I
have all my IOC registry and container stuff in perl
modules and use module find to bring them all
together. I'll finish this app and see what it
bought me, if anything useful. MooseX::IOC just made
it too easy to try out :) Hopefully I'll get some
time to write up the app and then I will look forward
to comments and criticisms.
>
> > To be honest I'm on the wall with this particular
> > idea, which is why I thought to ask the group for
> > thoughts.
> >
> > I have a similar idea which honestly makes more
> sense
> > to me, which is to have a quick system to call
> > $schema->populate against a configuration file.
> This
> > is actually quite easy to do, particularly now
> with
> > the new multi create logic. Then my database
> deploy
> > scripts and tests can be easy to configure.
>
> You want fixtures here. I've got a poor-man's
> fixtures cribbed from
> Ruby's ActiveRecord stuff - I could throw it to the
> list and someone
> take it and fold it in. Anyone interested?
I am :)
>
> > Another thing I was thinking this would make
> easier is
> > that the configuration files would be a little
> more
> > portable for different applications. I already
> have
> > several apps with a basic membership system which
> I
> > typically just copy the classes. Of course then I
> > have to edit them to change the package names. I
> > guess you could just as easily do this with a Perl
> one
> > liner so maybe that's not a particularly strong
> use
> > case either.
>
> See above - use the same classes against the same
> schema - just point
> at different databases.
Yeah, I see the light with this now :)
>
> > There's been a push at my current job to move more
> > stuff into configuration and out of code.
> Sometimes
> > it makes sense, other times it doesn't.
>
> Schema should never be in conf. Configuration is
> what differs between
> app instance A and app instance B. That's things
> like directory roots
> and database user/pass. Unless, of course, you're
> treating DBIC as
> purely a DBI overlay and not a true model. In which
> case, you're just
> going to ignore me (and rightly so). :-)
>
> Rob
I doubt I'd ignore you thought even if I didn't see
the immediate application. For me DBIC is the primary
model in my applications. The only thing I have in
conf for Schema is the connect string info and
sometimes the list of classes to pass to load classes,
or settings for result and resultset namespaces. I
think that seems okay, that way I don't have to
subclass for each application that needs a schema.
--john
____________________________________________________________________________________
Shape Yahoo! in your own image. Join our Network Research Panel today!
http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
Wiki: http://dbix-class.shadowcatsystems.co.uk/
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
Searchable Archive: http://www.mail-archive.com/dbix-class@lists.rawmode.org/
