HTML select object support on template fields

[ThoAppelsin]

About

We cannot prepare template fields that contains HTML <select> inputs, the support is just not there, yet. We need them for the dropdown input that would be very useful to our users while preparing templates.

To-do

• [x] Design an extension to JSON structure of data template fields, to support the <option>s of the <select>.
• [x] Find a way how a user may customize the <select> objects' <option>s, add, remove, and edit.
• [x] Implement those.
• [x] Update Documentation for the JSON Structure of Data Template Fields and Posts for the new fields and inputs.

[ThoAppelsin]

I think we can again transform the <select> into a <textarea> this time, and then let the user input the options they desire into lines of text.

Transforming the <select> into <textarea> would take its <option>s' texts and place them into the <textarea> separated by new lines. Transforming it back would generate <option>s with the text on those lines.

Not the most pleasant way to do it for the users, probably, but it would work, I think.

[ThoAppelsin]

Please, feel free to check the JSON schema in the documentation, and come up with the ideas to extend it to support the select field with flexible amount of ordered options.

Idea 1: The idea that comes to my mind is to add an array field called "options" inside the input objects. For an input object with "type" as "select", the "options" array would contain simple strings, all of which would be the textContent of the <option> objects within the <select> object.

How would you like this idea? Do you have any other ideas? Please, do contribute before we begin implementing on top of this design. Later on, the trouble of re-implementation would hold us from considering yours.

I plan to work on these as soon as I finish a couple of other works I have, and they have their deadlines on Tuesday.

[smddzcy]

Adding an options field to input sounds OK 👍 @triforce930 wdyt, would it be OK for the Android part as well?

[karacasoft]

I'm on the side of completely removing the inputs array. Why don't we add options array directly to the upper level of the structure?

Example:

{ "type" : "dropdown", "legend" : "Simple Dropdown", "options" : ["Option1", "Option2"] }

If this is not ok, then, yes, adding it to the input is OK.

[ThoAppelsin]

That is not okay, unless I miss something. How would you, say, represent the field of number/select input combination that will sooner or later is expected to be on our product?

[karacasoft]

Number/select input combination? A number input and a select input? How is this kind of an input will ever be expected? If you talk about currency, we can do something like this:

{ "type" : "currency", "legend" : "Cost" }

[ThoAppelsin]

Then how would you make a field for time input with time-zone selection?

[smddzcy]

@ThoAppelsin { "type" : "time-with-timezone", "legend" : "Time of sth" } 😄 Both are fine, but what we choose depends on our productization. Mahmut's way simplifies the app, but it limits the use cases. Your way makes the app complex, but it is more flexible. I'd choose whatever is simpler for us, we don't have enough muscle power to implement complex things.

[karacasoft]

There's no need for time-zone selection. Everyone should be able to enter time with their time-zone information. For other time-zones, the time should be converted to that time-zone.

If we REEALLY want to do that, we can do something like this:

{ "type" : "time", "legend" : "Time", "with_timezone_input" : true }

[ThoAppelsin]

This really does not seem to simplify it. Instead, makes things complicated. The logic we have to build will increases as new use-cases emerge (and we all know how easy it is for Suzan Uskudarli to come up with those).

On the other hand, what we currently have simply dictates the input types itself. The inputs array contains all the inputs, and each input with the type on its own defines itself. No "if field-type is this, generate input-types of these" kind of concerns, nothing.

In the end, I fail to see how the proposal simplifies the task. As far as I can tell, this proposal rather complicates the job.

I don't know how anyone could ever come up with an idea more simpler than mapping the front-end one-to-one with the data stored on the back-end. That is exactly the structure of the current JSON scheme: Fields hold a list of inputs, both at the front-end and the database. Inputs have types on their own, both at the front-end and the database. How is this any complicated?

And here's what the proposal does: Back-end speaks in a cryptic language, front-end (be it web or android) is to decipher it. When back-end says "currency", it actually is talking of a number input and a dropdown.

Why don't we just call our fields "A", "B", "C", etc.? Because, really, having to interpret "currency" as a number and a dropdown input with predefined list of currencies, is no different than interpreting "A" as the same. It will be like the back-end and the front-end has a language on their own.

[karacasoft]

The thing is, I don't want to generate complex set of inputs, it might have undesirable effects (like inputs may not fit on the screen), or maybe for date time input, I may not want to use a text box, I may want to use the native date picker component of the Android while implementing a date type field.

Back-end speaks in a cryptic language, front-end (be it web or android) is to decipher it.

This is true.

When back-end says "currency", it actually is talking of a number input and a dropdown.

This is wrong. In different platform, there may be ways to build the currency field in a much better way. The date example above describes it.

Why don't we just call our fields "A", "B", "C", etc.?

We can do that too, or use numbers so that we can get rid of the quotation marks as each of them eats one whole byte.

But, I'll simply give up here. I mean, I'll never know how you can find the energy to write these long paragraphs of text that I'll probably never fully read. I'll send the half-ready proposal to #169. Just so that it can stay in records. Then I'll close the issue and we can move on.

[ThoAppelsin]

I am just defending the option, of which I am yet to see any shortcomings, and that I still claim to be superior.

Web front-end also rather uses a date-picker, and not a text box, for the input of type date. It does so, because the type of input is given as "date" in the JSON, and not because it is the first input of the field of type "date-time" or "date-time-with-time-zone" or whatever.

What you would be able to do with the proposed change, you still can with the current scheme.

[karacasoft]

I said, we can move on...

Adding an options field to input sounds OK 👍 @triforce930 wdyt, would it be OK for the Android part as well?

Adding options to input is fine for me

[ThoAppelsin]

I have updated the documentation, and finally closing this.