[EN] Creating Layouts in Rock (Draft)

[briankalwat]

How can we empower Rock users to create the layouts they need?

Hey guys! Below are some thoughts we've been formulating regarding layouts as we've been working on our Rock theme. They are by no means a "this is what we should do", but rather a conversation starter for us to discuss how we can improve layouts in Rock. It's fairly lengthy, so feel free to read it over, chew on it for a while and then ask questions, make suggestions, point out problems and the like. We, just like you, want to make Rock the best that it can be!

How Layouts Currently Work

1. Predefined layouts + Rock zones within an individual theme

<div class="row">
      <div class="col-md-3">
                <Rock:Zone Name="Sidebar 1" runat="server" />
      </div>
      <div class="col-md-9">
                <Rock:Zone Name="Main" runat="server" />
      </div>
</div>

<div class="row">
      <div class="col-md-12">
                <Rock:Zone Name="Section A" runat="server" />
      </div>
</div>

<div class="row">
      <div class="col-md-4">
                <Rock:Zone Name="Section B" runat="server" />
      </div>
      <div class="col-md-4">
                <Rock:Zone Name="Section C" runat="server" />
      </div>
      <div class="col-md-4">
                <Rock:Zone Name="Section D" runat="server" />
      </div>
</div>

2. Ability to extend/nest layouts with block-instance level lava template code

Issues

• Users are unable to make changes/create new layouts without writing code.
• Changes to Lava templates at the block-instance level are not carried back to a source file, which will make maintaining the consistency of layout changes a major issue over time.

How can we make it better?

1. Adding a block width field

By adding a block width field to the RockBlock class, users can create custom layouts without writing any code. We would limit the number of options for the sake of simplicity (halves, thirds, and quarters), and make the decisions on what each block width changes to at various breakpoints (ex: a 3 column block would become 6 columns at the small breakpoint, and 12 at the extra small), so the user only has to worry about the layout of a single breakpoint. Each block would then be output within a grid column, set to the width chosen by the user.

<div class="col-md-3 col-sm-6 col-xs-12">
      [ Block Contents ]
</div>

2. Limit theme layouts to high-level page segmentation

In order for this to all work consistently, it'd be best to limit layout themes to high-level page segmentation (two columns, three columns, full width, etc). Also, the gutters between layout columns need to exist at the block level, not in the layouts themselves. This would introduce the use of the flush/hard helper classes for removing negative margins and padding from layout-level bootstrap grid elements.

<div class="row flush">
      <div class="col-md-8 hard">
            <div class="row">
                  <Rock:Zone Name="Section A" runat="server" />
            </div>
      </div>
      <div class="col-md-4 hard">
            <div class="row">
                   <Rock:Zone Name="Section B" runat="server" />
            </div>
      </div>
</div>

3. Limit Lava templates to non-layout customization

In order for this to work, our layout grid elements need to all be set at the same level (layout/block model/block instance). Making changes on multiple levels is what introduces inconsistency, so we'd want to emphasize not using lava templates to make layout changes. Also, to improve consistency at the block-instance level, it would be ideal to have a filename attribute added to the lava editor, so changes can be copied back to a static file that can be shared across block instances.

[briankalwat]

@jonhorton @dcs619 @edolyne any thoughts on this?

[dcs619]

@briankalwat You'll want to mark the title with [EN] to indicate an enhancement.

Can you screenshot the hard/flush class differences in Better:2 so it's clear what it does?

Better:3 sounds super complicated, which I don't think was the original intent. Can you suggest the Lava editor has a FileName attribute that would sync to the file system? That by itself would solve a lot of inconsistency.