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
The common use case of the YUI object-finder picker was to allow picking files (and folders!!) with selectability restricted based on the type of the node and required type of a field. It should be possible to easily configure the FilePicker module (without re-configuring all the constituent views), to define rules / conditions for the selectability of items.
Ideally, it should be possible to:
support selection of any type of node, i.e. files / folders as well as other kinds of nodes (custom view may need to be provided by developer for custom structure traversal)
restrict selectability of nodes based on the type, an aspect (both supported by legacy picker) or custom renderFilter rules based on state (i.e. property comparisons)
remove/reorder tabs or add custom tabs to the picker without duplicating (copy&paste) the entire widgetsForDialog config structure
With these requirements in mind, I'd refactor the picker to extract form control functionality, selection rule handling and aggregation of tabs into a base picker module, use mixins for "add-in" pre-defined tabs and one pre-defined "FileFolderPicker" (equivalent to the current "FilePicker") which extends from the base picker and mixes in all the tab mixins. This could in the future also form the base of a complex authority picker (instead of just the simple MultiSelectInput config currently used in the FormsRuntimeService. Developers could use the base picker to build use-case specific pickers without inheriting all the baggage of tabs they don't need.
The text was updated successfully, but these errors were encountered:
Thanks for the input on this, I can add some feature request issues in JIRA but to be honest at the moment my primary focus is in providing something that enables us to make progress with the forms runtime service. That's not to say that these aren't good ideas and shouldn't be implemented, but at the moment I just need something that works for the moment.
I agree that the correct approach is to abstract the re-usable parts into other modules that can be extended and mixed in.
I'm not sure how quickly I'll be able to get this done though.
The common use case of the YUI object-finder picker was to allow picking files (and folders!!) with selectability restricted based on the type of the node and required type of a field. It should be possible to easily configure the FilePicker module (without re-configuring all the constituent views), to define rules / conditions for the selectability of items.
Ideally, it should be possible to:
With these requirements in mind, I'd refactor the picker to extract form control functionality, selection rule handling and aggregation of tabs into a base picker module, use mixins for "add-in" pre-defined tabs and one pre-defined "FileFolderPicker" (equivalent to the current "FilePicker") which extends from the base picker and mixes in all the tab mixins. This could in the future also form the base of a complex authority picker (instead of just the simple MultiSelectInput config currently used in the FormsRuntimeService. Developers could use the base picker to build use-case specific pickers without inheriting all the baggage of tabs they don't need.
The text was updated successfully, but these errors were encountered: