On 19/07/2011, at 12:51 PM, Adrian Crum wrote: > 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.
That's how the content data model is designed, virtually nothing in the current data model attempts to link directly to the DataResource entity. >> 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 still don't quite get it, wouldn't placing the images on the variants achieve the same thing? I could see potential for what you're talking about on configurable products where there is no virtual but I guess you don't mean that because we'd be talking about config options instead of product features. >> >> 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? Absolutely, I'd rather not give our committers enough rope with which to hang the project. Am I really that concerned about the quality of code getting committed? Yes, yes I am. Besides, you can't just propose a new entity and throw in a bunch of random fields with no justification for their presence. As it stands I could use your entity to link a partyId and geoId without using a productFeatureId or dataResourceId at all, I wonder how long it would take for someone to do something like that simply because it's easier than actually doing a proper 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 >>>
smime.p7s
Description: S/MIME cryptographic signature
