Data template schema's are too complex for this simple application

[karacasoft]

About

Here's what we need to do:

• Display some form inputs in a given order.
• Display a set of input fields according to a given type name. (text field for short text, text area for long text, ...)

Defining the type of an entry and a label for that is simple enough. Why do we ever have to define a set of input fields that should be generated? They should be known by the underlying system. If we ever want to support custom entries, we can discuss that later and add it as an extra. We don't need to let users generate custom stuff for now.

tl;dr; inputs field is an overkill. We simply don't need it. Defining where the label will be seen is even worse.

[ThoAppelsin]

The comprehensiveness of the schema is not there to allow users to produce fields with custom inputs on their own. In fact, they can't and they never will be able to. We define and offer them the types of fields they can use, and they can either:

a) populate the inputs for the specific types of fields such as the multisel, b) edit their legend, c) or, if available, edit the labels of the inputs.

That is all they can, and will be able to do. We do the generation of the fields, and I defend that the current scheme helps us in doing that.

I am certain that flattening our JSON scheme down is a needless act to take now. Furthermore, I believe that this reduction will most likely limit us to a point that we may be unable to come up with some certain types of complex fields.

That being said, the side of the label could possibly be taken out. I don't think it will cause us a trouble to assume the side of the label for a given type of input.

If you disagree, then you are free to come up with a proposal. When you do, I would like to ask you for a day or two for all of us to think about what could go wrong with this reduction. If there is none, then we can put this on our list, on which I definitely hope to have it as a low priority issue.

[karacasoft]

The comprehensiveness of the schema is not there to allow users to produce fields with custom inputs on their own

Then it is there to confuse us. And maybe probably there for the multisel field.

I defend that the current scheme helps us in doing that.

With current scheme I have to know what I have to generate for each field. (It's not written on the documentation). If somehow, my code gets broken and I generate wrong fields, your code will never know the difference and accept it.

I am certain that flattening our JSON scheme down is a needless act to take now.

I certainly agree with that. But earlier we do it, we can manage our code better. In the later stages, data template code will be everywhere and refactoring will be almost impossible.

we may be unable to come up with some certain types of complex fields.

What type of complex field can we come up with?

If you disagree, then you are free to come up with a proposal.

I'll get a system proposal ready soon.

[karacasoft]

Data Template Schema

Template Field

A template field consists of three base fields. These fields are required and should be included in every single field definition.

Name	Description	Type
type	Defines what type of fields will be generated for this field.	enum
label	Defines the name of the field. This will be the visible label of the field.	string
order	Defines the order that this field will be seen. High order number fields will appear below low order number fields.	integer

In addition to the fields above, a data template field can include extra fields that come from the type of the field. We will mention these fields after.

Inputs generated by the type parameter can be platform specific. The descriptions below are given to give ideas about what the field will look like.

Values of 'type' field should be one of these:

• 'short_text' ----> Generates a simple text field with no input restriction.
• 'long_text' ----> Generates a text area field with no input restriction.
• 'numeric' ----> Generates a text field with only number input available.
• 'email' ----> Generates a text field with only email input available.
• 'url' ----> Generates a text field with only url input available.
• 'telephone' ----> Generates a text field with only telephone number input available.
• 'multi_sel' ----> Generates a list of check box inputs from the 'choices' parameter given to the field.
• 'single_sel' ----> Generates a dropdown field with inputs filled with the 'choices' parameter given to the field.

Template Field input restrictions can be done on frontend, but because a user can simply change the way frontend code works, input validation must be done on backend.

Template Fields may have extra parameters that define their behavior clearly. These parameters are mostly optional. Each input type has different set of extra parameters. So we will check them out one by one.

Short Text Field

This field in general, generates a basic text box with no input restrictions.

Extra Parameters:

Name	Description	Type
max_char (optional)	Restricts the number of characters entered into this field.	integer

Long Text Field

It is recommended for this field to generate a text box that supports multiple lines.

Extra Parameters:

Name	Description	Type
max_char (optional)	Restricts the number of characters entered into this field.	integer

Numeric Field

This field in general, generates a text box with only numeric input available.

Extra Parameters:

Name	Description	Type
min_val (optional)	Defines the minimum value that this field should take.	float
max_val (optional)	Defines the maximum value that this field should take.	float

Email Field

This field in general, generates a text box with only email input available. The email check can be done on frontend, but whatever the case is, it must be done on backend.

No Extra Parameters (We can maybe restrict the host of the email address, but I don't see any reason to do that)

URL Field

This field should generate a basic text box with only URL input available. Input format check should be done on backend. It can optionally be done on frontend, too.

No Extra Parameters

Telephone Field

This field is supposed to generate an input to be able to enter telephone numbers. But phone number format is not defined in this documentation. It can be checked for a specific format, or not be checked at all, which is risky.

No Extra Parameters

Multiple Select Field

This field is supposed to generate a list of check box inputs from a given list of strings in the extra parameter named 'choices'.

Extra Parameters:

Name	Description	Type
choices	Defines the list of choices that should be presented to the user by this field.	array of strings

Single Select Field

This field is may generate a dropdown list or a list of radio select buttons for the user. What to generate for this field is left to the implementor. List of choices is once again given via the extra parameter 'choices'.

Extra Parameters:

Name	Description	Type
choices	Defines the list of choices that should be presented to the user by this field.	array of strings

Some Examples

TODO