Feature request - View's fields grouped by tab #411

New Issue

Closed

opened 2019-04-27 07:42:41 +00:00 by jcodewalker · 6 comments

jcodewalker commented 2019-04-27 07:42:41 +00:00 (Migrated from github.com)

Copy Link

Hi Llewellyn,

I don't know if this is a need only mine... but what would you say to manage the view's field with nested subforms?

Example: in a view I set (let's say) 5 tabs and today I have to set all fields in just 1 subform (whichever is the tab they are referred to). There, I have to set db fields, backend config fields and even menu item(s) options, not to mention notes and spacer fields.

With complex project it's easy (for my works) to have something like 60 or more fields. And when the customer asks for a change it is a little bit more complex than what it could be.

What do you say to manage the view fields a little bit different?

In view setting, when adding tabs, we should be able to set if that tab is for backend (config/options), backend edit form, front-end form (which can be different from the backend) , menu item or the possible combinations between them (managed with checkboxes?).

Then, in view's fields tab, we should have a subform, let's call it tabs-container, with two fields: a list field containing all the tabs settled in view's setting tab we can choose from, and a subform field with the current options (less the tab the field is referred to, obviously).

In this way all the fields are grouped by tab, and each tab has its own display setting.
More over, I can use the same field for different scope and different project. I can have need to use a field in the backend only in a project but the need to use the same field in the front end in another view or project. Today I need to have the same field multiple times, with different extra-property-display setting. If something changes (with the project or Joomla's code) I have to manage the same field for all the "copies". In a brief time I have tons of identical fields with different display setting.

To refine more the field/tab/display options management, I would say to allow view's setting to manage tabs for view's backend edit form, front end form and menu item display only (aren't we in the view environment?).

Then, in project setting tab, we should have a new button to add tabs (for component's option/config display only), and a new 'config' tab (or 'options' tab) where to set the fields for component config display only.

In this way I would say JCB would reflect even more what a Joomla developer is already used to, improving significantly the learning process.

What do you say?
Thanks.

Hi Llewellyn, I don't know if this is a need only mine... but what would you say to manage the view's field with nested subforms? Example: in a view I set (let's say) 5 tabs and today I have to set all fields in just 1 subform (whichever is the tab they are referred to). There, I have to set db fields, backend config fields and even menu item(s) options, not to mention notes and spacer fields. With complex project it's easy (for my works) to have something like 60 or more fields. And when the customer asks for a change it is a little bit more complex than what it could be. What do you say to manage the view fields a little bit different? In view setting, when adding tabs, we should be able to set if that tab is for backend (config/options), backend edit form, front-end form (which can be different from the backend) , menu item or the possible combinations between them (managed with checkboxes?). Then, in view's fields tab, we should have a subform, let's call it tabs-container, with two fields: a list field containing all the tabs settled in view's setting tab we can choose from, and a subform field with the current options (less the tab the field is referred to, obviously). In this way all the fields are grouped by tab, and each tab has its own display setting. More over, I can use the same field for different scope and different project. I can have need to use a field in the backend only in a project but the need to use the same field in the front end in another view or project. Today I need to have the same field multiple times, with different extra-property-display setting. If something changes (with the project or Joomla's code) I have to manage the same field for all the "copies". In a brief time I have tons of identical fields with different display setting. To refine more the field/tab/display options management, I would say to allow view's setting to manage tabs for view's backend edit form, front end form and menu item display only (aren't we in the view environment?). Then, in project setting tab, we should have a new button to add tabs (for component's option/config display only), and a new 'config' tab (or 'options' tab) where to set the fields for component config display only. In this way I would say JCB would reflect even more what a Joomla developer is already used to, improving significantly the learning process. What do you say? Thanks.

Llewellyn commented 2019-04-27 08:29:33 +00:00

Copy Link

I actually do not follow your explanation. So I would ask that you give screenshots or a video tutorial explaining this.

Before you do, it could be that JCB already does what you are looking for and so you may need to learn the correct approach... Then even more to change how JCB links fields are not that simple as moving a few fields around in the GUI. There are many systems build upon the current implementation, systems that you may not even be aware exist at this time. Since JCB is a treasure trove, as you study the compiler you will be dumb struck at all the dynamic functions (basic AI). Remember the majority of the tutorials made up until now just cover the basic concepts of JCB :)

But okay please give some screen shots and clear drawings of the change you think will be helpful and then we can look at this again. The reason for this, is the fact that so many things in JCB and Joomla has the same names in different areas, which makes it hard to communicate in plain text documentation. That is why I make tutorials... this gets everyone on the same page much faster.

I actually do not follow your explanation. So I would ask that you give screenshots or a video tutorial explaining this. Before you do, it could be that JCB already does what you are looking for and so you may need to learn the correct approach... Then even more to change how JCB links fields are not that simple as moving a few fields around in the GUI. There are many systems build upon the current implementation, systems that you may not even be aware exist at this time. Since JCB is a treasure trove, as you study the compiler you will be dumb struck at all the dynamic functions (basic AI). Remember the majority of the tutorials made up until now just cover the basic concepts of JCB :) But okay please give some screen shots and clear drawings of the change you think will be helpful and then we can look at this again. The reason for this, is the fact that so many things in JCB and Joomla has the same names in different areas, which makes it hard to communicate in plain text documentation. That is why I make tutorials... this gets everyone on the same page much faster.

jcodewalker commented 2019-04-27 09:00:28 +00:00 (Migrated from github.com)

Copy Link

I understand you at 100%, believe me. I was concerned to be perceived as not respecting all the work behind JCB but, believe it or not, I'm very aware of it. At the same time the more the project is complex the more JCB can help.

So here we are:

This picture is how I intend the fields tab to be.

If it makes sense for you too, I'll do the other pictures to full explain.

If JCB already does it... GREAT! lead me to the right video, please.
Thanks.

I understand you at 100%, believe me. I was concerned to be perceived as not respecting all the work behind JCB but, believe it or not, I'm very aware of it. At the same time the more the project is complex the more JCB can help. So here we are:  This picture is how I intend the fields tab to be. If it makes sense for you too, I'll do the other pictures to full explain. If JCB already does it... GREAT! lead me to the right video, please. Thanks.

Llewellyn commented 2019-04-27 09:20:29 +00:00

Copy Link

Okay you build the tabs on the adminn view and add the tabs to the fields... hmm that is how it works now.

So you see the field called admin tabs is the selection option for the tabs.

Okay so please explain more :) if you are going another direction with this. At this point the only benefit is less selection, but the down side is huge changes to the compiler, so I will need some more motivation here.

Okay you build the tabs on the adminn view and add the tabs to the fields... hmm that is how it works now.   So you see the field called `admin tabs` is the selection option for the tabs. Okay so please explain more :) if you are going another direction with this. At this point the only benefit is less selection, but the down side is huge changes to the compiler, so I will need some more motivation here.

jcodewalker commented 2019-04-27 10:58:23 +00:00 (Migrated from github.com)

Copy Link

I totally understand you and thanks for you attention.

Ok, let's see if I have completed the process.

admin view: create new tab:

Here we decide where the tab will be displayed (not the single field).

Component setting tab:

New button to create/add new config tab.

Component create new config tab process:

As this tab will only be displayed in component's config view doesn't require any more control.

Now, if I'm not wrong, fields do not require the display option anymore as they can be displayed anywhere depending on the tab they are included in.

Component's config are where a Joomla developer would look in, in component configuration environment. The order is determined by the tabs ordering.

View's fields are grouped by tab and there we can have a right idea of what is displayed where.
As the fields are now display independent, we can use the same field in more tabs which are displayed in different way.

Does it make sense?

I totally understand you and thanks for you attention. Ok, let's see if I have completed the process. admin view: create new tab:  Here we decide where the tab will be displayed (not the single field). Component setting tab:  New button to create/add new config tab. Component create new config tab process:  As this tab will only be displayed in component's config view doesn't require any more control. Now, if I'm not wrong, fields do not require the display option anymore as they can be displayed anywhere depending on the tab they are included in. Component's config are where a Joomla developer would look in, in component configuration environment. The order is determined by the tabs ordering. View's fields are grouped by tab and there we can have a right idea of what is displayed where. As the fields are now display independent, we can use the same field in more tabs which are displayed in different way. Does it make sense?

Llewellyn commented 2019-04-27 18:02:19 +00:00

Copy Link

Sorry @jcodewalker I am afraid this is not going to happen anytime soon.

I appreciate your suggestions, but with relation to this one there is no real major improvement to JCB. All the features already exist, just in a different way. You should also realize that moving these at this stage will inevitably cause bugs and other pains towards those who have been using it in the way it already works.

So lets go over this, the config fields are set per component, and that may be a pain, but is really the best way as its implementation is able to reach down into the menu of a site view, and even any other area in your component. That being said, the idea to have config that is linked to a view and therefore added to any component that uses that view is not bad. So we keep that idea in the shelf and see if we can get that done after J4 and all that comes with those changes.

Then the option to tweak the show of fields with relation the the config, on the component level can be handy but hey doing this on a field level as it is now, is not that much worse. Reality is that you can very easy copy a field and change its attributes for a second implementation.

Then when working with custom fields, you can use one custom code placeholder between various versions of the same custom code. Secondly there is a prime switch in the custom fields that allows you to set one of those fields as the prime, to insure its code is what gets used for all fields with the same custom field type. (if al is added to the same component)

Then their is the whole reality of a custom tab implementation, which already has huge powerful features.

Then we need to really think about individual tab permissions, as we already have permissions down the the field level, yet the idea to add a permission switch to tabs is actually the one idea that I think we can explore. But it also will need to take a back seat... as there are some other more important stuff in the todo list for now. Yet if I get the time... I will bump that in 👍

So in short config will for now stay in the component view as it is, and the switch to turn off the field from showing in the global options or just the menu options is done on field level. Let me know if you don't know how this is done. Just that you know if you use that field in a admin view as well as in the config, they are independent and the show in global options or menu is just in relation to the config fields, and ignored when the same field is used in a normal admin view.

I am closing this issue, but you are welcome to continue the communication about this over here, and would I add any of these ideas I will reference this issue 👍

Sorry @jcodewalker I am afraid this is not going to happen anytime soon. I appreciate your suggestions, but with relation to this one there is no real major improvement to JCB. All the features already exist, just in a different way. You should also realize that moving these at this stage will inevitably cause bugs and other pains towards those who have been using it in the way it already works. So lets go over this, the config fields are set per component, and that may be a pain, but is really the best way as its implementation is able to reach down into the menu of a site view, and even any other area in your component. That being said, the idea to have config that is linked to a view and therefore added to any component that uses that view is not bad. So we keep that idea in the shelf and see if we can get that done after J4 and all that comes with those changes. Then the option to tweak the show of fields with relation the the config, on the component level can be handy but hey doing this on a field level as it is now, is not that much worse. Reality is that you can very easy copy a field and change its attributes for a second implementation. Then when working with custom fields, you can use one custom code placeholder between various versions of the same custom code. Secondly there is a prime switch in the custom fields that allows you to set one of those fields as the prime, to insure its code is what gets used for all fields with the same custom field type. (if al is added to the same component) Then their is the whole reality of a custom tab implementation, which already has huge powerful features. Then we need to really think about individual tab permissions, as we already have permissions down the the field level, yet the idea to add a permission switch to tabs is actually the one idea that I think we can explore. But it also will need to take a back seat... as there are some other more important stuff in the todo list for now. Yet if I get the time... I will bump that in :+1: So in short config will for now stay in the component view as it is, and the switch to turn off the field from showing in the global options or just the menu options is done on field level. Let me know if you don't know how this is done. Just that you know if you use that field in a admin view as well as in the config, they are independent and the show in global options or menu is just in relation to the config fields, and ignored when the same field is used in a normal admin view. I am closing this issue, but you are welcome to continue the communication about this over here, and would I add any of these ideas I will reference this issue :+1:

jcodewalker commented 2019-04-27 18:15:33 +00:00 (Migrated from github.com)

Copy Link

Thank you for your time, first of all.

I understand everything and even all your concerns, so keep it up, bro.

Have anice sunday.
claudio

Il giorno 27/apr/2019, alle ore 20:02, ((ewe))yn notifications@github.com ha scritto:

Sorry @jcodewalker https://github.com/jcodewalker I am afraid this is not going to happen anytime soon.

I appreciate your suggestions, but with relation to this one there is no real major improvement to JCB. All the features already exist, just in a different way. You should also realize that moving these at this stage will inevitably cause bugs and other pains towards those who have been using it in the way it already works.

So lets go over this, the config fields are set per component, and that may be a pain, but is really the best way as its implementation is able to reach down into the menu of a site view, and even any other area in your component. That being said, the idea to have config that is linked to a view and therefore added to any component that uses that view is not bad. So we keep that idea in the shelf and see if we can get that done after J4 and all that comes with those changes.

Then the option to tweak the show of fields with relation the the config, on the component level can be handy but hey doing this on a field level as it is now, is not that much worse. Reality is that you can very easy copy a field and change its attributes for a second implementation.

Then when working with custom fields, you can use one custom code placeholder between various versions of the same custom code. Secondly there is a prime switch in the custom fields that allows you to set one of those fields as the prime, to insure its code is what gets used for all fields with the same custom field type.

Then their is the whole reality of a custom tab implementation, which already has huge powerful features.

Then we need to really think about individual tab permissions, as we already have permissions down the the field level, yet the idea to add a permission switch to tabs is actually the one idea that I think we can explore. But it also will need to take a back seat... as there are some other more important stuff in the todo list for now. Yet if I get the time... I will bump that in 👎

So in short config will for now stay in the component view as it is, and the switch to turn off the field from showing in the global options or just the menu options is done on field level. Let me know if you don't know how this is done. Just that you know if you use that field in a admin view as well as in the config, they are independent and the show in global options or menu is just in relation to the config fields, and ignored when the same field is used in a normal admin view.

I am closing this issue, but you are welcome to continue the communication about this over here, and would I add any of these ideas I will reference this issue 👍

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

Thank you for your time, first of all. I understand everything and even all your concerns, so keep it up, bro. Have anice sunday. claudio > Il giorno 27/apr/2019, alle ore 20:02, ((ewe))yn <notifications@github.com> ha scritto: > > Sorry @jcodewalker <https://github.com/jcodewalker> I am afraid this is not going to happen anytime soon. > > I appreciate your suggestions, but with relation to this one there is no real major improvement to JCB. All the features already exist, just in a different way. You should also realize that moving these at this stage will inevitably cause bugs and other pains towards those who have been using it in the way it already works. > > So lets go over this, the config fields are set per component, and that may be a pain, but is really the best way as its implementation is able to reach down into the menu of a site view, and even any other area in your component. That being said, the idea to have config that is linked to a view and therefore added to any component that uses that view is not bad. So we keep that idea in the shelf and see if we can get that done after J4 and all that comes with those changes. > > Then the option to tweak the show of fields with relation the the config, on the component level can be handy but hey doing this on a field level as it is now, is not that much worse. Reality is that you can very easy copy a field and change its attributes for a second implementation. > > Then when working with custom fields, you can use one custom code placeholder between various versions of the same custom code. Secondly there is a prime switch in the custom fields that allows you to set one of those fields as the prime, to insure its code is what gets used for all fields with the same custom field type. > > Then their is the whole reality of a custom tab implementation, which already has huge powerful features. > > Then we need to really think about individual tab permissions, as we already have permissions down the the field level, yet the idea to add a permission switch to tabs is actually the one idea that I think we can explore. But it also will need to take a back seat... as there are some other more important stuff in the todo list for now. Yet if I get the time... I will bump that in 👎 > > So in short config will for now stay in the component view as it is, and the switch to turn off the field from showing in the global options or just the menu options is done on field level. Let me know if you don't know how this is done. Just that you know if you use that field in a admin view as well as in the config, they are independent and the show in global options or menu is just in relation to the config fields, and ignored when the same field is used in a normal admin view. > > I am closing this issue, but you are welcome to continue the communication about this over here, and would I add any of these ideas I will reference this issue 👍 > > — > 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/411#issuecomment-487307370>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALWXFT7DFJRMVLQDH2UT7SLPSSILBANCNFSM4HI3V2VQ>. >

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

5.x

4.x

3.x

master

staging

v5.0.1-alpha2

v4.0.1-alpha2

v3.2.2-alpha2

v3.2.2-alpha1

v4.0.1-alpha1

v5.0.1-alpha1

v5.0.0

v4.0.0

v3.2.1

v3.2.0

v3.1.28

v3.1.27

v3.1.24

v3.1.19

v3.1.17

v3.1.15

v3.1.12

v3.1.11

v3.1.10

v3.1.9

v3.1.8

v3.1.7

v3.1.6

v3.1.5

v3.1.4

v3.1.3

v3.1.2

v2.13.1

v2.13.0

v2.12.16

v2.12.15

v2.12.14

v2.12.10

v2.12.9

v2.12.8

v2.12.7

v2.12.6

v2.12.4

v2.12.3

v2.12.2

v2.11.7

v2.11.4

v2.11.3

v2.11.2

v2.11.0

v2.10.13

v2.10.11

v2.10.9

v2.10.5

v2.10.1

v2.10.0

v2.9.21

v2.9.18

v2.9.14

v2.9.11

v2.9.10

v2.9.8

v2.9.7

v2.9.1

v2.9.0

v2.8.5

v2.8.4

v2.8.2

v2.8.0

v2.7.10

v2.7.7

v2.7.6

v2.7.5

v2.7.4

v2.7.1

v2.7.0

v2.6.17

v2.6.16

v2.6.15

v2.6.14

v2.6.13

v2.6.12

v2.6.11

v2.6.10

v2.6.9

v2.6.8

v2.6.7

v2.6.6

v2.6.5

v2.6.3

v2.6.2

v2.6.1

v2.6.0

v2.5.8

v2.5.6

v2.5.5

v2.5.4

v2.5.1

v2.5.0

v2.4.10

v2.4.9

v2.4.8

v2.4.7

v2.4.6

v2.4.5

v2.4.4

v2.4.3

v2.4.2

v2.4.1

v2.4.0

v2.3.10

v2.3.9

v2.3.8

v2.3.7

v2.3.6

v2.3.5

v2.3.4

v2.3.2

v2.3.1

v2.3.0

v2.2.10

v2.2.9

v2.2.6

v2.2.5

v2.2.4

v2.2.3

v2.2.2

v2.2.0

v2.1.21

v2.1.20

v2.1.19

v2.1.18

v2.1.17

v2.1.16

v2.1.14

v2.1.13

v2.1.12

v2.1.11

v2.1.10

v2.1.9

v2.1.8

v2.1.7

v2.1.6

v2.1.5

v2.1.4

v2.1.3

v2.1.2

v2.1.1

v2.1.0

v2.0.9

v2.0.8

Labels

Clear labels   

Beta

Issues related to the a beta release

  

Bug

  

Documentation

  

enhancement

  

help wanted

  

invalid

  

joomla

Joomla related changes

  

question

  

URGENT

  

wontfix

No Label

Beta

Bug

Documentation

enhancement

help wanted

invalid

joomla

question

URGENT

wontfix

Milestone

Clear milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

No Assignees

1 Participants

Notifications

Subscribe

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: joomla/Component-Builder#411

No description provided.