Layout Editor
Created 6 years ago by ryanthompsonThe layout editor is coming along but wanted to put some ideas down here in HOW it will work.. I am in a battle vs more traditional form builder cycle vs tons of JS..
So the idea of the layout builder is that you can define 1 or more layouts per stream. A layout being basically the $structure for a form - based on stream and slug. So the default layout for Pages for example. This utility will let you customize it from the CP. So you can put your custom fields anywhere - reorder the existing fields / add tabs / rows / columns / etc within sections or add more sections and customize your form layout. The slug is so you can define multiple per stream in case you want to combine them / change them for whatever reason.
So where I am at now is a mixture of traditional request cycles and JS..
For example - add section (reloads), add tab (reloads), add field (modal -> select -> reloads), all dragging and dropping would be like pages - no reload. But then you'd want to save your ordering (obvious reload).
The reason being is so that we can rely on the underlying UI architecture to produce HTML. I started off using much much much more JS and it was not going to work well if I changed HTML / markup at all. Basically I'd have to mirror HTML / structure changes in JS as well..
Thoughts on this? All in all I think the workflow mentioned above will be a little slower but MUCH more stable and MUCH more maintainable and MUCH more versatile for other CP admin themes.
My 5 cents, release it that way. Let the community have a go at it. Then we can take it from there. I think i prefer that we rely as little as possible on JS until we have actually moved pyro backend to utilise VUE.
And second. I feel this release without too much js will be released faster. And we need this yesterday. And there is not anything stopping us from adding more js along the way if it's needed.
Behind layouts currently and possibly blocks. I REALLY really wanna get blocks out cause I am so sick of using Grids for it lol. Migrations and stuff copying around is kinda annoying.
Update on this item. Layout editor is still planned however we're pushing it back. We need to complete the BS4 update first as it will cleanup some of the controls around form UI.
So I've been thinking about this for a while. But I think a flex and 12 column grid assumption could REALLY help simplify this.
Currently all sections define the layout as a row and column structure. But what if we removed row column and did width per field so that they ARE the column. Then we can wrap to create new "rows". Then all we need is to define a width per field.
So for example if the first 3 fields had widths of (could use % too but will use grid sizing) let's say: 6, 6 and nothing. The first "row" would have the first two fields followed by an auto sized field since it's not defined that would default to 12. So skip rows entirely and assume wrapping and the UI for this also get's SUPER simple. Dead simple.
Any clarification on this needed? Does this make sense? No rows. Only widths, which means we can go straight to the field and not worry about complicated arrays of section layout.
And lastly where do we put this.. Could be a global config value like default_value is. Maybe call it row_width since width is a little ambiguous. But that's also kinda a bad idea because it's aggressive in that it'll apply to any form it appears in.
So maybe store it on the assignment.. still have assigned fields potentially in multiple forms though..
It might be best to keep it in CP for now.. until it solidifies more. Cause layout editing will include users being able to add tabs and more sections to forms as well. Not just this row/column aspect.
So the original layout spec above might still be correct - but the structure underlying it is vastly more simple now because no rows / columns as their own thing - it's inherited by field width within an assumed grid.
I dig it.
PS this and the other features like versions / statuses will be in Pyro 3.5 with Streams Platform 1.4