Hi Brian, All very good points and enriching questions. Hopefully others will pitch in for help, and I will try to address some points below:
- Your point about system-defined and user-defined being conceptually similar is valid, but there is an important and critical difference. User defined items have a varying value (user input) whereas system defined values do not change (the description remains the same and everything else). So the logic around receiving input from users, validating it, storing it, and fetching it later adds complexity that does not exist with system-defined values. - One way to create keys associated with the attributes is by fetching them from a table (Enumeration for example), and create the validation logic at the service & user interface levels. - The attribute is only one suggestion that I had in mind. Another way to go about this is with the entity extensibility pattern -> https://cwiki.apache.org/confluence/display/OFBIZ/General+Entity+Overview#GeneralEntityOverview-ExtensibilityPattern - Are you familiar with ECAs? Maybe another way to also achieve your objective is with ECAs by triggering additional services for the logic around your user-input into orders -> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Tutorial+-+A+Beginners+Development+Guide#OFBizTutorial-ABeginnersDevelopmentGuide-ECA(EventConditionAction) - All in all, whatever solution you come up with, I think you'll have to create some custom logic, at least for validation and CRUD. I think you are trying to (rightly so) reuse whatever you can, but you still need to get some work done. Hopefully others will provide input, and I hope this helps. Cheers, Taher Alkhateeb On Mon, Aug 15, 2016 at 12:18 AM, Brian Ghidinelli <[email protected]> wrote: > > On 8/14/16 01:07, Taher Alkhateeb wrote: > >> I think perhaps what you are seeking is not related to the product data >> model, instead, it is related to order. >> >> Now, in your case this might be a bit too custom for your needs. I'm not >> sure but I would suggest to store such values in OrderItemAttribute where >> you define a custom attribute maybe with a key called CUSTOM_EMBROIDER for >> example. Then you build your solution around that attribute key. >> >> Thanks Taher, that's a good direction to consider. The reason that I > looked at Product Features is because my users conceptually consider > system-defined and user-defined options for a product as roughly equivalent > and they are related at the order line item level. You could imagine: > > Product: Engagement Ring > > System-defined Product Feature Types where product features are enumerated: > Size (finger sizes) > Material (gold, silver, plat) > Stone type (diamond, opal, ruby) > > User-defined "Product Feature Types" where the product features are > provided by the user: > Engraving text (text, limit of 30 characters, engraved on the ring) > Date of wedding (date field, used for customer service to send a wedding > card) > Name of partner (text, limit of 10 characters, printed onto a certificate > of authenticity) > Total amount you want to spend (money/decimal field, choose a stone > quality/size which stays within budget) > > This is just an example but the idea is that my admins may want to collect > ad-hoc data from the customer. They want to see it with the line item that > has been purchased, include it in receipts, print it in reports, etc. Today > we do this using EAV since our SaaS system can't define it in advance for > all customers. > > Looking at OrderItemAttribute, it looks like a candidate, but I don't see > where in the model you define what the attributes are? E.g., where would I > define the label "Date of wedding"? What if I wanted to specify it should > be a date? What if I wanted to define it as required or optional? If those > are all things that need to be added, it sounds like duplicating much of > the ProductFeature supporting entities? > > Can ProductFeatures and OrderItem be intelligently extended to handle both > system-defined and user-defined values? > > > Brian > > > >
