On May 14, 2007, at 2: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.
Here is what I would do. Make ProductTypeAttribute an abstract
class. Make each type of attribute a sub-class
(ProductTypeBooleanAttribute, ProductTypePowerChainAttribute, etc.)
and use single table inheritance and give each type a restricting
qualifier ((type = 'Boolean'), (type = 'PowerChain') etc.) that is a
class property.
Now create a component for each type of attribute:
BooleanAttributeUI, PowerChainAttributeUI etc. You can then use
WOOGNL (from Project Wonder) or methods in your other components to
translate between the type of ProductTypeAttribute and the name of
the UI using WOSwitchComponent:
<webobject name="ProductTypeAttributesRepetition">
<webobject name="ProductTypeAttribute" />
</webobject name="ProductTypeAttributesRepetition">
ProductTypeAttributesRepetition: WORepetition {
list = aProduct.type.attributes;
item = anAttribute;
}
ProductTypeAttribute: WOSwitchComponent {
WOComponent = ~anAttribute.type() + "AttributeUI";
attribute = anAttribute;
}
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
