Hi Johan,
I have worked on this and halfway implemented it. In my case,
however, I wanted to be able to reuse the code for many different
entities (i.e. products, customers, vendors) and not have to create a
schema for each entity. My approach has been to create a class with
static methods that return AttributeValue[ ] for the specific objects
and Attribute[ ] for a specific entity (and allow editing of
course). The library then works with the entity's class name and
it's primary key info as appropriate. This uses an interface called
IAttributable that returns the class name and primary key info. I'm
kind of using "class name" loosely because it doesn't figure out the
class name, but instead allows the implementing class to return
whatever value it wants to. The goal of this was to reduce the
amount of recoding if subclasses of a class should just use the
parent class' attributes. The same goes for the pkid method. Rather
than just use the pkid, the class can return whatever it wants as a
pkid.
The rest of the coding is as you have it, and I'm not going to even
go into the UI. There is going to be a table with a bunch of
booleans, a table with a bunch of varchars, etc.
I just thought that I'd share this method because it is reusable and
would someday (when I'm finally done) produce a completely standalone
library that can be used with any entity. But, if you're getting
into it, you might want to make it reusable from the start.
John
On May 14, 2007, at 4:14 AM, Johan Henselmans wrote:
I am settting up a database in which we want to store information
about products and their attributes.
However, we do not know in advance what attributes will be part of
the product, apart from a few (price, date-available etc). So I
came up with the idea to use a separate table for producttype-
attributes, that would be filled afterwards.
The producttype-attributes would then be defined for a product-type.
EG: a product-type of car would have product-attributes:
Powerchain (electric/diesel/hybrid/petros/steam)
Airco (Yes/No)
NoOfDoors (anInteger)
PriceInEuro's (currency)
PriceInDollars (currency)
If an extra attribute would show up, for example the amount of CO2
exhaust per km, then one would add a producttype-attribute
CO2exhaustpkm (float) ,
add that to the product-type, and every car would get that extra
attribute.
These attributes would of course be defined in a separate table,
that would make it possible to use those producttype-attributes for
different product-types.
In our case the Powerchain attribute would also be part of the
product-type for trains, planes and vans.
The scheme would be:
producttype-attributes <<->> product-type ->> product<->>product-
attributes -> producttype-attributes
The problem for me is in the values that a producttype-attribute
can have. It would mean that one defines in producttype-attributes
values like boolean/date/time/integer/float/multiplechoice on a
meta level and that value that would end up in the product-
attributes. That would have to translate into a view (popup list,
numberformatter, dateformatter) during input and presentation.
Is there anybody that has done that kind of thing, or does anybody
know any examples that do the same thing?
Regards,
Johan Henselmans
http://www.netsense.nl
Tel: +31-20-6267538
Fax: +31-20-6273852
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/the_larsons%
40mac.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
