Bug in field size

mubeenraj commented

2019-10-30 14:30:36 +00:00

(Migrated from github.com)

Steps to reproduce the issue

Create a field in JCB, in the database tab, assign field size and then save the field. For example, simply create a Name field, give it VARCHAR (50) size and save the field.

Open the field again and you'll see that size information is not there i.e. JCB is not saving Size info.

Expected result

Field size information should be saved properly

Actual result

One Big issue is that when I'm creating the component, the same Field SIZE info is not copied to the SQL installation script and creating lots of troubles for me in installing the component. I've to manually edit the sql installation script to complete the component installation again and again.

System information (as much as possible)

OS Name & Version:
MySql Version:
Apache Version:
PHP Version: 7.2.11
Joomla Version: 3.9
JCB Version: 2.10.4
Browser:

Additional comments

### Steps to reproduce the issue Create a field in JCB, in the database tab, assign field size and then save the field. For example, simply create a Name field, give it VARCHAR (50) size and save the field. Open the field again and you'll see that size information is not there i.e. JCB is not saving Size info. ### Expected result Field size information should be saved properly ### Actual result One Big issue is that when I'm creating the component, the same Field SIZE info is not copied to the SQL installation script and creating lots of troubles for me in installing the component. I've to manually edit the sql installation script to complete the component installation again and again. ### System information (as much as possible) - OS Name & Version: - MySql Version: - Apache Version: - PHP Version: 7.2.11 - Joomla Version: 3.9 - JCB Version: 2.10.4 - Browser: ### Additional comments

Llewellyn commented

2019-10-30 20:08:25 +00:00

I have also noticed this, when creating a new field the size value is dropped, I will take a closer look and get back with a fix.

Llewellyn commented

2019-11-08 16:07:43 +00:00

Okay so it was fix in the last push to the staging branch, please test and let me know.

Llewellyn commented

2020-02-25 18:46:29 +00:00

@jcodewalker just mentioned that this issue is not resolved.

Llewellyn commented

2020-02-25 18:48:22 +00:00

@jcodewalker can you please give us more details of exactly what you are doing. Screenshot will be helpful. Since we do not see the same outcome.

jcodewalker commented

2020-02-26 08:32:27 +00:00

(Migrated from github.com)

Since you don’t see the same outcome I did go deep in the issue and I’ve discovered the trick.
To get the same result (at least it works for me), the field type (es: text) must not have a default database data settled. It means when you add a new text field, database data fields are not automatically populated but you have to do it manually. Then Save&Close, then open the new saved field and you should get the issue. If you set again the length and save it then it keeps the setting.

Even with”Fieldtype” I get the same issue when I set the database default data (first time), then once re-saved it keeps the setting.

Hope this helps

Since you don’t see the same outcome I did go deep in the issue and I’ve discovered the trick. To get the same result (at least it works for me), the field type (es: text) must not have a default database data settled. It means when you add a new text field, database data fields are not automatically populated but you have to do it manually. Then Save&Close, then open the new saved field and you should get the issue. If you set again the length and save it then it keeps the setting. Even with”Fieldtype” I get the same issue when I set the database default data (first time), then once re-saved it keeps the setting. Hope this helps

Llewellyn commented

2020-02-27 12:23:07 +00:00

Okay, got it... I also now see the issue. Weird... still debugging not sure what is the cause.

Llewellyn commented

2020-02-27 13:19:29 +00:00

ahaa found it, but wow it is a far larger issue then I thought.

Since it involves the actual JCB way of dealing with field conditions. See we have a common problem in web forms that if a field is required, it must both browser side and server side be required. Yet if the field is only required within the selection choices of other fields in the form we may hide the field at times and then it is not required. So bang... once you submit the browser could be told to allow this... and yet server side it would still complain.

There are two workarounds that are in use in the industry, first that you also have the same logic as the form in your validation class server-side that also based on active fields and selection maps required fields, and validates accordingly, second that you browser side build a second value set of field not required, that gets used server side to ignore fields. Well in Joomla the second option was the easiest way to implement, but with this option all not required fields must be emptied for security of course.

So now to this issue, the datalenght field gets added to this "not required" list, and therefore emptied an submission.

So why is this a larger issue, well the actual problem is how JCB builds its field conditions with Javascript. Joomla as improved in this area since JCB was created, and so we need to instead start moving JCB into a more Joomla way of dealing with field conditions, instead of this huge load of Javascript.

I can fix this for this implementation in this view, but we will have to think head, and make the change in this whole area actually.

ahaa found it, but wow it is a far larger issue then I thought. Since it involves the actual JCB way of dealing with field conditions. See we have a common problem in web forms that if a field is required, it must both browser side and server side be required. Yet if the field is only required within the selection choices of other fields in the form we may hide the field at times and then it is not required. So bang... once you submit the browser could be told to allow this... and yet server side it would still complain. There are two workarounds that are in use in the industry, **first** that you also have the same logic as the form in your validation class server-side that also based on active fields and selection maps required fields, and validates accordingly, **second** that you browser side build a second value set of field not required, that gets used server side to ignore fields. Well in Joomla the second option was the easiest way to implement, but with this option all not required fields must be emptied for security of course. So now to this issue, the `datalenght` field gets added to this _"not required"_ list, and therefore emptied an submission. So why is this a larger issue, well the actual problem is how JCB builds its field conditions with Javascript. Joomla as improved in this area since JCB was created, and so we need to instead start moving JCB into a more Joomla way of dealing with field conditions, instead of this huge load of Javascript. I can fix this for this implementation in this view, but we will have to think head, and make the change in this whole area actually.

jcodewalker commented

2020-02-27 13:28:55 +00:00

(Migrated from github.com)

Yes, I understand.

Really it’s not a big deal for me, JCB doesn’t allow to save the field without a length, so we can survive with this until all the area is managed in a more Joomla way.
I just need to keep it in mind to avoid another issue call in Github in the future… :-)

Thanks, have a nice day!

Yes, I understand. Really it’s not a big deal for me, JCB doesn’t allow to save the field without a length, so we can survive with this until all the area is managed in a more Joomla way. I just need to keep it in mind to avoid another issue call in Github in the future… :-) Thanks, have a nice day!

Llewellyn commented

2020-02-27 21:10:55 +00:00

This should at last be resolved, let me know.

jcodewalker commented

2020-02-29 08:46:30 +00:00

(Migrated from github.com)

Yes, fixed, I confirm.
Thanks!

Il giorno 27/feb/2020, alle ore 22:10, Llewellynvdm notifications@github.com ha scritto:

This should at last be resolved, let me know.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/vdm-io/Joomla-Component-Builder/issues/487?email_source=notifications&email_token=ALWXFT4HKMJIGBTXGG27NRLRFAT57A5CNFSM4JG2KVFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENF62AY#issuecomment-592178435, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALWXFT7UBBJVLWTCL7UXLNLRFAT57ANCNFSM4JG2KVFA.

Yes, fixed, I confirm. Thanks! > Il giorno 27/feb/2020, alle ore 22:10, Llewellynvdm <notifications@github.com> ha scritto: > > This should at last be resolved, let me know. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub <https://github.com/vdm-io/Joomla-Component-Builder/issues/487?email_source=notifications&email_token=ALWXFT4HKMJIGBTXGG27NRLRFAT57A5CNFSM4JG2KVFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENF62AY#issuecomment-592178435>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALWXFT7UBBJVLWTCL7UXLNLRFAT57ANCNFSM4JG2KVFA>. >

Bug in field size #487

Steps to reproduce the issue

Expected result

Actual result

System information (as much as possible)

Additional comments