I typically act on field categories on the back end rather than on the frontend. If there needs to be something field-specific on the frontend, the approach I tend to recommend is to do so based on the field alias.
If you can tell me a little about the scenario you are working with, maybe we can look into adding passing the field categories to the frontend.
I'll address each separately, though the true solution would probably be an amalgam of each scenario.
Change Field Presentation
To change the way a field gets displayed, you can actually override Formulate's built-in field rendering for that field to do something entirely custom. We have actually done this specifically with the date field (as you say, the native date field functionality isn't great). This page shows how to do that (in this case, it override's the built-in text field): http://www.formulate.rocks/articles/custom-field-types
For quick reference, here's the relevant bit of code:
Rather than try to use categories as settings, I'd recommend creating a new type of field, perhaps called "Advanced Date". In this field type, you can add whatever settings you want (e.g., a drop down that allows for the date selection type to be chosen). Formulate calls this "configuration". You can see a good example of this with Formulate's built-in button field type:
It includes some configuration for a "button kind". In the back office, this is shown as a drop down. By default, it allows for "Submit", "Previous", and "Next", but in the case of the button it allows for the drop down values to be configured in a file. Getting the values from a configuration file is probably more complicated than you need, but the rest of the implementation still applies.
Recommendation
You could certainly consider sending the field category to the frontend, but it would require a pull request for Formulate. Personally, I'd probably go with creating a new field type. In that case, you wouldn't need to override the rendering of the built-in date field, as you'd have an entirely new field type to control the rendering of.
Field Categories
It’s not immediately obvious how to act upon fields once a Category has been selected.
e.g. I don’t see a class or attribute on the field to indicate the category.
I typically act on field categories on the back end rather than on the frontend. If there needs to be something field-specific on the frontend, the approach I tend to recommend is to do so based on the field alias.
If you can tell me a little about the scenario you are working with, maybe we can look into adding passing the field categories to the frontend.
I’d like to use the Date field type, it’s just unfortunate that consistent browser support for HTML5
input type="date"
just isn’t there yet.As an alternative, we sometimes use a third party datetime picker.
I was trying to test how this would integrate with Formulate.
A class is ideal to pick up on since there could be more than one date field on a form.
e.g.
I’d hoped that categories might let me go as far as to specify the format of the picker too.
Looks like there are two things going on here:
I'll address each separately, though the true solution would probably be an amalgam of each scenario.
Change Field Presentation
To change the way a field gets displayed, you can actually override Formulate's built-in field rendering for that field to do something entirely custom. We have actually done this specifically with the date field (as you say, the native date field functionality isn't great). This page shows how to do that (in this case, it override's the built-in text field): http://www.formulate.rocks/articles/custom-field-types
For quick reference, here's the relevant bit of code:
Field Settings
Rather than try to use categories as settings, I'd recommend creating a new type of field, perhaps called "Advanced Date". In this field type, you can add whatever settings you want (e.g., a drop down that allows for the date selection type to be chosen). Formulate calls this "configuration". You can see a good example of this with Formulate's built-in button field type:
It includes some configuration for a "button kind". In the back office, this is shown as a drop down. By default, it allows for "Submit", "Previous", and "Next", but in the case of the button it allows for the drop down values to be configured in a file. Getting the values from a configuration file is probably more complicated than you need, but the rest of the implementation still applies.
Recommendation
You could certainly consider sending the field category to the frontend, but it would require a pull request for Formulate. Personally, I'd probably go with creating a new field type. In that case, you wouldn't need to override the rendering of the built-in date field, as you'd have an entirely new field type to control the rendering of.
is working on a reply...