Minor extension of existing field types
ssokolow opened this issue · comments
Currently, GM_config lacks a comfortable middle-ground for new field types. Either you reinvent the world, or you use the existing ones.
However, often, everything that's needed to get a really nice user experience is already implemented by the HTML5 additions to forms support.
Given that user scripts tend to have lower backwards-compatibility and cross-browser compatibility requirements than websites scripts and any savvy user already has an easy means to bypass validation if desired, that means that no backend changes are needed... we just need a way to customize how the field is displayed.
(eg. As far as GM_config is concerned, the only difference between an <input type="text"> expecting a hex color code and an <input type="color"> is that the latter magically makes the user less likely to type in invalid data.)
As such, I'd like to propose a documented facility for requesting a field type backed by <input type="text"> like text, int, or float, and then overriding/appending props values so I can ask for things like this:
'my_num': {
'label': 'Number is...',
'type': 'int',
'props': {
'type': 'range'
'min': 1,
'max': 10,
'step': 1
}
},
Refer to my answer on #72. You don't have to reinvent the wheel, you can make a custom field type extends one that GM_config already supports. Just call the prototype functions from your custom toNode, toValue, and reset functions. There is plenty of existing code to leverage for an extension of existing types.
Would you consider adding an example of that to the documentation? Even now that I know it's not going to cause some kind of subtle breakage if I do it properly, I don't feel confident I'll get it right.
Yeah I'll create example of how to extend an existing type in this way and put it in the wiki.
I hope it won't be as complex as the "Custom field types" example.
Expecting a developer to go to that much trouble just to change type="text" to something like type="url" or type="email" (or even type="datetime-local") would be spitting in their face.
It won't be anywhere near that complex. That example is about showing how to implement a new field type that is nothing like any of the current field types. Like what if you wanted an ordered list that could be reordered by dragging and dropping, and items could be added/removed by dragging and dropping from/to a second space of possible list items. That example shows how this could be achieved without having to edit the source of GM_config. You could publish that reusable field type as an extension for anyone who wants it.
The existing example is there for people who want to dream big. I'll be honest that I never considered minor tweaks to existing field types. There are many ways to do that, but the cleanest way is to create a custom field type to extend an existing type. If I have to modify GM_config to make the example simpler, then I will. But the code will stay generic and reusable.
I'm not spitting in anyone's face by offering a power, flexible, and reusable library with tons of documentation and detailed examples. I might have overlooked a use case, but I already said I'll remedy that. I answered your questions respectfully, and even updated the example I referenced on your other ticket. The least you can do is give me the benefit of the doubt.
Sorry about that. I try to be polite, but I'm not the most socially perceptive person and, especially when I'm dozy, I occasionally make mistakes. (At the moment, I'm trying to stop being nocturnal, so I'm half-asleep most of the time.)
My intent there was only to draw attention to the misconception users could potentially walk away with if they didn't follow up by actually contacting you and, in hindsight, I completely blew it.
Hi, sorry for being 3 years late, I've been working on a userscript and i've ran into the exact same issue, namely not being knowledgeable enough to implement <input type="color"> with the API Provided, sadly as far as i can see the example that was mentioned here isn't in the wiki, has OP Figured this issue out by now?
@Blumlaut Unfortunately not... I've had a lot of trouble finding time to work on userscripts over the last few years.
That's a shame, it seems the maintainer of this repo also went inactive, i'll see if i can get it working somehow, if i do i'll send an update here.
#90 will be the way this issue will be resolved, so this issue is now redundant.