View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 1857 | Composr | core_fields | public | 2015-04-14 19:10 | 2015-04-22 20:04 |
| Reporter | Chris Graham | Assigned To | Chris Graham | ||
| Priority | normal | Severity | feature | ||
| Status | resolved | Resolution | fixed | ||
| Summary | 1857: Field options | ||||
| Description | Add field options for a field (needs doing for both CPFs and catalogue fields). It is done via a simple line input, which has comma-separated options written into it. There'll be no specific UI for configuring it all, it will involve hand-typing (a UI would be hard as to make it user-friendly we'd need to code it up with pre-knowledge of all options, and what field types each could apply to). Supported field options would be... Multi-list inputs: - custom_values=no|single|multiple - widget=multilist|vertical_checkboxes|horizontal_checkboxes - show_unset_values=off|on - dynamic_choices=off|on Date inputs: - min_year=? - max_year=? Multi-line inputs: - num_required=? - cms_type=line|codename|integer|float|email Text-block inputs: - wordwrap=off|on - wysiwyg=off|on - rows=? Upload inputs: - filetype_filter=? List inputs: - custom_values=no|single|multiple - widget=inline|dropdown|radio - list_size=? - auto_sort=off|frontend|backend|both (Misc): - input_size=regular|fullwidth - maxlength=? - html_type=text|password|number|email|tel|url|color Not all options apply to all field types. Many are very specific. I have roughly showed above what field types would support which. Extra notes: - Setting custom_values to a value other than 'no' turns a multi-list input into a combo box - Setting dynamic_choices to 'on' feeds all existing user-selections for the field back in as possible choices in the input list for future users (i.e. the input list is a combination of the list specified in the catalogue settings, and also subsequent user-inputs) - Setting show_unset_values to 'on' results in the entire selection list being shown on the frontend, with crosses or checks next to each item saying whether it is selected. Normally it would just list the selected values alone. Some of the existing multi-list field types would be merged together, and then differentiated only by field options. e.g. we don't need separate field types for whether a multi-select list is used or checkboxes, as that is just the 'widget' setting. This will make things much more intuitive, as it separates considerations of data modelling from the concerns of input UI design. We would write a conversion script to switch out existing usages of the dropped field types. A new fields tutorial would be produced. It would consist of a table with a row for each field type. Each row would include: - The human name of the field type - The codename for the field type used internally (makes things much clearer for programmers) - The supported field options, including what the defaults of each option is - A screenshot of the input UI - A screenshot of the frontend UI (or multiple if the 'widget' field option is supported by the field type) - Supported formats for inputting the default value - List fields have options delimited by "|", with the real default value coming first - Date fields may have a default value of 'now', which works dynamically - AUTO_INCREMENT default value - RANDOM default value - ... ? - Storage format, and notes how search is impacted (e.g. a date is stored as a textual string, and multi-lists are stored as a string with each selection written on its own line) The existing catalogues tutorial would link to the fields tutorial, as would the tutorial that covers CPFs. Any fields documentation in the catalogues tutorial would be merged in. | ||||
| Tags | No tags attached. | ||||
| Attach Tags | |||||
| Attached Files | |||||
| Time estimation (hours) | 8 | ||||
| Sponsorship open | |||||
|
|
This is far more extensive than we proposed as we were looking at Multi-list inputs only. You have vastly expanded the options and all are likely to be required at some stage. Happy to sponsor this great development. |
|
|
There is one other thing that I didn't mention earlier and that is when you edit a catalogue and add additional custom data fields (Which you will be able to add options as detailed in this ticket) There does not appear to be any way to GROUP "like" additional custom fields together nor any way to change the background shading of the newly added custom field. It would be a nice touch if it was relatively easy to be able to select collapsed or expanded on the group of fields and associate that with a group label. so it might be something like. Fields one to five (group label) (expand ^ or v) Field_one_text (shaded pink) Field_two_text (shaded pink) Field_three_text (shaded pink) Field_four_date (shaded blue) Field_five_date (shaded blue) |
|
|
There's a way to do something similar. If you put in a common coloned suffix, like "Example set: A" and "Example set: B" then "Example set" becomes a common header. |
|
|
This works a treat. The only issue is there is one line "MORE" sits by itself. It doesn't affect any operation. See the attached images. When you know how all of this CATALOGUE operation works it is a major selling feature for Composr as you can virtually create any sort of additional data set and corresponding screen entry. Very happy to sponsor this sort of work which will benefit many site users. |
|
|
Is there a proposed date for implementation of any of this work? |
|
|
"More" expander issue moved to 1864. |
|
|
Thank you for your sponsorship :). This is now implemented. I have attached the new fields tutorial. This all actually took me quite a lot longer than I planned, as there are so many field types, and I ended up doing a lot of tuning and v10 bug fixing during the process. I've tried to make the tutorial very clear. As it is a feature sponsorship it is for the next version (for v10). We will need to discuss what to do regarding your v9 site separately, and I'll bring this to you in due course. |
