Introduce product attributes

[bleroy]

Product attributes are defined as fields that usually have nothing to edit in the product editor. The parameters of the attributes are usually set-up at the content type definition level, as settings of the fields.

Built-in product attributes are Boolean, numeric, and text (which includes predefined values, and thus can handle enums, flags, and combos). This should be enough for most cases, but is, as usual, extensible.

The front-end for those new fields will be introduced with the shopping cart: each attribute will participate as adding information to the "add to cart" action. For example, adding two shirts of size M.

[agriffard]

The editor of the settings of the TextProductAttributeField does not seem to be displayed when I try to configure it.

[bleroy]

Works fine for me. Anything in logs? Oh wait, that's weird, the edit cshtml has a dot instead of an underscore in the name. I'm wondering if that explains the difference. Can you try to rename it? I'll also update the PR, if only for consistency.

Nah, unless you have the same problem with Boolean.

[agriffard]

Yes, I should have checked this:

2019-04-22 13:41:59.0368|Default|8000004b-0004-fe00-b63f-84710c7967bb||OrchardCore.ContentTypes.Editors.IContentDefinitionDisplayHandler|ERROR|IContentPartFieldDefinitionDisplayDriver thrown from OrchardCore.Commerce.Settings.TextProductAttributeFieldSettingsDriver by ArgumentNullException System.ArgumentNullException: Value cannot be null.
Parameter name: value
   at System.String.Join(String separator, String[] value)
   at OrchardCore.Commerce.Settings.TextProductAttributeFieldSettingsDriver.<>c__DisplayClass0_0.<Edit>b__0(TextProductAttributeSettingsViewModel viewModel) in D:\Orchard\OrchardCoreDev\src\OrchardCore.Modules\OrchardCore.Commerce\Settings\ProductAttributeFieldSettingsDriver.cs:line 50

[bleroy]

Good catch, I'll fix it now. Thanks.

[bleroy]

Done. Please check again. Thanks!

[agriffard]

Ok, it works now. Thank you.

@Skrypt managed to use a nice editor for predefined values on a text field.

[bleroy]

Sure, I'm going for MVP for the moment, but I'll gladly merge PRs making stuff nicer. I'll take a look though.

[microposmp]

The settings view for BooleanProductAttributeField is missing a field for configuring default value.

Added below code block to test the logic.

<fieldset class="form-group">
    <div class="row col-sm">
        <label asp-for="Label">@T["Default value"]</label>
    </div>
    <div class="custom-control custom-checkbox">
        <input asp-for="DefaultValue" type="checkbox" class="custom-control-input">
        <label class="custom-control-label" asp-for="DefaultValue">@T["On/Off"]</label>
    </div>
    <div class="row col-md">
        <span class="hint">@T["The default value associated with this attribute."]</span>
    </div>
</fieldset>

[bleroy]

Good catch, thanks!

[Skrypt]

Just saying but I think you can also use Bootstrap switch toggles. It's more like an On/Off and you don't need to specify it.

[microposmp]

Now I think it's clear to me what the real purpose of the ProductAttributeFields are. I missed this sentence in the description in #25. "The main difference is that the actual value is not attached to the product but to the shopping cart item.".

I really like this feature. It enables easy configuration of scenarios that we today call additional handling. We today see multiple scenarios where this would be useful. For example printing custom information on items.

In the sample above with the Discountable field I would use the standard BooleanField in OrchardCore. I like the idea with the default value configurable and see value in making it part also in the OrchardCore standard BooleanField. I'll do that as an exercise.

I don't see the need to consider the ProductPart (SKU) as I described in #31 for the ProductAttributeFields. I think size/color on products in stock (inventory) should be handled in a different way. I'll try to clarify how I think about this with some samples. Plan to do it in the weekend.

[bleroy]

Thanks. I do think the possibility for different SKUs need to be there at least as an extensibility point: one of the biggest challenges in designing an e-commerce platform, as opposed to a one-shot e-commerce web site, is that no two businesses share exactly identical processes.

The way I see it, the SKU could be modified by any service implementing a certain interface. Attributes would be one way to affect it, but there could be others.