On 6/8/07, <b class="gmail_sendername">Guy Debord</b> <<a href="mailto:situationist@gmail.com">situationist@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So is this not a good option if I want specific logic in Model::Foo but not Model::Bar ( I can't even create these without breaking ) <div><br></div><div>This seems to run contrary to my reading of the documentation and tutorials, etc.
</div><div><br></div></blockquote></div><br><br clear="all">Hi Guy,<br>
<br>
I think that a diagram of how things are encapsulated would probably be of assistance. Sorry if I'm covering stuff you already know, just want to make sure everything is thoroughly laid out.<br><br>First, it's important to know how things work outside of Catalyst. The DBIC classes you have can be used just like $schema->resultset('TableName'), where $schema is (as I can see) a "TMP::Schema" object.
<br><br>The DBIC::Schema helpers basically create a short-hand for you to access "TableName", but they make you use some prefix. This is really useful if you have a model in your app called "User" but you also have a schema class (a database table) named "User"
<br><br>As an example, something like this:<br> $c->model("User"); # Just some other model class<br> $c->model("DB::User"); # A DBIC class resultset, equivalent to doing $schema->resultset('User')
<br><br>So, just think that when you are doing "$c->model("DB::SomeTable")" you're doing the equivalent of $schema->resultset("SomeTable"); And, as such, $c->model("DB") would be somewhat analogous to returning the $schema object -- except it doesn't, because that gets shoved off behind the scenes, and Model::DBIC::Schema creates a map between the ->resultset("TableName") and model("DB::TableName") automatically, so you shouldn't need the $schema object to get at the result sets.
<br><br>The prefix there ("DB::") is configurable via the helper scripts, but is very important (both for the reason I listed above w/ having other model classes) and the way that Catalyst::Model::DBIC imports your schema classes into your Catalyst application.
<br><br>The syntax that Matt posted:<br>script/tmp_create.pl model DB DBIC::Schema TMP::Schema<br><br>Breaks down like this:<br>You're creating (tmp_create.pl) a model, with a prefix of "DB" that inherits from "DBIC::Schema" and will use Helper::DBIC::Schema to generate the code.
<br><br>The arguments beyond there ("TMP::Schema") are instructive to Helper::DBIC::Schema to know what to map against.<br><br>Helper::DBIC::Schema then creates a map of the prefix ("DB") to "TMP::Schema".
<br><br>You're on the right track though, and what you said in the original post about it getting "ugly" as the app grows I suppose is just a matter of perspective. You can always run without debugging enabled so you don't see how things get dumped out. But, it's all just information for you to look at. Even without the ("DB::") prefix (or "Foo::" as you have in your example) you'd still have to load each and every schema class into Catalyst so that ->model(...) knows what to work with.
<br><br>Hope this helps clear things up,<br>-Jay<br><br>-- <br>J. Shirley :: <a href="mailto:jshirley@gmail.com">jshirley@gmail.com</a> :: Killing two stones with one bird...<br><a href="http://www.toeat.com">http://www.toeat.com
</a>