You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
We have widely-used class, ConfigurableOperationDef, which is used as the basis of several runtime-configurable objects:
CollectionFilter
PaymentMethodHandler
PromotionAction
PromotionCondition
ShippingEligibilityCheker
ShippingCalculator
The definition allows the developer to define args which can then be configured at run-time with concrete values by the Administrator. In the Admin UI we generate form fields for this purpose.
The problem is that with the current implementation there are a number of limitations:
The supported data types for the args are fixed and cannot be extended in any way. Supported data types are: 'string' | 'int' | 'float' | 'boolean' | 'datetime' | 'facetValueIds'. Note that facetValueIds is a kind of special case which is actually just an array of strings.
The Admin UI cannot be customized to use custom components as input for these args values.
Only simple data types are supported, there is no support for relations. E.g. the facetValueIds seems like it is a relation, but it is really just a dumb list of strings. True relations would be prefereable, and should be generic so that any entity can be related.
List values are not supported.
Describe the solution you'd like
Disregarding the feasibility for now, here is the ideal solution:
Args can be defined as any of the datatypes supported by custom fields, as well as a relation to any available Entity
Arrays of any of those types are also supported
There is a way to specify a UI component to act as the input control of that arg, in a similar way that we do with custom fields already.
Any breakthroughs in this area may also be applicable to custom fields, such as the ability to define lists and relations.
I have no design for this yet - this is quite a complex problem and after some exploration I'll add any implementation ideas I come up with.
The text was updated successfully, but these errors were encountered:
Relates to #414
BREAKING CHANGE: The `'facetValueIds'` type has been removed from the `ConfigArgType` type, and replaced by `'ID'` and the `list` option. This change only affects you if you have created custom CollectionFilters of PromotionActions/Conditions using the `'facetValueIds'` type for an argument.
Is your feature request related to a problem? Please describe.
We have widely-used class, ConfigurableOperationDef, which is used as the basis of several runtime-configurable objects:
The definition allows the developer to define
args
which can then be configured at run-time with concrete values by the Administrator. In the Admin UI we generate form fields for this purpose.The problem is that with the current implementation there are a number of limitations:
'string' | 'int' | 'float' | 'boolean' | 'datetime' | 'facetValueIds'
. Note thatfacetValueIds
is a kind of special case which is actually just an array of strings.facetValueIds
seems like it is a relation, but it is really just a dumb list of strings. True relations would be prefereable, and should be generic so that any entity can be related.Describe the solution you'd like
Disregarding the feasibility for now, here is the ideal solution:
Any breakthroughs in this area may also be applicable to custom fields, such as the ability to define lists and relations.
I have no design for this yet - this is quite a complex problem and after some exploration I'll add any implementation ideas I come up with.
The text was updated successfully, but these errors were encountered: