On 20/07/2011, at 2:48 AM, Adrian Crum wrote: > On 7/19/2011 2:40 PM, Scott Gray wrote: >> 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. > > Actually, adding the productFeatureId field to the ProductContent entity > would satisfy the need. I can extend the entity for this project. Thanks for > the help!
No worries, glad you've found a solution that will work for you. By the way, thank you for starting discussions like this, it's so rare these days that a committer will actually discuss significant changes/features with the community before diving into the implementation. The value of these types of threads really can't be overstated. >>>>>>>> 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
