Product features and user-provided data

[Brian Ghidinelli]

A model question from the OfBizDatamodelBook PDFs and
https://cwiki.apache.org/confluence/display/OFBENDUSER/Product+Features

I believe I understand I can have a ProductFeatureType of "Brand" with
ProductFeatures of Hanes, American Apparel and Lacoste that could be
related to my Product.

What if I have user-provided data for my product?  For example, I have a
"Name to embroider on shirt" where I want to collect an arbitrary value
from the buyer?

Once that's presented to the user in the purchase process as something
like a text input field, where would OfBiz store that value for a
particular Order Item?


Brian

[taher]

Hi Brian,

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.

Regards,

Taher Alkhateeb

On Sat, Aug 13, 2016 at 6:44 AM, Brian Ghidinelli <[hidden email]> wrote:

>
> A model question from the OfBizDatamodelBook PDFs and
> https://cwiki.apache.org/confluence/display/OFBENDUSER/Product+Features
>
> I believe I understand I can have a ProductFeatureType of "Brand" with
> ProductFeatures of Hanes, American Apparel and Lacoste that could be
> related to my Product.
>
> What if I have user-provided data for my product?  For example, I have a
> "Name to embroider on shirt" where I want to collect an arbitrary value
> from the buyer?
>
> Once that's presented to the user in the purchase process as something
> like a text input field, where would OfBiz store that value for a
> particular Order Item?
>
>
> Brian
>
>

[Brian Ghidinelli]

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

[taher]

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 <[hidden email]> 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
>
>
>
>

[Brian Ghidinelli]

On 8/15/16 13:03, Taher Alkhateeb wrote:
> 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.
Taher,

Thank you for the response, this helped me get things in the ofbiz way a
little better. We're looking at a ProductQuestion entity similar to
ProductFeature but using our existing EAV structure to facilitate the
requirements and validation and then a linked entity from OrderItem to
store the results of those answers.

Cheers,


Brian

[Jacques Le Roux]

Thinking about it, maybe you should look at the how the Survey* entities could be used for that need

I believe it's powerful way but maybe not a smooth journey https://ofbiz-vm.apache.org:8443/content/control/FindSurvey

Jacques


Le 19/08/2016 à 04:21, Brian Ghidinelli a écrit :

>
> On 8/15/16 13:03, Taher Alkhateeb wrote:
>> 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.
> Taher,
>
> Thank you for the response, this helped me get things in the ofbiz way a little better. We're looking at a ProductQuestion entity similar to
> ProductFeature but using our existing EAV structure to facilitate the requirements and validation and then a linked entity from OrderItem to store
> the results of those answers.
>
> Cheers,
>
>
> Brian
>
>