Communication requirements and format backend vs. frontend [#1682906]

I've been thinking a lot following our layout meeting late yesterday about what kind of things we need to communicate, and here is a starter proposal for discussion:

1. Communicate the name and numeric value of breakpoints (steps):

   320px: smartphone, 780px: tablet, 960px: standard

2. Communicate the layout with its wrappers (this is the same for all steps, so just one):

  <wrapper machine_name="w1">
    <region machineName="a" label="A" />
    <region machineName="b" label="B" />
    <region machineName="c" label="C" />
    <region machineName="d" label="D" />
    <region machineName="e" label="E" />
   </wrapper>
   <region machineName="f" label="F" />

3. Communicate the layout characteristics belonging to each machine name vs. step. The above markup can be used to build various layouts, some examples:

-----A -----B --------C    F
----------------------D    |
----------------------E    |

F  -----A -----B ---------C
|   ----------------------D
|   ----------------------E

-----A -----B --------C
----------------------D
----------------------E
----------------------F

-----A ------B
-----C ------D
-------------E
-------------F

-----A -----B  F
---C --D ---E  |

We need the associated "grid classes" for each wrapper and region per each step, so for example (for a 16 column grid):

grid_classes:
  960:
    w1: span12, left
    a: span3
    b: span3
    c: span3
    d: span12
    e: span12
    f: span4, right
 780:
   ....

etc.

4. If we allow the user to build their own grid, we need to communicate the grid properties to the server so it can build the required CSS either by applying the right classes on the right regions or by generating CSS for the regions based on styles it would otherwise associate with the grid classes. This really depends on how much detail we let the user to configure, and the above classes depend on this obviously.

While I used a human readable list for 1, XML for 2 and a nested (JSON like) structure for 3, we can nest all this in a unified JSON payload (no need for XML).

Opinions?

Comment	File	Size	Author
#9	LayoutsVSOtherObjectsCurrent.png	225.81 KB	gábor hojtsy
#7	LayoutObjectThinking.png	217.4 KB	gábor hojtsy
#7	LayoutsVSOtherObjects.png	177.64 KB	gábor hojtsy

Comments

Comment #0.0

gábor hojtsy

he/him

Hungarian

Hungary

commented 13 July 2012 at 15:23

Issue summary:

View changes

Add code tags.

Comment #0.1

gábor hojtsy

he/him

Hungarian

Hungary

commented 13 July 2012 at 15:24

Issue summary:

View changes

Line up layouts.

Comment #1

gábor hojtsy

he/him

Hungarian

Hungary

commented 13 July 2012 at 15:27

As per more discussion with Jesse Beach and @tkoleary, we might be better off with abstracting the grid building out of this tool and have a common grid for your site instead of per-layout.

Comment #2

andypost

he/him

Russian

commented 16 July 2012 at 21:46

Common grid for site and sane layout builder for using grid sizes is enough. In perfect world this tool should have ability to import|export svg (or a kind of structured format) right from|into any vertor editor a-la Ilustrator or Fireworks

Comment #3

gábor hojtsy

he/him

Hungarian

Hungary

commented 17 July 2012 at 17:09

@andypost: Thanks for the feedback. Indeed, an svg to layout conversion is not currently in the plans. We are focusing on initially building the functionality. I think it is a possibility for the more distant future.

Comment #4

lslinnet commented 20 July 2012 at 17:36

I would recommend going in a direction where the layout of a specific page and the setup of break point & grid settings are seperated.
In the sense that it is possible to create a specific set of break points and grid settings for one page, but those settings would then be resuable on the next page you will be layouting.

Comment #5

jessebeach commented 24 July 2012 at 14:50

Issue tags:

+custom layouts

@lslinnet, listed below is the client-side data structure we have so far.

By default, a layout is a full-width stack of regions. Steps wrap a layout in a context. Each layout is by default wrapped in a step that spans 0 to ∞. Within a step the width of the regions can be altered. A grid, applied to a step, provides a framework to snap region widths to.

Hopefully this keeps the three aspects of a layout fairly separated. What do you think?

{
  'regions': [
    {
      'machine_name': 'header_a',
      'label': 'Header A'
    },
    {
      ...
    }
  ],
  /* A layout is a series of overrides on a basic RegionList. */
  'steps': [
    {
      'label': 'Phone',
      'machine_name': 'small',
      'breakpoint': '0',
      // Machine name of the grid applied at this step.
      'grid': 'gridpak_3',
      // Overrides that reduce the full-width default of a region.
      'regions':[
        {
          'machine_name': 'header_a',
          'columns': 1
        },
      {
          ...
        }
      ]
    },
    {
      ...
    }
  ],
  'grids': [
    {
      'machine_name': 'gridpak_3',
      'columns': 3
    },
    {
      ...
    }
  ]
}

Comment #6

andypost

he/him

Russian

commented 25 July 2012 at 10:35

Currently the most confusing thing in panels flexible builder is a way to place a region. It's really hard to describe that there's a rows in columns but rows could contain other columns or regions and there's no way to change it back.

So #5 describes a special case with grids and steps but I think this part should be variable each layout could contain another meta-information (context of doc-type or custom layout properties).

The static part of layout should describe:
1) regions - machine name, label and ref to properties
2) region wrappers - a kind of html tag to use and properties (classes array for ex)

Comment #7

gábor hojtsy

he/him

Hungarian

Hungary

commented 25 July 2012 at 12:08

Status	File	Size
new	LayoutsVSOtherObjects.png	177.64 KB
new	LayoutObjectThinking.png	217.4 KB

So #5 describes a special case with grids and steps but I think this part should be variable each layout could contain another meta-information (context of doc-type or custom layout properties).

Well, there are two extreme ends, and there are good reasons to separate regions, breakpoints, grids and layouts. Here is a visual summary of our thinking to separate them:

Which makes the layouts be informed by many other object types:

Of course the separation of things makes it harder to ensure that inter-dependent config is correct. Eg. if you import a layout that has things defined for breakpoints not on your system, what should the system do? Not import it and complain? Import it and discard the non-interpretable setting? It also makes it important that regions, grids, breakpoints and layouts are equally exportable and stageable, so that explains why have we been moving toward ctools data management for grids/breakpoints lately for example. (There are some UI gaps for regions that I'm trying to find help with: https://twitter.com/gaborhojtsy/status/227902616359809024 :).

So the reason I explained it in this detail here is because it has direct impact on the communication formats. If all these objects are independently configured and stored, then we should only refer to them by their machine name within each other. The regions, grids and breakpoints could be really independent, while the layout brings them altogether (see above figure).

All of this is evolving currently, so nothing is set in stone yet :)

Comment #8

jessebeach commented 25 July 2012 at 12:14

@andypost, right right. We need to make sure we've got adequate HTML hooks for styling and such. That kind of stuff should be easy to add in once we have the skeleton in place.

Comment #9

gábor hojtsy

he/him

Hungarian

Hungary

commented 25 July 2012 at 12:20

Status	File	Size
new	LayoutsVSOtherObjectsCurrent.png	225.81 KB

Just for a reality-check so you can compare the above to the current implementation:

We currently have 3 things: regions, grids/breakpoints (combined) and layouts. We did not separate grids/breakpoints yet and also the layouts do not define a subset of grids/breakpoints used, because we assumed for simplicity so far that the grid CSS uses separately identifiable classes for each grid, so you can "class up" your regions with grid classes for each grid/breakpoint appropriately.

So those are the gaps between the shiny plans and the current reality.

Comment #10

gábor hojtsy

he/him

Hungarian

Hungary

commented 26 July 2012 at 08:00

There are also other needs of breakpoints outside of layout module (unrelated to grids), see #1693036-5: Responsive layouts & responsive images: both need breakpoints.

Comment #10.0

gábor hojtsy

he/him

Hungarian

Hungary

commented 26 July 2012 at 08:00

Issue summary:

View changes

More layout fix.

Communication requirements and format backend vs. frontend

Comments

Comment #0.0

Comment #0.1

Comment #1

Comment #2

Comment #3

Comment #4

Comment #5

Comment #6

Comment #7

Comment #8

Comment #9

Comment #10

Comment #10.0

News items

Our community

Documentation

Drupal code base

Governance of community