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
mla ha scritto:
I just finished getting the tutorial project working.
The thing I'm not clear on is this separation between lib/MyAppDB/
and lib/MyApp/Model/
The tutorial says:
With Catalyst::Model::DBIC::Schema you essentially end up with two sets
of model classes (only one of which you
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
lib/MyAppDB is where you define your schema (your relations etc.) and
lib/MyAppDB/Model is where you'd use them.
The latest long discussion on where your model should be is basically if
your model is only fixed to the web application (blog etc), whack your model in
lib/MyAppDB/Model. If,
On Mon, May 14, 2007 at 06:22:36PM -0700, mla wrote:
All the real models live in lib/MyAppDB? And if I wanted to use a
model *outside* catalyst, I'd use MyAppDB::Book, but within
catalyst it would be MyApp::Book?
well, $c-model('MyApp::Book') if your DBIC::Schema was Model::MyApp.
Is this
Anthony Gardner wrote:
Have a look at this for another angle
http://www.teambarry.com/?p=38
Ah, I like this approach very much.
It says:
So how do you get some of the advantages of ORM and keep control over
SQL? I employ composition and a couple basic design patterns. For
example, I have
On Tue, May 15, 2007 at 01:19:53AM -0700, mla wrote:
So how do you get some of the advantages of ORM and keep control over
SQL? I employ composition and a couple basic design patterns. For
example, I have a base model factory interface that uses chainable
“Loader” modules (ie, DBILoader,
On Tue, May 15, 2007 at 12:10:15AM -0700, mla wrote:
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
Matt S Trout wrote:
On Tue, May 15, 2007 at 12:10:15AM -0700, mla wrote:
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
Matt S Trout wrote:
On Tue, May 15, 2007 at 01:19:53AM -0700, mla wrote:
So how do you get some of the advantages of ORM and keep control over
SQL? I employ composition and a couple basic design patterns. For
example, I have a base model factory interface that uses chainable
“Loader” modules
On Tue, May 15, 2007 at 03:47:57AM -0700, mla wrote:
I find the Rails ActiveRecord interface pretty appealing:
http://ar.rubyonrails.com/classes/ActiveRecord/Base.html
DBIC's interface is not dissimilar although it favours data structures
for query descriptions rather than raw SQL.
I
On Tue, May 15, 2007 at 01:24:17PM +0100, Matt S Trout wrote:
On Tue, May 15, 2007 at 03:47:57AM -0700, mla wrote:
I like how if you fetch columns that don't exist in the table
the object becomes read-only by default.
That's neat, although I prefer tools that presume I know that I'm doing.
--- Matt S Trout [EMAIL PROTECTED] wrote:
On Tue, May 15, 2007 at 03:47:57AM -0700, mla wrote:
I find the Rails ActiveRecord interface pretty
appealing:
http://ar.rubyonrails.com/classes/ActiveRecord/Base.html
DBIC's interface is not dissimilar although it
favours data structures
--- Matt S Trout [EMAIL PROTECTED] wrote:
On Tue, May 15, 2007 at 12:10:15AM -0700, mla wrote:
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
Daniel Hulme wrote:
On Tue, May 15, 2007 at 01:24:17PM +0100, Matt S Trout wrote:
On Tue, May 15, 2007 at 03:47:57AM -0700, mla wrote:
I like how if you fetch columns that don't exist in the table
the object becomes read-only by default.
That's neat, although I prefer tools that presume I
Matt S Trout wrote:
On Tue, May 15, 2007 at 03:47:57AM -0700, mla wrote:
So with that design you'd get the centralized validation, which
is most critical to me, but then you could use SQL freely
and get back a collection of read-only active record objects
if you did fancy stuff.
You -can-
On Tue, May 15, 2007 at 12:37:57PM -0700, mla wrote:
Daniel Hulme wrote:
On Tue, May 15, 2007 at 01:24:17PM +0100, Matt S Trout wrote:
On Tue, May 15, 2007 at 03:47:57AM -0700, mla wrote:
I like how if you fetch columns that don't exist in the table
the object becomes read-only by default.
On Tue, May 15, 2007 at 12:56:43PM -0700, mla wrote:
Matt S Trout wrote:
On Tue, May 15, 2007 at 03:47:57AM -0700, mla wrote:
So with that design you'd get the centralized validation, which
is most critical to me, but then you could use SQL freely
and get back a collection of read-only active
I just finished getting the tutorial project working.
The thing I'm not clear on is this separation between lib/MyAppDB/
and lib/MyApp/Model/
The tutorial says:
With Catalyst::Model::DBIC::Schema you essentially end up with two sets
of model classes (only one of which you write... the other
19 matches
Mail list logo
