Note: this is deprecated in favor of http://drupal.org/node/1499460
We need two systems. One for the layout reorganizable from the UI. Currently this is Manage Display. So it needs to be field level. We can't regress. The layout engine driving this needs to be pluggable. http://groups.drupal.org/node/160144 describes a UI. The way I imagine this, you have something like the current region demonstration screen then a toolbox hovering above it. You can drag-and-drop components of the page into the region and configure them. Some come grouped like the fields of an entity. You can put the whole group there or just pieces from it. Once there, the components in a group can be moved out of the group. But also arbitrary components can be grouped together to form a container. Container has a tag, id, class. I believe with CSS3 there is no need for anything else on the layout level. There's nothing a themer would or could touch here. This is all generated by the (pluggable) layout engine.
Router paths just become a provider of context for these layouts.
How do we deal with "show this block everywhere"?
Now for lower level. What is logic and what is templating? What is the role of a field formatter? Just provide the data and let the theme deal with it with a default theme function / template providing the markup? How much configuration of this goes into the layout engine like Manage Display had?
Comments
generic and reusable CSS styles
I'm not sure I understand all that you are saying here, but I definitely want to set id and class on containers. Styling individual containers is crazy. I define generic, reusable container styles in my CSS and apply them to containers by adding classes (via Panels,
Block ThemeBlock Class module, or in template.php / block.tpl.php). So on a moderately complex site I need markup like this, otherwise I'll end up with 2000+ line unmaintainable CSS:<div class="margin-1-0-1-0 padding-0-0-1-0 my-fancy-style-1">some block content</div><div class="margin-1-0-1-0 my-fancy-style-2">some other block content</div>
.margin-1-0-1-0 {margin: 1em 0;
}
.padding-0-0-1-0 {
padding-bottom: 1em;
}
.my-fancy-style-1 {
color: red;
}
.my-fancy-style-2 {
color: blue;
}
That's exactly what I meant
I am not sure what is not understandable there but I meant you can specify the tag used for the container: it can be a div, span, fancy HTML5 whatever and then add an id and a list of classes.
relief
I thought that "there's nothing a themer would or could touch here" was referring to the tag, id and classes. And I panicked. :)
Currently you have something
Currently you have something like page.tpl.php and that would simply go away. There's no need for that.
Would it completely go away
Would it completely go away or simply become "less necessary"? It seems like we're proposing that more things would be possible within the UI, but I still think that there will still be a need for page.tpl.php or whatever.tpl.php.
Panels Everywhere, afaik
As I understand, this is going to be sort of Panels + Panels Everywhere in core. Please correct me if I'm wrong. So instead of .tpl.php files we'll write layouts. Not much difference on the surface, but:
<div class="grid-4 alpha"><?php print $variable_left; ?></div><div class="grid-4"><?php print $variable_center; ?></div>
<div class="grid-4 omega"><?php print $variable_right; ?></div>
Layouts are reusable: write the above a 3-column layout once, and you can use it to output a full page, or a node, or a part of a node, or whatever you assign it to.
Layouts are content agnostic: you can determine what goes into $variable_left, $variable_center, $variable_right.
Layouts are context aware: you can determine that, for example layout-1 should be used on /some-path but layout-2 should be used on /some-other-path.
Essentially
That is the general plan, more or less. However, I expect many sites will not use all-general layouts. We want to make writing a new layout dead simple so that it's easy to write a custom layout at least for the page level that is custom to your site. For many responsive designs that will be necessary, so we want to make it easy.
Also, we want to allow nesting of layouts. Details of how you'd go about configuring that are still being worked out.
context
context (and configuration) is why I doubt that dead simple layout template would work. If you consider the Manage Display screen I am planning to generalize, you can configure your fields there. That means the layout engine needs to be able to push those things down to the component theming engine. Though the results of the components might still go into such a template... we will see.
Are "components" blocks?
By components are we talking something like what we've been talking of as the new blocks? If so then even though details are missing because you(and everyone else) are still ironing out the details but it seems like we're moving in the same direction architecturally.
Panels limitation
I think with Panels there's a limitation, I mean you can theme a Field as its own region. But you can't arrange more than one of them in a single region to form a more complex things.
You are limited to that one argument (a single token from a context), I think.
I'm not sure where my argument is leading to be honest. But last time I checked there was that. You can theme them one by one, but can't mesh them together, which was simple in itself. What was lead me to think of Rules|contrib arguments.
re-arranging fields
Yes, it would be very helpful when making a new block in the new system to have the Views functionality of being able to select, re-arrange and modify/re-write fields and their surrounding html. It sounds to me as if this is already the goal.
Christopher Pelham
Director
CRS (Center for Remembering & Sharing)
http://www.crsny.org
CRS (Center for Remembering & Sharing) is an arts & healing center located just south of Union Square in Manhattan.
Block for ESI
Eh, assuming Block initiative provides ESI (Edge Side Include) then the missing ability to mesh several components(?) as a single block with some complex php logic make sense.
Just pick one block here, put it here, you get another block, put it there. Err, assuming Layout Initiative is that simple.
one custom theme per site is moot
Err, if layouts are plugins, then the concept of one custom theme per site becomes moot. Isn't it?
Since custom themes are just something that provides plugins, and site builder free to choose the layouts provided.
Though having a custom theme defines its default layouts selection is a good option.
PS: I was thinking in the concept of Panels layout plugins, and Skinr.