Tony Bowden wrote:
> 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?
Mainly for reasons of backwards compatibility. It won't be too hard to
get it working, but we'll need to update most of the factory templates
and some of the documentation. The feedback on this so far is positive,
so I've put it on the todo list.
> 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
_______________________________________________
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