Add new field types

[paddelboot]

Issue Overview

Adding new field types like range.

Expected Behavior

New field types to populate pods with.

Current Behavior

Limited set of field types available.

Steps to Reproduce (for bugs)

Possible Solution

Adding new field types to the core, probably.

[paddelboot]

Any estimate on the amount of time that might be necessary to implement this? I wouldn't mind doing it myself, but I would prefer some minimal input on which files to work on.

[sc0ttkclark]

Field types are in flux right now for Pods 2.8 while @pglewis rewrites them all with Backbone and Marionette so they will be ready for repeatable fields and loop field groups.

Let's start out by scoping what you want a range field to do. You want it to support storing to number values? How would you want the values stored? JSON / serialized for table storage? Serialized for meta storage? What field options will it have?

[pglewis]

Basic numeric ranges should already be supported with field type "number" and input type set to "slider" in advanced field options.

[sc0ttkclark]

I think he's wanting a range field like 1-10. Is that right? Or did you mean what @pglewis is describing?

[paddelboot]

Basic numeric ranges should already be supported with field type "number" and input type set to "slider" in advanced field options.

Thanks a lot, I didn't notice that.

If I understand your other answer correctly, the field types implementation is in the process of refactoring, which would make it kind of obsolete to add any additional field type for Pods 2.7x?

Regarding the value storage type: I'm not entirely sure. I would probably prefer a (serialized) JSON format that would be compatible with all sorts of use cases. The field options themselves would be something to consider per field type, I think. But in general, they would just map the official field type attributes, like step for a range field.

[pglewis]

If I understand your other answer correctly, the field types implementation is in the process of refactoring, which would make it kind of obsolete to add any additional field type for Pods 2.7x?

Definitely a freeze on field types in 2.7 since a big portion of the work for 2.8 is reworking all the fields.

The 2.8 push is literally now so this is the time to examine the shortcomings and make improvements.

[paddelboot]

This is not in the scope of any particular field type, but a major improvement would be if I could easily add any kind of options to either existing field types or new field types, ie. in the "Additional field options" or "Advanced" tab. It would give end users more control over the behaviour, like hiding them in a specific context or performing certain actions after submission.

I know there is a pods_admin_setup_edit_field_options filter, and I am using it in my current code to add a field option, but it's a bit hacky, because I need to use the name of an existing option, ie. hidden, for the field value to be remembered after saving.

[sc0ttkclark]

That part is getting better as part of #1793