Convert Field XML field definition to a subform (json) #258

New Issue

Closed

opened 2018-04-07 08:40:53 +00:00 by Llewellyn · 4 comments

Llewellyn commented

2018-04-07 08:40:53 +00:00

Owner

Steps to reproduce the issue

The idea is to move away from the xml [text area] concept and instead have a subform(repeatable) field with all the attributes and their default values loaded.

Expected result

The will speed-up the field building since we will start with an array/object of values and not a string. To make it even more easy to build fields.

Actual result

We are still doing intense string manipulation at the foundation of the field builder in the compiler, which is really not ideal.

Additional comments

We will rename the xml field to json. Then we will convert all field declarations in the xml field to a json objects and make the field hidden. Since we will load the subform via ajax and on save dynamical take the data and store it back into the hidden json field. This will insure we still have the easy fieldtype selection option that builds the default field.

I also would like to look at the idea of updating the DataBase settings to the most common for each fieldtype, so giving users an easy starting point if they are not sure of what those values should be.

### Steps to reproduce the issue The idea is to move away from the xml [text area] concept and instead have a subform(repeatable) field with all the attributes and their default values loaded. ### Expected result The will speed-up the field building since we will start with an array/object of values and not a string. To make it even more easy to build fields. ### Actual result We are still doing intense string manipulation at the foundation of the field builder in the compiler, which is really not ideal. ### Additional comments We will rename the xml field to json. Then we will convert all field declarations in the xml field to a json objects and make the field hidden. Since we will load the subform via ajax and on save dynamical take the data and store it back into the hidden json field. This will insure we still have the easy fieldtype selection option that builds the default field. I also would like to look at the idea of updating the DataBase settings to the most common for each fieldtype, so giving users an easy starting point if they are not sure of what those values should be.

ro-ot commented

2018-04-07 12:38:49 +00:00

(Migrated from github.com)

Author

Owner

This will be a very big change and will effect many functions. Do you have a list of all the areas that will need to be updated? Could we do this on a new branch as to not effect the stable branch?

Llewellyn commented

2018-04-09 05:50:06 +00:00

Author

Owner

So for now my proposal at this point is to keep the xml storage concept and just via the Ajax query load a subform that is used to model the field values but on save we map it back to the xml storage method and so in reality nothing changed, just the way the user/developer models the data.

Then in a later release when we are sure our subform field modelling method works well, we can take on the behemoth of converting all xml field storage values to the json objects.

This way it is smaller steps at a time and at-least we are going in the direction of making JCB more user friendly to non seasoned developers.

I actually do have a list, yet I have come to see that the main question is should we change the xml stored values at the same time or should we just change the field area, and still convert the values back to xml. This at least could be the first step, and later we can do the conversion of xml. So not to make implement the change all at once... but gradually over time move in that direction. So for now my proposal at this point is to keep the xml storage concept and just via the Ajax query load a subform that is used to model the field values but on save we map it back to the xml storage method and so in reality nothing changed, just the way the user/developer models the data. Then in a later release when we are sure our subform field modelling method works well, we can take on the behemoth of converting all xml field storage values to the json objects. This way it is smaller steps at a time and at-least we are going in the direction of making JCB more user friendly to non seasoned developers.

ro-ot commented

2018-04-13 19:10:52 +00:00

(Migrated from github.com)

Author

Owner

This does work better, and not doing it all at once was the right choice.

mwweb commented

2018-04-13 19:33:49 +00:00

(Migrated from github.com)

Author

Owner

I will test it over the weekend. Just adding final touches on my HUGE component, Total lines written: 152484, all done in JCB. Once that is done, I'll have free time, once again, provided no major errors are discovered.

🎉 1