Marcello Romani wrote:
In MyApp/Model I usually have only MyAppDB.pm, which role is to expose
the DBIC::Schema classes under MyAppDB/ as a catalyst model.
This doesn't mean however that "I would never create anything" else. If
all I need is one dbic schema, then the answer to your question is "yes".
On the other hand, if I need for example to access two databases, then I
could have another dbic-schema folder (e.g. lib/MyAppDB2) and another
model class (lib/MyApp/Model/MyAppDB2.pm) to expose it to cat like the
first one.
Or I could have some other type of data that don't live in a database or
that I can't/don't want to access via dibc-class. In this case I could
write some classes under lib/MyApp/Model that directly access that data,
or better yet, have a set of classes (not tied to Catalyst) that deal
with the data and expose them as a cat model via one or more wrapper
class(es) (e.g. lib/MyApp/Model/ExtData.pm).
Thanks, Marcello. I think I'm beginning to understand.
The thing I was missing was that everything under Model/, View/,
and Controller/ is (relatively) tightly coupled to Catalyst itself.
So if you want a general "model" class, you don't want it in the
Catalyst Model/ directory.
I'm now trying to extend the tutorial by designing a User class, and
I'm rearranging lib/ to what seems most intuitive to me. Criticisms
appreciated.
Here's my thoughts.
The project directory is intended to hold the entire project. So
I'm expecting pretty much all of the Perl modules particular to it
to live under lib/
So as not to collide with namespaces on CPAN, we want to prefix most
everything with the project name (I'm using Try in this example).
For a generic user class, I'd therefore expect it to live in
lib/Try/User.pm
Here's the hierarchy I have currently:
$ find ./lib
./lib
./lib/Try
./lib/Try/Model
./lib/Try/Model/DB.pm
./lib/Try/View
./lib/Try/View/TT.pm
./lib/Try/Controller
./lib/Try/Controller/Root.pm
./lib/Try/Controller/Users.pm
./lib/Try/DB.pm
./lib/Try/User.pm
./lib/Try.pm
But I'm thinking a better layout would be:
/lib
./lib/Try
./lib/Try/Catalyst/Model
./lib/Try/Catalyst/Model/DB.pm
./lib/Try/Catalyst/View
./lib/Try/Catalyst/View/TT.pm
./lib/Try/Catalyst/Controller
./lib/Try/Catalyst/Controller/Root.pm
./lib/Try/Catalyst/Controller/Users.pm
./lib/Try/DB.pm
./lib/Try/User.pm
./lib/Try.pm
That makes the relationship between M/V/C and Catalyst explicit, and
leaves the rest of the namespace available for generic use.
Any thoughts?
What layouts are you folks using for large-scale projects?
Thanks,
Maurice
_______________________________________________
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
