Thanks Scott.

On 7/19/2011 12:45 AM, Scott Gray wrote:
Hi Adrian,

Why not replace it with a ProductFeatureContent entity 
(PK=productFeatureId:contentId:fromDate), that would follow the pattern 
commonly used throughout OFBiz.

Then I would have to go through the Content entity to get to the DataResource entity. That seems unnecessarily complicated to me.

Regarding your example, it would seem more appropriate to link your images 
directly to the product, I don't see the justification for needing to link it 
to the product feature.  Even if you justify it, the best place for meeting 
that need would probably be the ProductFeatureAppl entity.

Maybe I gave the wrong examples. A better example would be a model X automobile product, with a body color feature, a trim color feature, an upholstery color feature, and driver orientation (left/right) feature. Selecting the various features updates the image of the model X automobile so that it represents the current selections.


I'm not a huge fan of overly flexible entity definitions because they can lead 
to inconsistent usage across the codebase as different developers shoehorn it 
to fit their specific use cases.

So fear of inconsistent use should drive design?


Regards
Scott

On 19/07/2011, at 12:22 AM, Adrian Crum wrote:

I would like to use the ProductFeatureDataResource entity to connect an image 
to a product feature, but I don't see how that can be done with the way the 
ProductFeatureDataResource entity is constructed. There seem to be fields 
missing, and the way the primary key is set up there is no way to connect a 
data resource to a product + product feature combination.

Example: I have two products - 8 1/2 by 11 paper and a ball point pen. I also 
have a product feature - color: blue. I need to link product 8 1/2 by 11 paper 
+ color blue to an image of blue paper, and I need to link product ball point 
pen + color blue to an image of a blue ball point pen. The current 
ProductFeatureDataResource entity does not support that.

It seems to me this entity should be set up more like the PRICE COMPONENT 
entity in the DMRB - where various fields can be filled in to connect a data 
resource to a product, or a product feature, or product + product feature, or 
other combinations of product/order related criteria.

A better version of the ProductFeatureDataResource entity might be:

prodFeatDataResId* id-ne
dataResourceId id-ne
productId id
productFeatureId id
productCategoryId id
geoId id
partyId id
partyTypeId id
fromDate date-time
thruDate date-time

This version would meet the needs of my example, plus it provides the 
flexibility to connect data resources to other combinations of product/order 
related data.

What do you think?

-Adrian

Reply via email to