Can layouts be handled better?

[jcc5018]

While your package does some great things, it can quickly become cumbersome when forms start getting huge. And it is not immediately obvious (for newer developers) how to break things down into more manageable chunks. I am wondering if there is a better way to tackle this for future versions of Filament.

Trying to figure out the differences between section, groups, etc, can get confusing, and then trying to find which level of the nested resource to attach the columns() designation is even worse.

Suggested Improvement

First thought would be to create a "Layout" page or function.

Something like

 public static function layout(Layout $layout): Layout
 {
 [
   row('full') =>[Insert('ActionButtons')],
  Tabs=> [
        tab1 =>[  
                     row(2/3+1/3) => [column( insert('main_content_form' ) + column(insert('status_form')], 
 
                     row('full') => [insert(TextArea::make('description')],
 
                     row(1/2+1/4+1/4) => [column (insert('model_infolist1') + column('insert('sample_widget') + column("insert('ActionButtons')],
 ], 
        tab2 => [
 //more layout elements
],
 
 ]

 
 }

 
 public function main_content_form: Form
 
 {
...FORM FIELDS...
}


 public function status_form: Form
 
 {
...FORM FIELDS...
}

 
 public function sample_widget: Widget
 
 {
...Widget Code...
}

///ETC

Explanation

The idea being, that each section can be defined independently and then referenced within the layout. Perhaps this is doable already, but I think the process could be cleaned up some

• Anything from forms, tables, widgets, infolist, related fields, Actions, pagination, etc

• Each form within the layout will reference the parent model, but each section can potentially be overridden with its own reference. with a ->model($model) designator.

  • Anything within a layout element defined with a different model, will reference that model or relationship

• Each element can be defined as a function within the same page, or referenced from an external location. Perhaps in sub folders for each element type.

I think separating the layout from the components within would be easier to visualize. Though my implementation may need to be improved.

Panel management

Consider a "menu" element where users can define the order of resources/pages, instead of within the resource itself

Sample

public function menu (Menu $menu0: Menu
{
return [ 
logo,
search field -> closure,
'heading 1' => [ Resource1, Resource 2, Resouce 3],
'heading 2' => [Resource 4, Page 1, Page 2]
'heading 3' => [External link, Laravel route, Resource 5]

Potential File Structure

Elements can be defined within the panel, or if elements are reusable within multiple panels, then they can be in a common folder.

• Filament
  • Panels
    • Config (define if an over aching or single instance panel, set theme, etc) - Currently in providers directory
    • Resources (has index, edit, create options defined
    • Pages
    • Forms
    • Tables
    • Modals
    • Widgets
    • RelatedResources
      • Tables
      • Forms
    • Views (info lists)
  • Common
    • Actions
    • Forms

Summary

• At its core, layouts should really be defined via row, and columns.

  • Columns can be set in any fraction of 12.

  • rows, and columns can be set within pages, tabs, modal, or slide out elements

  • if fraction designation is not set, set all defined columns equal size with gap.

    • (row(1/2 ) -> column (content) + Column( content) + column (content) would produce the first column at half width and the other 2 columns split equally in remaining space)

  • columns can define a minWidth to stack elements if no space

  • columns can define order and reference the typical breakpoints (md:order-0, lg:order-1, etc)

• Panels can contain pages, pages can contain tabs, or single page layouts,

• Panels can manage all models, or single instances of a model (think settings pages for individual organizations, or users