Why are the rules on what layouts can be nested what they are?

Just curious about why Section Layouts cannot contain other Section/Form/Dashboard Layouts and so on for other Layout Components, is related to restrictions in the Java that backs SAIL forms or is it a best practices thing to try and keep interfaces from becoming excessively complicated?

I'm similarly interested why Forms and Dashboards cannot be contained in a list of items?

  Discussion posts and replies are publicly visible

Parents
  • The only two rules I know off the top of my head are:

    • a!formLayout cannot be embedded underneath any other layout type (i think this also applies to a!dashboardLayout, but i'd have to double check).  It must be the top position, which makes sense because the a!formLayout should reflect the entirety of whatever form the user is currently seeing, and any other subcomponents can be governed by using items contained in the formLayout.
    • a!sectionLayout cannot be a child of another a!sectionLayout.  I think this might be a bit of an outdated restriction at this point, going back to when forms and sections could only contain two columns and the experience was overall a lot more restrictive than now.  However I suspect they're keeping this restriction at least for now because even if you have sections nested, there are no graphical clues provided onscreen which hint at the hierarchy, as all sections appear in-line and roughly equivalent to each other (though this would get more complicated once you consider the issue of multiple columns).  AFAIK most use cases for having nested columns are currently handlable by just having subsequent, non-nested sections; and when you need nesting, we now have boxLayout which provides a pretty flexible and nice-looking alternative.
Reply
  • The only two rules I know off the top of my head are:

    • a!formLayout cannot be embedded underneath any other layout type (i think this also applies to a!dashboardLayout, but i'd have to double check).  It must be the top position, which makes sense because the a!formLayout should reflect the entirety of whatever form the user is currently seeing, and any other subcomponents can be governed by using items contained in the formLayout.
    • a!sectionLayout cannot be a child of another a!sectionLayout.  I think this might be a bit of an outdated restriction at this point, going back to when forms and sections could only contain two columns and the experience was overall a lot more restrictive than now.  However I suspect they're keeping this restriction at least for now because even if you have sections nested, there are no graphical clues provided onscreen which hint at the hierarchy, as all sections appear in-line and roughly equivalent to each other (though this would get more complicated once you consider the issue of multiple columns).  AFAIK most use cases for having nested columns are currently handlable by just having subsequent, non-nested sections; and when you need nesting, we now have boxLayout which provides a pretty flexible and nice-looking alternative.
Children
No Data