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? > 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? > 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. > 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 _______________________________________________ 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/
