mla ha scritto:
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/
This seems a good approach to me (with the s/Catalyst/Web/g patch).
Thanks for the suggestion.
--
Marcello Romani
Responsabile IT
Ottotecnica s.r.l.
http://www.ottotecnica.com
_______________________________________________
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/
