Feature Request - auto setup database data in new field definition #410

New Issue

Closed

opened 2019-04-26 16:57:37 +00:00 by jcodewalker · 7 comments

jcodewalker commented

2019-04-26 16:57:37 +00:00

(Migrated from github.com)

Hi Llewellyn,

What do you think to add an auto fill the fields in the database tab, in field definition, based on the field type selected?

I mean, there are several field type that use often the same database setting, like radio: tinyint, length 1, default 0...
You could add a tab, in field type definition, to set default database value to be used to pre-set the database tab in field definition. There the user can always change the values.
What do you think?

Hi Llewellyn, What do you think to add an auto fill the fields in the database tab, in field definition, based on the field type selected? I mean, there are several field type that use often the same database setting, like radio: tinyint, length 1, default 0... You could add a tab, in field type definition, to set default database value to be used to pre-set the database tab in field definition. There the user can always change the values. What do you think?

Llewellyn commented

2019-04-26 19:03:19 +00:00

Okay... give me the auto fill db values per field type, and I can see what would be the best path for implementation.

Llewellyn commented

2019-04-26 19:05:03 +00:00

I have looked at this before, can't now remember why it did not happen. But I agree it would be nice to have 👍

I have looked at this before, can't now remember why it did not happen. But I agree it would be nice to have :+1:

jcodewalker commented

2019-04-27 05:51:36 +00:00

(Migrated from github.com)

I'm not so expert and other can say different values, so I would say to use common sense.
What do you say about these?
type dbtype bdlength dbdefault
accesslevel: int 7 ''
calendar: datetime 50 ''
category: int 7 ''
checkbox: tinyint 1 0
checkboxes (prusume json encoded): text
color: varchar 7 ''
custom: int 11
customUser: int 11 0
editor : mediumtext
email: varchar 255 ''
file: varchar 255 ''
filelist: varchar 255 ''
folderlist: varchar 255 '' ?
hidden: int 1 0
integer: int 11 0
list: int 11 0
media: varchar 255 ''
menuitem: int 7 0
meter: int 11 0
number: int 11 0
password: varchar 255 ''
plugins: int 7 0
radio: tinyint 1 0
range: int 11 0
subform: mediumtext
tag: varchar 255 ''
tel: varchar 50 ''
text: varchar 255 ''
textarea: blob / text
timezone: int 7 0
url: varchar 255 ''
user: int 11 0
usergroup: int 11 0

I'm not so expert and other can say different values, so I would say to use common sense. What do you say about these? type dbtype bdlength dbdefault accesslevel: int 7 '' calendar: datetime 50 '' category: int 7 '' checkbox: tinyint 1 0 checkboxes (prusume json encoded): text color: varchar 7 '' custom: int 11 customUser: int 11 0 editor : mediumtext email: varchar 255 '' file: varchar 255 '' filelist: varchar 255 '' folderlist: varchar 255 '' ? hidden: int 1 0 integer: int 11 0 list: int 11 0 media: varchar 255 '' menuitem: int 7 0 meter: int 11 0 number: int 11 0 password: varchar 255 '' plugins: int 7 0 radio: tinyint 1 0 range: int 11 0 subform: mediumtext tag: varchar 255 '' tel: varchar 50 '' text: varchar 255 '' textarea: blob / text timezone: int 7 0 url: varchar 255 '' user: int 11 0 usergroup: int 11 0

Llewellyn commented

2019-04-27 08:44:35 +00:00

We realized that this may not be a problem with all field types, but just with some, and yet if just one does not work well in this direction of automation, then we can't trust it fully.

So at the time we ignored the issue and moved on. What to do now?

This seems to call for beginner and experienced developer difference in the actual behavior.

So what I think would serve as the best practice, is like you said at the first. Lets add the option to manually set these values in the field type (by default they will not be set). So that if they are not set, the user experience will remain the same as it is now. Yet if someone like you set them in the field type, then they will know what they have done, and we can be sure they are aware of the full implication.

Okay i will see when I can do this... let me know if this will work for you.

aaah now I remember why we did not set these, we had an internal debate about the possible unexpected behavior if the user does not emphatically set the database values them selves. Since then they may expect that JCB will set the values based on the field attributes, which it does not do, and so we will be forced to build a new set of helper methods to based on field attributes tweak the database values. This will happen since the database is on the second tab, which they do not see when creating the field, so we are actually forcing the user to set the database every time since that seemed like the most trusted way to insure correct implementation. Therefor the note given under those fields about being sure to set the database values correctly. We realized that this may not be a problem with all field types, but just with some, and yet if just one does not work well in this direction of automation, then we can't trust it fully. So at the time we ignored the issue and moved on. What to do now? This seems to call for beginner and experienced developer difference in the actual behavior. So what I think would serve as the best practice, is like you said at the first. Lets add the option to manually set these values in the field type (by default they will not be set). So that if they are not set, the user experience will remain the same as it is now. Yet if someone like you set them in the field type, then they will know what they have done, and we can be sure they are aware of the full implication. Okay i will see when I can do this... let me know if this will work for you.

jcodewalker commented

2019-04-27 08:53:56 +00:00

(Migrated from github.com)

That's right! 👍
Thanks!

That's right! 👍 Thanks!

Llewellyn commented

2019-05-02 23:01:35 +00:00

Okay @jcodewalker please test and let me know if it works as expected.

jcodewalker commented

2019-05-04 17:30:58 +00:00

(Migrated from github.com)

Hi,
Just installed this release and it works like a charm.
Now we only do a check in the database tab of new field, just to be sure everything fits the case and adjust if not.

Thank you.
claudio

Il giorno 03/mag/2019, alle ore 01:01, ((ewe))yn notifications@github.com ha scritto:

Okay @jcodewalker https://github.com/jcodewalker please test and let me know if it works as expected.

—
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/410#issuecomment-488862404, or mute the thread https://github.com/notifications/unsubscribe-auth/ALWXFT26UGXQLRFFOQYG3Z3PTNXFLANCNFSM4HIXQWHQ.

Hi, Just installed this release and it works like a charm. Now we only do a check in the database tab of new field, just to be sure everything fits the case and adjust if not. Thank you. claudio > Il giorno 03/mag/2019, alle ore 01:01, ((ewe))yn <notifications@github.com> ha scritto: > > Okay @jcodewalker <https://github.com/jcodewalker> please test and let me know if it works as expected. > > — > 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/410#issuecomment-488862404>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALWXFT26UGXQLRFFOQYG3Z3PTNXFLANCNFSM4HIXQWHQ>. >