On Wed, Dec 29, 2004 at 04:10:00AM +0000, Simon Flack wrote:
> >>package Football;
> >>use base Class::DBI;
> >>Football->table('fairy');
> >For the various things which use moniker() and/or table() what's the
> >consensus on which should be used where?
> >I'd personally want 'football' almost everywhere.
> I agree. The most significant place that the table name is used over the
> moniker() is the request url. That's a pretty significant change though.
Hmm. Why's that? Do you mean for reasons of backwards compatbility, or
in terms of technical implementation?
I think it's quite an important change, and hadn't actually realised
Maypole dispatched purely based on table names!
Class::DBI goes to quite some length to make sure that the table
name for any class is a 'private' piece of information that is never
needed anywhere else. The ->table() declaration should be the only
place to you ever need to use it. This is most useful where you are
building a Class::DBI layer on top of a legacy database over which you
have no control. You can hide the fact that you have a table called
'tx_qjkr[!ser:93/01]' behind one declaration, give it a sensible name,
and forget about the underlying insanity.
It even provides ways of constructing SQL (even with joins!) without
mentioning any table names.
Maypole should certainly strive to maintain this illusion as well.
Or, consider the useful Class::DBI idiom of having multiple classes
pointing at the same table. Take the example of a 'customer' table which
holds a column 'is_staff'. We can't split this out in its own table, as
we're wrapping a Maypole framework around someone's 10 year old database
with other large systems all feeding in to it and hundreds of reports
for management worldwide being generated from it.
Your business rules state that if a customer is a staff member then the
other data you hold in this table should be treated differently (the
otherwise mandatory 'address' fields, for example, can be left out as we
already have these in a different HR database)
You could write all sorts of complex logic in your MyCompany::Customer
table, but it's often easier to split out a MyCompany::Employee class,
that also points at the same table as MyCompany::Customer but with
different triggers, validation routines, default values etc. and provide
different forms for creating a normal Customer vs creating an Employee
Customer.
Maypole certainly shouldn't care that both of these classes will be
reading and writing the same database table. If we've already partitioned
their behaviour at the Model level, everything else should Just Work.
Tony
_______________________________________________
maypole mailing list
maypole at lists.netthink.co.uk
http://lists.netthink.co.uk/listinfo/maypole
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:57 GMT