Story #33153
Feature suggestion: Option Value Providers
| Status: | Accepted | Start date: | 2012-01-12 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | - | |||
| Target version: | 6.0 | |||
| Story points | - | |||
| Velocity based estimate | - | |||
| Remaining hours | ||||
| Votes: | 1 (View) |
Description
Excellent work guys. I've got a suggestion though. It's a multipart suggestion and I hope each part makes individual sense:
- Add way to fill out default select option values when adding a select-type property
- Add a setting to define wether field supports multiple (CSV) values
- Replace generated TCA for fields which are <select> fields and are not relations, to employ a itemsProcFunc
- Generate an AbstractOptionsProvider which implements an interface compatible with TYPO3 itemsProcFunc carrier classes (the method may need to be static...). Place in generated dir Classes/OptionProvider/.
- In AbstractOptionsProvider, make a prop+getter which returns if the field supports multiple values (CSV)
- Generate in Classes/OptionProvider/<ModelObjectName>/ an OptionProvider for each select type property, the OptionProvider being...
- - unique if default options were provided
- - a shared OptionProvider base class for the ModelObject if no options are provided
- Generate the code which sets the default values (could be a protected property and default return logic I suppose)
- Allow the modelling tool to set the OptionsProvider class name (generate using that name if specified)
- In edit/create views, generate a series of OptionProvider calls and template variable assignments
- In the default form, use the assigned template variables as options argument for <f:form.select> fields
I am going to submit a change in Extbase itself, adding an OptionValueProvider base class which you can subclass in the future. I may add TypeConverters to turn multivalue-selects into arrays. I'll see what I come up with.
The benefit would be the capability of providing dynamic options (for example, limit the status options based on the current status) to the BE in addition to just the niceness of being able to specify the options for each select-type property directly while modelling, without diving into TCA, and post-facto by editing a proper Extbase class :)
And of course the tighter connection between FE and BE values assuming the OptionProviders are used in FE as well. Which they should be, why the default code should be generated so people quickly learn the concept :)
Of course all these OptionProvideres should be protected (individually by model class and one exclusion for the abstract base class) in the YAML config as all other paths are.
Hope it makes sense. Not sure which category to place this in.
History
Updated by Nico de Haen over 1 year ago
- Target version set to 6.0
That's definitely a good idea but we have to implement the new GUI first, since the current GUI is hard to extend and it is not worth to invest any more work in the old YUI/inputEx framework. I know it's a kind of blocker and hopefully we will proceed soon with the new GUI...
So the target version for this feature is set to 3.0
Updated by Nico de Haen over 1 year ago
- Status changed from New to Accepted
Updated by Claus Due over 1 year ago
Hi Nico,
Instead of doing much of the above perhaps we can join forces about this extension I've just started working on but already made great progress with: