I’m working on a port of one of my PRs (#15146) to 3.x, as well as carrying through the TV form layout established in my recently-merged PR (#15773) to the other element editing forms. As I do this, it occurs to me that it would be beneficial to move the element code field (for templates, chunks, snippets, and plugins) into its own tab.
One of the things I’m realizing is that it’s a little irritating when you’re editing these bits of code on a regular basis to have to always scroll down to it. Aside from the benefit of having the code at the top of the page, since the forms are stateful you would be able to have the form open up with the code tab active by default (assuming that’s where you left off when last editing a particular element).
This is a pretty easy move to make; should I pursue doing it?
Hm, I don’t write code in the manager last years, but it sounds reasonable. Code is code, metadata is another thing. I assume that it also can be an intermediate step to moving elements to files from UI point of view.
The one reason I’d push (ever so lightly) for this for 3.0 is that it’d be ideal for the more visible changes (like this proposed one) to be introduced at the major version change. That said, I understand if you feel more consensus would be needed than can be gotten in the time before the feature freeze. (I do however believe that the change from a technical perspective is extremely easy.)
My only concern with this is if it is the primary/first tab, navigating the elements in the tree would be useless if you were trying to quickly review metadata.
Sounds good to me. I think, it should allways open the last opened tab, while navigating the elements in the tree (tab - state should be stored for the user).
@bruno17 - Yes, in terms of “stateful” … that’s what I mean.
All - There may be a disconnect with what I’m intending: What I’m proposing would not touch the tree, it would just add a tab in the form tabs (for those elements with a code field) and move the code field into that new tab.
No disconnect here. I’m just trying to make sure that if I click elements in the tree that I would be able to quickly see the metadata without having to switch tabs on every item.
OK, just wanted to be sure we’re on the same page . I would make it the second tab, so I think it would not be an issue in the context of the concern you have. Following the behavior of the TV form, where each individual TV maintains its form state, the other element forms could be made stateful as well — so if you tend to work with the metadata more that the other tabs, your forms would tend to open on that tab. Another thing I could do is add a system setting to toggle this stateful behavior off, in which case every element would always open to its first tab.
If the goal is consistency, I’d prefer to see more of the TV options (primarily input and output options) brought on to the main tab so there’s less need for switching when setting things up.
. I would make it the second tab, so I think it would not be an issue in the context of the concern you have. Following the behavior of the TV form, where each individual TV maintains its form state, the other element forms could be made stateful as well — so if you tend to work with the metadata more that the other tabs, your forms would tend to open on that tab. Another thing I could do is add a system setting to toggle this stateful behavior off, in which case every element would always open to its first tab.