Openbravo Issue Tracking System - POS2 | |||||
| View Issue Details | |||||
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0046322 | POS2 | Core | public | 2021-04-22 13:06 | 2022-02-01 08:07 |
| Reporter | vmromanos | ||||
| Assigned To | Triage Platform Base | ||||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Platform | OS | 5 | OS Version | ||
| Product Version | |||||
| Target Version | Fixed in Version | ||||
| Merge Request Status | |||||
| Review Assigned To | |||||
| OBNetwork customer | |||||
| Support ticket | |||||
| Regression level | |||||
| Regression date | |||||
| Regression introduced in release | |||||
| Regression introduced by commit | |||||
| Triggers an Emergency Pack | No | ||||
| Summary | 0046322: Ability to extend ConfigurationSet's selectorFunction | ||||
| Description | A configuration set is defined with a selector function, which returns the name of the configuration currently selected. Example: const configSet = ConfigurationSet.newInstance('OBPOS2_ButtonBar1') .setSelector(selectLayoutConfig) .addListenedModels(['Session', 'UI']) .put('default', ButtonBar1Config); In this case the selectLayoutConfig is a function that returns the config based on the layout. This approach makes it difficult to extend the configuration set from external modules, as it highly depends on the selector function implementation details. I mean, if the selector function is developed in a way that can't be extended from external modules, then you are totally blocked, and the benefits of using a Configuration Set would be lost. I see here two possible solutions to be able to extend it from external modules: 1. To be able to include several selector functions (one in the module that defines the Configuration Set, and other functions in external modules). The functions will be executed like a chain, and the next function will receive the output of the previous one (if any). This way we could easily reuse code. For example, in the example of the selectLayoutConfig, let's imagine that returns 'phone'. My external module function could read that 'phone' and decide what to do with it (reuse or replace). 2. Another possibility (that could complement previous option) will be to allow to change the configuration by any other *standard* mechanism, that would be totally independent of the selector function implementation, for example through a change in the state. | ||||
| Steps To Reproduce | I found this problem trying to change the configuration of the Product Popover configuration set (OBPOS2_ProductPopover). The selector function selectLayoutConfig originally linked to this configuration set didn't allow me to change the configuration in an external module (allergens), because that selector function was looking only at layout stuff, and I needed something to proactively change the config based on a user interaction (view allergens info button). The solution in my case was to replace the setSelector function by another implementation, loosing any logic about layout selection. The implementation was to add the configuration name in the UI model so this selection function could read it and return it immediately. I honestly think this is the way to go, maybe something like: state.UI.ConfigurationSet.<Name>.activeConfig | ||||
| Proposed Solution | |||||
| Additional Information | |||||
| Tags | No tags attached. | ||||
| Relationships | |||||
| Attached Files | |||||
| Issue History | |||||
| Date Modified | Username | Field | Change | ||
| 2021-04-22 13:06 | vmromanos | New Issue | |||
| 2021-04-22 13:06 | vmromanos | Assigned To | => Retail | ||
| 2021-04-22 13:06 | vmromanos | Triggers an Emergency Pack | => No | ||
| 2021-04-29 09:44 | guilleaer | Assigned To | Retail => platform | ||
| 2021-04-29 10:49 | guilleaer | Status | new => acknowledged | ||
| 2022-02-01 08:07 | alostale | Assigned To | platform => Triage Platform Base | ||
| There are no notes attached to this issue. |