create native HTML5 fields

[icebob]

Because currently there is no vanilla datetime picker. Pickaday is only date selector.

• [x] create new field common type which has a "inputType" property. (break changes)
• [x] rename datetime field to datetimePicker (break changes)
• [x] rename slider field to rangeSlider (break changes)
• [x] update docs (add new radio values description)

Available types

• [x] date
• [x] datetime
• [x] datetime-local
• [x] time
• [x] month
• [x] week

Other HTML5 types

• [x] url
• [x] tel
• [x] radio

Set this inputType to the field type attributes:

input( :type="schema.inputType")

[lionel-bijaoui]

Same thing should be done with slider field. It should be renamed "ion.rangeSlider" or "rangeSlider". Also a "radio" field ! Switch is cool, but sometime you need more the 2 values. And "tel" for a native masked/cleave for phone number only. Last one is "url". I would also like to point out that we need more HTML5 attributes:

• autofocus
• inputmode
• selectionDirection
• spellcheck

specific to text, search, tel, url or email:

• pattern
• size (also for password)

:boom: More HTML5! :boom:

[icebob]

HTML5 range is exist as fieldRange. I added the other types to the tasklist.

what is the size attr?

[lionel-bijaoui]

Yeah, sorry I forgot to remove that sentence.

size The initial size of the control. This value is in pixels unless the value of the type attribute is text or password, in which case, it is an integer number of characters. Starting in HTML5, this attribute applies only when the type attribute is set to text, search, tel, url, email, or password; otherwise it is ignored. In addition, the size must be greater than zero. If you don't specify a size, a default value of 20 is used. HTML5 simply states "the user agent should ensure that at least that many characters are visible", but different characters can have different widths in certains fonts; in some browsers, a certain string with x characters will not be entirely visible even if size is defined to at least x.

Source

I think the goal for v1.0.0 is to have all attributes exposed for native HTML5 fields.

[icebob]

I think, the size is not neccessary, because the default width is 100%. So it is overwrite the size attr. And you can change the width via styleClasses property in schema

[lionel-bijaoui]

Yes, but if you change the width via styleClasses and then, you may want to use it for some reason. I mean, it don't cost much to add, why not add it just in case someone needs it ?

[lionel-bijaoui]

@icebob We need a radio field, right ?

[icebob]

Yes, I added to the list.

[lionel-bijaoui]

I'm going to work on a html5 field based on input( :type="schema.inputType") One field for all native input. Check the html5 branch on the doc.

[icebob]

good solution, thanks!

[icebob]

I'm unsure with the inputType property. Currently easy and straightforward to create a simple text field in the schema:

{
  type: "text",
  label: "Name",
  model: "name"
}

but after this feature, it will be more complex and harder to read:

{
  type: "html5",
  inputType: "text",
  label: "Name",
  model: "name"
}

So I think would be good to stay the current format. But need to rewrite the getFieldType part: https://github.com/icebob/vue-form-generator/blob/master/src/formGenerator.vue#L108

It would be smarter. So it will try to search the field by the exact name (fieldText). If not found use the common html5 field and set the type to inputType.

[lionel-bijaoui]

I have a counter arguments: putting them under the "html5" umbrella avoid collision with other potential field name, especially since custom fields exist. It also simplify the documentation. HTML are well documented already, not need to explicitly redo it for each field. We only provide a shell for them and potentially future new HTML input fields.

Also most other fields use special properties already and it is not a big problem.

Maybe the name should change from "html5" to "native" "input" ?

{
  type: "input", // more explicit
  inputType: "text",
  label: "Name",
  model: "name"
}

EDIT I prefer to be explicit and not rely on a search function to determine the field type. It will add logic in multiple place, take a bit longer and could lead to unexpected behavior.

This fields is particular, because it is an interface to the native input elements. I understand that it change a bit different from what you have done so far, but I really believe my proposal is the best way to handle this. It will give people more control.
The other fields (text, email, number, etc) can coexist[1] for now, and maybe map type: "test" to type: "html5", inputType: "text" if you really think this is necessary.

[1] I think we need to deprecate them and maybe remove them from 1.0.0

[lionel-bijaoui]

@icebob I have edited my answer, I really hope I was able to convince you :smile:. I will soon do a PR (still need test) with my proposal, but it will use a new feature of github which allow you to modify directly my PR if you need to. EDIT: #70

[icebob]

I welcomed this new github feature. I think it is neccessary for contribution.

1. I don't want to reject my thoughts about searching, because it will affect only one function. I will try it.
2. My other confusion is the html5 type (Now I see you wrote it too). I think we need to change this field type to input instead of html5

[lionel-bijaoui]

Ok since #70 is done, what's left is:

• a radio thing
• rename datetime field to datetimePicker (break changes)
• rename slider field to rangeSlider (break changes)

I'm going to start with the renaming, since it is fast and easy

[icebob]

Great!

I updated first post, plus added "update docs" task

[lionel-bijaoui]

Ok, now are left radio thing and docs work. @icebob Do you think you could give me a little help with the doc ? or you don't have free time ? I understand if you don't have free time, this information will simply help me evaluate the time needed.

[icebob]

Nice! Thank you. Sorry, but currently I can't help, because I have a lot of work in my full-time job :( I hope one week and I will be more active with VFG :smile:

Btw: are we need radio field? Because It is useless if there is only one radio button. Need a list for multiple radio button, but to handle list we have many select* fields.

[lionel-bijaoui]

No pb, I understand. Maybe you could add me as a collaborator ? If you don't feel like it, I perfectly understand, this is your project and you have complete control over it.

I'm going to create a "radios" field ;) It will be close to "checklist" in a way, but sometime, you really need radio inputs.

[icebob]

A while ago, I'm thinking that I add you as a collaborator. Because you have a lot of hard work to improve this component, what I thank you. But I want to controlling the direction of development. So I will add you, but I will need to approve the PRs before merge, that I can check the changes, ok?

[lionel-bijaoui]

No problem, I would not like to push thing without your validation anyway :) I'm mainly going to use the kanboard and tag issues. Thank you for your trust.

[icebob]

@lionel-bijaoui Are you working anything from this issue?

[lionel-bijaoui]

Yes, I'm on the "radios" field. I can do a PR tomorrow if you want to help (I very busy at work lately). You could do the docs if you can.

[icebob]

Ok, I updated docs in html5 branch.

[lionel-bijaoui]

@icebob #80 I do the unit test and it's done EDIT: Done and merged ! I'm going to update the doc. Get ready to create a new release :)

[lionel-bijaoui]

@icebob I'm done with the doc !

[icebob]

Thanks! Tomorrow I will make the new release