Re: [CDBI] Different subclasses for one table / Factory Pattern?

I just did something very similar, but relating to RF components. I
looked at Class::DBI::Loader and Class::Accessor for guidance.

I have several tables (there are many more than are listed in the
implementation, but the others don't mess with my factory pattern):

Pedestal - has many components.

Component - contains the instance information for a component, and a
has-a relationship to a ComponentModel

ComponentModel - contains model information for that component, and it's
capabilities it has many ModelParameter and ModelSensors.

ModelParameter - r/w values with command protocol info for each
parameter for the matching model. I want these to expand to
accessor/mutator functions for the generate objects

ModelSensor - r/o values with command protocol info for each sensor for
the matching model. I want these to expand to accessor functions for the
generated objects.

I wrote a module ComponentFactory.pm, that generates code for each
component as it's initialized from the contents of the Component table,
and then evals the code into the perl namespace, and then initializes
the class and returns the instance.

For example:
a MetCom model receiver (in table ComponentModel) is a component in the
component table (name = MetCom_1).

I call something like:
$rx = ComponentFactory::Generate_Component( 
	myDBI::Component->search( name => "MetCom_1" )->next() );

The Generate_Component() function:

1. creates a class Component::Model::MetCom, with accessors/mutator
functions based the ModelParameter and ModelSensor functions. It evals
the code. It generates a constructor that takes the myDBI::Component
record as the argument. (NOTE: you need to make sure the model isn't
already in the namespace. I eval "use Component::Model::MetCom;" and
check for errors to see if it's already done. If so, then I just move on
to step 2. NOTE2: this also allows you to override the auto-generated
objects as well, since if you write a module, it will eval ok, and then
just run new() on the module you wrote--very useful!).

2. calls Component::Model::MetCom->new(), passing in the
myDBI::Component record, and returns the object.


Looking back on it now that it's working, it was a lot easier than I had
thought it was going to be. It's probably even more simple than I can
convey in the description here. 

-Judd

-- 
____________________________
Judd Taylor
Software Engineer

Orbital Systems, Ltd.
8304 Esters Blvd, Suite 870
Irving, TX 75063-2209

judd.t-EHvbq2lE5PjkQYj/[email protected]
(469) 442-1767 x127


On Sun, 2006-07-30 at 21:19 +0200, Stephan Brunner wrote:
> Hi all,
> 
> I'm currently setting up an application with Class::DBI and sqlite. In the 
> database, I will store something like a filesystem representation, so I have 
> a table "dir" for directories and "file" for files.
> The application knows different types of files and I would like to use a base 
> class "File" and subclasses (like "File::Foo" for files of type foo and so 
> on...) to handle those file types.
> 
> Right now, I have only one table for *all* files, but need to create different 
> File::<something> objects depending on column values (the file name, for 
> example). I want $dir->files() to return a list of objects in the 
> per-file-specific subclass. Is it possible to set this up using Class::DBI? 
> 
> My idea woud be something like a sub new() in the base class "File" (the one 
> representing the database table) that gets the column values and selects the 
> appropriate subclass (by calling File::Foo->new(...), for example). But I'm 
> not sure which exact sub I would have to override and whether this is safe 
> under all circumstances?
> 
> Another possibility seems to be Class::DBI::Plugin::Factory, which (if I 
> understood correctly) hooks into the select-trigger and reblesses the given 
> object.
> 
> One more way to go would be to redesign the database schema and create 
> seperate tables for each file type, but that's not as flexible IMO (adding 
> another filetype would require a change to the schema).
> 
> Thank you very much for your advice to a novice,
> 
> Stephan
> 
> _______________________________________________
> ClassDBI mailing list
> ClassDBI-Ra3b/[email protected]
> http://lists.digitalcraftsmen.net/mailman/listinfo/classdbi