On 20/07/2011, at 12:31 AM, Adrian Crum wrote: > On 7/19/2011 1:19 PM, Scott Gray wrote: >> On 20/07/2011, at 12:03 AM, Adrian Crum wrote: >> >>> On 7/19/2011 2:07 AM, Scott Gray wrote: >>>> 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. >>> I would hope the design decision to go through the Content entity was based >>> on something more than "it's always been done that way." If someone wants >>> to use the image in a CMS, then they can create a Content record that >>> points to the DataResource. >> Of course it was, the Content -> DataResource relationship adds a huge >> amount of functionality that doesn't exist when referencing a DataResource >> record directly. To be honest I can't believe we're even having this >> discussion. Mime types, decoration, pre-rendering service execution, >> permissions, internationalization and more. I get the impression your view >> is narrowed to your specific use case (getting a url for an image) and >> you're not considering the wider implications. >> >>>>>> 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. >>> Would it help the discussion if the new structure looked like this: >>> >>> prodFeatDataResId* id-ne >>> dataResourceId id-ne >>> productId id >>> productFeatureId id >>> fromDate date-time >>> thruDate date-time >>> >>> >>> ? >> Not really, we're still missing the justification for inclusion of a >> productId and I still completely disagree with the direct relation to >> DataResource. I still think a ProductFeatureContent entity following our >> standard practices is the best way to go. > > A product feature might apply to more than one product, so both bits of > information are needed to select the correct image.
I'm still not entirely sure of the use case, but I could live with something like: ProductFeatureContent productFeatureId* contentId* productFeatureContentTypeId* (or perhaps an enum instead of yet another type entity) fromDate* thruDate productId The definition above follows the same pattern used by ProductContent, ProductCategoryContent, ProductPromoContent (name?) and plenty of other entities that link into the content model. I worked on a project recently where we did something similar with ProductContent except the additional field was for a productStoreId which allowed us to use specific product names, descriptions, images, etc. for different product stores and also provide a general default by leaving the field null. >> >>>>>> 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
