David Baird wrote:
>> (A) The M-M-CDBI model base class should not inherit from C-DBI. It
>> should first call C-DBI-Loader, which decides the appropriate
>> flavour of C-DBI to inherit from (C-DBI-mysql, C-DBI-SQLite etc)
>> and creates all the classes for the tables with that base class.
>>
>> (B) But the other useful thing that the M-M-CDBI base class does is
>> to _use_ all the additional C-DBI-* modules (AsForm, FromCGI etc).
>> To do that, for some of them at least, it needs to inherit from
>> C-DBI or a subclass (so the C-DBI-* modules can call set_sql in
>> their startup).
>>
>> So that's the dilemma. M-M-CDBI shouldn't inherit from C-DBI (A),
>> and it should (B).
> (A) is implemented as a method call (runtime), and (B) via use
> statements (compile time). To get the runtime call to happen at
> compile time, before B, you can wrap it in a BEGIN { ... } block,
> which I believe should be placed before the use statements.
I started to experiment with that last night but gave up. The thing that
stopped me is the long list of arguments that get passed to
setup_database from the application - self, config, namespace, dsn,
user, password, options. It wasn't clear that all those would always be
available at compile time without putting lots more code into BEGIN
blocks. I hate to do that because it makes debugging much more
difficult. In particular, forcing third-party Maypole-using application
developers to put their code in BEGIN blocks seemed antisocial. Better
for the framework to take a complexity hit. Is there a way around that?
Cheers, Dave
_______________________________________________
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