Re: how to do a product->product-type->product-attributes with non pre-determined product-attributes?
Re: how to do a product->product-type->product-attributes with non pre-determined product-attributes?
- Subject: Re: how to do a product->product-type->product-attributes with non pre-determined product-attributes?
- From: Johan Henselmans <email@hidden>
- Date: Tue, 15 May 2007 16:41:50 +0200
On 14-mei-2007, at 19:12, Chuck Hill wrote:
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
Chuck, thanks for the suggestion. I had a look at WOOGNL. The
documentation is, let's say, ... sparse ....
Is there any chance that we might get a nice new book of some
infamous author which would cover subjects as Project Wonder, Eclipse
and WOLips, deploying and developing the new license-free WebObjects
on OS X, Linux, FreeBSD, Solaris and Windows?
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden