Add and configure master displays

Nice design, one question though, where can user add new block or region?

I've implemented a similar system in my Sigmaone base theme and utilizes 1140.css grid system. Will layout in core supports css grid system as well?.

so themes css is responsible to set the width of the layout item (region or block) as in the image? along with custom classes (if the theme is using a css grid system)?

By the way, see #1841824: Terminology: figure out proper words to use in the UI for describing unpopulated layout vs. populated layout to discuss template/layout/display terminology.

ahh thanks for the links, I got it now.

@Gabor: idea is great, suppose we need a element and method to provide a layout list to be used on pages where layout chosen so this entity should have a render/preview view mode. Please update issue summary about related issues about page-management roadmap (spark?)

Provider detection is broken.

+++ b/core/modules/display/lib/Drupal/display/DisplayListController.phpundefined
@@ -0,0 +1,63 @@
+    $layout = drupal_container()->get('plugin.manager.layout')->getDefinition($entity->layout);
+    $provider_info = system_get_info($layout['provider']['type'], $layout['provider']['provider']);

There's no "provider" key. Suppose we need a way to get module that provides this layout

Suppose label should be defined, also fixed lost provider key

we need to communicate back step by step, and use TempStore to save the in-progress object. JSON is an OK temporary measure, but this is exactly what the TempStore is for.

working on an in-depth review.

ok, more review. i think we're making good progress here.

if we're going to add a displays module, then we should probably move all of the displays code that's currently in the layout module to that.

i'm working on fixing the issues with saving now, but putting this review up for some discussion while i do.

diff --git a/core/modules/display/config/display.bound.admin_master.yml b/core/modules/display/config/display.bound.admin_master.yml
new file mode 100644
index 0000000..65aaf23
--- /dev/null
+++ b/core/modules/display/config/display.bound.admin_master.yml
@@ -0,0 +1,5 @@
+id: admin_master
+label: Default admin layout
+layout: static_layout:layout__two-col
+layoutSettings: { }
+blockInfo:
diff --git a/core/modules/display/config/display.bound.front_master.yml b/core/modules/display/config/display.bound.front_master.yml
new file mode 100644
index 0000000..54cf310
--- /dev/null
+++ b/core/modules/display/config/display.bound.front_master.yml
@@ -0,0 +1,5 @@
+id: front_master
+label: Default layout
+layout: static_layout:layout__two-col
+layoutSettings: { }
+blockInfo:

we haven't yet put the logic in place that would, at install time, convert unbound displays to bound displays based on some global default layout, but once we do, these should probably be unbound displays.

+++ b/core/modules/display/display.module
@@ -0,0 +1,90 @@
+ * @param \Drupal\layout\Plugin\Core\Entity\Display $display

This should probably specify BoundDisplayInterface.

+++ b/core/modules/display/display.module
@@ -0,0 +1,90 @@
+ * @param \Drupal\layout\Plugin\Core\Entity\Display $display

This should specify BoundDisplayInterface, i think.

+++ b/core/modules/display/lib/Drupal/display/DisplayListController.php
@@ -0,0 +1,63 @@
+class DisplayListController extends ConfigEntityListController {

This can only be a stopgap at best. We can't have just one entity list controller for all displays, as they can serve any number of different purposes. If that means we have to further differentiate the config namespace on something like a per-use-case basis (e.g., "display.bound.page." for this use case), i think that's totally fine.

Are you advocating NOT implementing this as a config list controller or inheriting a class for master displays only, so we can list them here?

yes, i'm advocating not implementing them as a config list controller. we're designing some patterns in core for how displays will be used, but we need to expect contrib will create others. as you point out, there can be only one list controller; therefore, nobody should use it. we might reuse some of the same patterns, or even classes (which would set a good pattern for contrib to follow), but we shouldn't bind it so tightly to the entity type.

i'm not sure what i'm doing wrong, but i can't get the visual thing to come up, at all. i wonder if it's some misapplication of the binary data in the patch...

can we put this in a branch somewhere, maybe in the scotch repo? it'll make it easier for me to collab.

the reason why blockInfo wasn't saving is because of this:

class ConfigStorageController {
  protected function getProperties(EntityInterface $entity) {
    // Configuration objects do not have a schema. Extract all key names from
    // class properties.
    $class_info = new \ReflectionClass($entity);
    $properties = array();
    foreach ($class_info->getProperties(\ReflectionProperty::IS_PUBLIC) as $property) {
      $name = $property->getName();
      $properties[$name] = $entity->$name;
    }
    return $properties;
  }
}

this doesn't work for displays, as a number of the properties that need to be written out are protected. the solution here is our own storage controller...which i want to do anyway in order to reduce some of the dense logic on the default ConfigStorageController (holy...crap).

i'm opening a separate issue to fix this, as i think it's better kept separate and get in quickly and easily: #1849480: Allow ConfigEntity classes to control how they are saved.

with that addressed, though, we still aren't writing out blockInfo properly, because it's not being set up quite right. here's the issue:

+++ b/core/modules/display/lib/Drupal/display/DisplayFormController.php
@@ -0,0 +1,157 @@
+  public function form(array $form, array &$form_state, EntityInterface $display) {
(...)
+    $regions = $display->get('blockInfo'); // <-- here's the issue
+    $form_state['values'] += array(
+      'layout' => isset($display->layout) ? $display->layout : reset($layout_keys),
+      'regions' => empty($regions) ? array() : $regions,
+    );

blockInfo is not a region-sorted three-level array. it's a two-level array; the first level has keys that are block config names, each of which contain an array with that block's config info. what you want here is $display->getAllSortedBlocks()...sorta. in the current code, that just returns the block config names as an indexed array, ordered correctly for output in the region. but it doesn't include the info; the expectation is that client code will assemble that together. the motivation for this was that block info ordered by region is neither the final storage format, nor what's most useful at render-time (since we do not necessarily render each block in sequence by region).

however, it's clearly complicating client code unnecessarily here, so i've made that method return the full set of data you want here :)

now, some further review points:

+++ b/core/modules/display/lib/Drupal/display/DisplayFormController.php
@@ -0,0 +1,157 @@
+  public function form(array $form, array &$form_state, EntityInterface $display) {

we have to use EntityInterface instead of DisplayInterface to avoid a strict warning on compat with EntityFormController's signature, but we should should add an instanceof check immediately inside to ensure that $display is a DisplayInterface.

...assuming we stick with using these classes at all, per the other line of discussion.

+++ b/core/modules/display/lib/Drupal/display/DisplayFormController.php
@@ -0,0 +1,157 @@
+    $display->remapToLayout($layout);

this means we remap on initial form build. if we have a built, bound display, then there's no reason to remap right up front.

remapping to a different layout should be a user-mediated process that happens out of band with the normal form. i wrote a big email about this to Kevin about 10 days ago, did it make the rounds with everyone?

+++ b/core/modules/display/lib/Drupal/display/DisplayListController.php
@@ -0,0 +1,63 @@
+    $provider_info = system_get_info($layout['provider']['type'], $layout['provider']['provider']);

this 'provider' value isn't set by the layout plugin itself, and it's tossing out a bunch of errors on the list interface.

are we expecting it to be added by plugin processing in the layout manager? b/c it's not, currently.

#28: In the "Layout list" screenshot Two column is under the header Template, but in the "Layout editing" screenshot the label of the dropdown is Layout. I think for consistent UX these should both be the same, i.e. the "Layout editing" label needs to be changed to Template as well.

Also (this might already be the case, so please tell me to STFU if needs be), but on the region objects within a Template declaration is there (or can we add) a simple property to say whether the blocks added to this region will be displayed vertically or horizontally. We could then lever this information in the "Edit layout"/"Add blocks to regions" page to give a better representation to the user how their page will look.

I'll have a go at converting the involved JS to backbone - there seems to be an ample amount of client-side logic involved in this. A little mv*-structure would be beneficial, imho. Initial battleplan: http://goo.gl/expgJ - i'll try to post a patch later today.

First stab attached. This is a very much WIP. Drag'n'drop, adding and deleting (random id-blocks) works but switching templates currently breaks things. I shoved all the backbone stuff into one file, grunt & build comes later.

Attached patch incorporates #29/#33.

Could you add screenies? Makes it easy for the non-devs to follow your progress :)

Ok, tried again.

Now slightly more complete (if not a lot prettier)
- Modal/Dialog integration - add new block instances, Remove/"Configure" existent block instances
- Drag and Drop, across regions
- Saving works
- Split up files & grunt included

Switching Templates doesn't work yet either.

Hope the patches are ok, trying the second approach to interdiffing now :)

Interdiff.txt is obviously #33.

Looks like this is in "needs review" ? :)

Pitching in where I can by reviewing the CSS.

+++ b/core/modules/layout/js/theme.js
@@ -0,0 +1,39 @@
…
+          '<div class="region-actions">' +
+            '<div class="add-block"><span class="plus-icon add-block"></span></div>' +
+          '</div>' +

• Should this span have the add-block class?

+++ b/core/modules/layout/layout.admin.css
@@ -15,3 +15,320 @@
…
+/**
+ * Begions.
+ */

• Typo

+++ b/core/modules/layout/layout.admin.css
@@ -15,3 +15,320 @@
…
+#display-blocks .add-block-press {

• (:1228) This looks like it might be styling an active state? If so, see if the :active pseudo-class might be used instead.

+++ b/core/modules/layout/layout.admin.css
@@ -15,3 +15,320 @@
…
+z#display-blocks .layout-block {
…
+z#display-blocks .page-block {

• (:1188 and :1199) Accidental 'z' characters inserted

More generally:

• We probably don't need to support the original -webkit-gradient(linear…) syntax.
• We should support linear-gradients in Opera with the -o prefix.
• Since the linear-gradient syntax has changed so many times, consider being explicit with the gradient direction: e.g. -{prefix}-linear-gradient(top, …) for prefixed and linear-gradient(to bottom, …) for official.
• Double-check that styles can be re-used where applicable. For example, make sure that #display-blocks .layout-block will only ever appear inside #display-blocks. If it or something that looks similar might appear elsewhere, consider un-scoping it as a single re-usable class, something like .admin-layouts_layout-block (or something less verbose).
• Also consider grouping repeated style blocks (like :1178–:1181, :1189–:1192) as a base class, e.g. .admin-layouts_block. Then add a second class and style rules to create a variant that 'extends' the base class: .admin-layouts_block-master extends .admin-layouts_block.

Kudos to everyone working so hard on this! :)

@Gábor Oh! I haven't seen that before. I guess it's a case of “You learn something new every day” :)

A small reroll of #38 to fix a reordering/rendering issue. There are still remaining issues (e.g. switching templates doesn't work, dragging onto an empty region doesn't work, etc.) and this there is no visual improvement/UX love in this, so far.

Before doing more substantial JS-work (or screenshots or in-depth reviews) on this, I think though, a little more time on the defining the architecture might be needed:

1. a written spec that details what goes where (the screens/mockups provide a lot of good ideas and points but I am not sure what's within the scope of this initial issue or outside of it, tbh).
2. as this is similar to placing "panels' content-placement" logic in core, we should co-ordinate with other aspects in the area (e.g. FieldUI & Entity Display ("panelizer in core") -> http://drupal.org/node/1852966)
3. discuss what (and if at) we retrieve in a REST-ful way (e.g. is there a resouce /entity/block listing all available blocks etc.) and what needs to remain maximally alterable and go via the Form API (e.g. Configuration Forms?)

Next iteration, even more work in progress. Signifcant new feature is persisting changes via RESTful webservice and TempStore.

- TempStore integrated (but not 100% complete, all very new to me incl. some "blind" copy and paste from views_ui) .
- New menu loader function %layout_master_cache
- (Temporary) Webservice on admin/structure/layouts/manage/webservice handles POSTs from the BB-App (non-FAPI-based communication)
- Changes are temporarily persisted in TempStore and then "saved" properly on clicking "Save" (no revert available atm :).

- Activated a RegionModal to prepare for region-based configuration Form.

Open issues remain (e.g. switching templates flaky, dragging onto an empty region doesn't work).

This should now mimic views_ui's usage of temp store. Includes cancelling unpersisted changes and locking as well as breaking of other users locks.

Open issues remain (e.g. switching templates flaky, dragging onto an empty region doesn't work).

Lets summon nod_ for the javascript then :)

Thanks for the review!

- The tempstore function seems to be working really well.

There are still some superfluous XHR-requests on reordering going over the wire, but that should be easily fixed.

- I see you moved the big "+" away from the right side of the region. I believe it was specifically designed to be that big and prominent and loosing that seems to be unfortunate.

I spoke to Bojhan about this in IRC. We can switch back to that behaviour/design later on, but it would require changes to the structure of HTML and the CSS and I wanted to avoid that in the initial stab.

- I've also seen you added a configuration gear on the region, which is not necessary at all. I don't know what you'd configure there, the current functionality specs for Drupal 8 definitely do not have anything to configure there. The region type which is the only property of a region besides its machine name and label is predefined and cannot/should not be changed I believe.

Easily removed. It might make sense to keep this, though, if e.g. we need to provide a (more accessible, more mobile etc.) traditional form-based "reordering interface" for the block instances.

Ok, reroll. I hope i addressed everything in the review.

1. grunt.js Add a @file block to the grunt-file added drupalSettings to the globals. Not aware of any guidelines. Can also be just removed, helps w/ development though.
2. js/models/block-model.js - improved documentation - we need unique ids for all BlockInstances these need to be generated server-side (or via a js-based UUID implementation?)
3. js/views/app-view.js - added documentation why we need emulateJSON and emulateHTTP (REST-verb based routing and application/json handling)
4. js/views/app-view.js - added documentation re: TempStore "locked" state
5. js/views/region-view.js - fixed the debounce-timeframe (but still too eagerly POSTing/PUTing)
6. js/views/regionmodal-view.js - i left this in because a) we should think about whether we need an alternative and more a11y-friendly (perhaps also mobile friendly) approach instead of d'n'd (plus: keeping in mind other usecase of content-placement within containers in d8 => fieldui, layout manager etc.)
7. layout.admin.inc - added more documentation. CSRF is inevitably going to be a concern w/ any RESTful stuff - because a "per request token" is not really "restful"; we should at least bring a per-session "CSRF"-token (e.g. a -tag like Rails does afaik) into core.
8. lib/Drupal/layout/DisplayFormController.php - fixed and removed flippant comment.
9. lib/Drupal/layout/Plugin/Core/Entity/Display.php - moved to a "traditional" submit-handler (the forms will be OOPified anyway soon)

Additionally: made sure that there are @file blocks in all JS and fixed a few small issues/typos etc. Bugs/lacking features mentioned in #47 still apply.

Setting to "needs review" (although it needs work as well ...)

I will work on some designs for the issue raised by Gábor,

*appears in a puff of smoke*

I had a quick look at the code, there is still hardcoded HTML that isn't in Drupal.theme.something.

More generally, that's a lot of JS for something that is essentially similar to dashboard with modals and stuff added to it. Lots of boilerplate code too. I could use a walk-through to understand the real value of using backbone here.

Amazing work so far frega.

nod_, my understanding of this work is that we're moving towards a UI that can configure static layouts and then eventually responsive layouts. My intent was to move the responsive layout builder to Backbone eventually. This work will dovetail nicely with it.

I went through and refactored the CSS to match our .base and .theme standards. This involved changing some class names and therefore some of the templates. I tried really really hard not to break any functionality. I'm sorry if I did.

One other thought, in region-view.js, the render function

render:function () {
  this.$el.html(Drupal.theme.layoutRegion(this.model.get('id'), this.model.get('label')));
  this._collectionView.setElement(this.$el.find('.row', '.blocks'));
  this._collectionView.render();
  return this;
}

I don't understand why the collectionView element is being set in this region's render function. If collectionView is a container for multiple regions, would it not be better to create the instances of region views in the collectionView?

@nod_: there are HTML-chunks in the modal-views but those should and probably will be replaced very soon w/ FAPI-forms loaded from the server - so i didn't bother with Drupal.theme-ing those. Please also note: we currently parse the HTML generated on the server to generate Models and Collections; I'm going to replace that as well - but I am not sure how comfortable people are with pages that render entirely on the client-side - what's your take on that (raises all kinds of "extensibility issues")?

Regarding the overall meaningfulness of using Backbone:

First, it's sort of a matter a principle: I don't think that we should store state in the DOM, ever. Serializing and deserializing from and into the DOM does not "scale". jQueryUI-widgets IMHO are not fun to work with (ask jesse or wim). Backbone can be verbose and definitely entails more "boilerplate", but it provides a saner and more decoupled approach than a DOM/jQueryUI based one.

Secondly, framing this as a "simple dashboard" underestimates the objective and implicit complexity both in terms of user interactions and of state/models. The objective, to me at least, is to start with a working prototype that can solve the (simple) use-case of "Block" placement for "Master Layouts", and in doing so lays meaningful groundwork for similar "GUI-challenges" down the road (FieldUI's "manage field" and the responsive layout builder jesse mentions).

I'd be happy to walk you through the code - if you have categorical concerns (there are plenty imaginable) or if you don't see how it "jives" with the overall strategy in D8, please tell me: I would not want to pursue this approach (or much spend time on it) otherwise.

@jessebeach: thanks for the adjustments, couldn't find any regressions so far.

Regarding the repeated setting of the nested _collectionViews' DOM-element - this is simply needed because at initialize()-time the containing region hasn't rendered yet and thus "

" hasn't been painted. Or do you mean something else?

I, personally, am OK with a UI generated completely by JavaScript for this component of the admin experience, especially because everything we're doing can be done through code if one really doesn't want to have JS enabled in their client. Sure, it wouldn't be convenient, but neither is building a complex UI that falls back to a non-JS functional state for a marginal minority of folks. We can also address aural and keyboard access in a complex GUI. There's no need to think about a non-JS version as the accessible version. Accessibility is what we make of it.

Regarding the repeated setting of the nested _collectionViews' DOM-element - this is simply needed because at initialize()-time the containing region
hasn't rendered yet and thus "" hasn't been painted. Or do you mean something else?

I'm not 100% solid on what I'd recommend here yet. My gut feeling is that children of a container should not necessary know anything about what contains them. The container should mediate communication to the objects it contains and be involved in their CRUD, rather than the other way around. The contained objects should only be concerned with their very focused tasks. In the case of a Region, that would be the task of managing blocks. Does that make sense? Maybe I just need to propose some code and see if what I'm babbling about makes sense here.

Had a little idle time so tried to improve on this.
- Switch from DOM parsing to passing JSON to instantiate Models and Collections from drupalSettings.
- Fixed minor regression in #60 (region-view.js configure click event caused page reload)
- Replaced RegionsView with a UpdatingCollectionView (currently RegionsView has no distinctive logic)
- Improved UpdatingCollectionView by adding the nestedViewContainerSelector-option which allows to specify into which sub-element of a view the UpdatingCollectionView should "render"
- Added a exportGroupedByRegion method to Display to allow stripping DisplayFormController from assembling that data.
- Cleanup code in places

Switching between Templates and dragging to empty regions still doen't work.

Big questions for me are:
a) decide on whether this makes sense to pursue
b) figure out how to best load FAPI forms into dialogs
c) Leverage Drupal's new router to be more restful, refactor Webservice and introduce some form of CSRF protection

Just trowing an idea in there, this removes the large plus, to a small one. I changed some of the visual styling so it still stands out. As I used the initial design, I found the large plus a little uncomfortable it takes up a lot of space when you have a more crowded layout and gives the illusion, there is another zone.

The current prototype looks sort of similar to what Bojhan outlined. I enabled overlay temporarily :) and took a few snaps.

Initial:

On clicking + an unstyled dialog with random blocks pops up.

If you modify the layout by moving, adding or removing block instances, changes are store in TempStore immediately and a views-like change notification is shown (yes buttons should change colors probably, too)

Please not the "gear" icon on the region is temporarily placed there and unstyled. In the "Layout Master" it doesn't have a purpose, in other related GUIs a configuration on a "container" level would probably make sense.

+++ b/core/modules/layout/lib/Drupal/layout/Config/DisplayBase.phpundefined
@@ -135,4 +135,22 @@ public function getAllRegionTypes() {
+    // Start by exporting the public properties.
+    $class_info = new \ReflectionClass($this);
+    $properties = array();
+    foreach ($class_info->getProperties(\ReflectionProperty::IS_PUBLIC) as $property) {
+      $name = $property->getName();
+      $properties[$name] = $this->$name;

+++ b/core/modules/layout/lib/Drupal/layout/Config/DisplayStorageController.phpundefined
@@ -0,0 +1,25 @@
+  public function getProperties(EntityInterface $entity) {
+    if (!$entity instanceof DisplayInterface) {
+      throw new \RuntimeException(sprintf('DisplayStorageController::getProperties can only work with objects implementing Drupal\\layout\\Config\\DisplayInterface, object of type "%s" was given.', get_class($entity)));
+    }
+
+    return $entity->export();

Why can't this just be:

public function getProperties(EntityInterface $entity) {
  $properties = parent::getProperties($entity);
  $properties['blockInfo'] = $entity->getAllBlockInfo();
  return $properties;
}

keeping the exception and all of course, but this is a bizarre workaround

Another iteration, now switching templates and dragging to empty regions works, removed some duplicate requests to the webservice.

I had to hack my way around some limitations (or design?) of FAPI/Drupal.ajax related stuff (see DisplayFormController.php:88-89 and layout.admin.js:72-73 - could also be due to the fact that i don't fully grok either).

Still missing loading FAPI-forms into the dialog.

I have left the issue raised in #66 unaddressed because I know nothing about that part of D8.

So I reviewed the code this week-end.

1. There are still duplicate Ajax calls for the layout thing.
2. As it it also poses the question of the first non no-js fallback functionality.
3. More generally I don't see the benefit for backbone here.
4. Code is somewhat hard to understand. I had to look at the AJAX request to figure things out. The format for those is pretty simple thankfully.
5. Code seems kind of convoluted in some places.

To me having the jquery sortable properly configured and some ajax calls here and there would do the trick. sortable has code to serialize DOM elements to a sorted list and publish enough events to react to most/all things. Also storing the state/config of the blocks might end up necessary. It's possible we'll want to add the block thing to wysiwyg and the only way to make copy/paste work properly is having all the data on the DOM element.

I'd favor a more direct approach, it's currently more complicated than it needs to be.

Hi nod, thanks for the review.

Re: 1. do you refer to the same request going over the wire twice (#67 removed only "some duplicate requests") - that can obviously be rectified but seems a somewhat pointless exercise right now.

Re: 2. there is no "no-js fallback" as the whole thing doesn't work w/o Javascript at all (#64) :)

Re: 3. and the general gist of your review - it is certainly possible to do this w/o Backbone using e.g. jqueryui widgets, drupal.ajax, FAPI and some events. I am not unaware of the boilerplate, complexity and the "impedance mismatch" between REST and FAPI, but I wouldn't want to pursue a "some ajax calls here and there"-approach. Especially if reuse is intended.

The patch is still far from that a properly decoupled approach using backbone and webservices on top of a proper API, would make sense imho - whether that's "core" stuff and what implications that has (maintaining extensibility via modules/PHP and JS) is though above my paygrade :)

As to 4.-5. that's hard to respond to without concrete examples, but please bear with me a little bit as this is only my second stab at D8 and grokking D8 can be quite a mouthful :)

One last iteration - now with backbone and Drupal.ajax :) It now includes a FAPI-form loaded in to a dialog. The prototype - if very ugly in appearance and parts of the code - can now do CRUD: add new blocks, move them around, update the block instance "config" (for want of meaningful things to configure just the block label) and delete block instances. Layouts can be switched on the fly (even if the logic for re-sorting them isn't very helpful).

The patch now *deliberately* combines Drupal.ajax and Backbone. Drupal.ajax is used for the block instance configuration modal (click on the gear that appears when you hover a block instance). Backbone handles adding, deleting (click the ugly "-" button), moving the block instances as well as the rendering. Please note how the two intertwine in js/layout.admin.js:7ff - I find that considerably more compelling than Drupal's traditional AHAH/AJAX stuff, but that might/will be contested :)

I don't think it makes a lot of sense for me to continue (and finetune) beyond this point without knowing whether to continue w/ Backbone or rip it out and replace it. I still think it is worthwhile to think what a "client-side driven approach" (based on a js-client backbone) could give us in a variety of use-cases, but am happy to roll either way.

sorry i've been absent from this for a while.

first, a general note - in theory, i'm excited about backbone, because the DnD block placement interface is one that i expect we'll want to see lots of different versions of. we certainly could do something simpler using what jQuery UI provides us - indeed, i did do just such a thing in contrib, albeit quite crappily. but if using backbone means creating an API that will be easier to repurpose both because:

a) people know backbone, and it'll be easier for them to grok.
b) backbone provides API layers that make it easier to reuse and repurpose what we've put in core.

i don't know backbone for shit, so these are completely generic statements about pros typically associated with using a framework.

my expectation is that this UI will be re-done not on a site-by-site basis, but by a few modules in contrib and especially in distros. which means that our API target should be more skilled developers, and creating a well-structured environment that eases the process of figuring out what differentiates a given implementation...and maybe even some kind of interoperability.

@tim.plunkett #66 - since #1849480: Allow ConfigEntity classes to control how they are saved went in, it seems the separation of concerns question has been decided. this patch can now be refactored to remove the custom workaround, since it's now in the base config storage controller.

So what is this blocked on?

1. We need a basic no-js fallback, meaning integrating most of this things through Form API.
2. Then we can add fancy JS things on top of it. Backbone or not doesn't matter at this point since we don't have the fallback yet.

1. is definitely in this issue, 2. can be split of for later probably, it'll take some elbow grease to make 1.

Awesome, sounds like a solid to do. I have created #1871746: Add modal block browser

will try and look at 1 next week

Hia! Just wondering if there was any update on this? :)

Looks like this won't happen for D8 either, its quite a massive task still.

was just talking about this today with Shannon and Kris. not doing this means is pretty much saying that we have to throw all of SCOTCH out, and my impression elsewhere is that we don't want to do that - given that we're now at the point of being able to build and render a display out (at least in patch form - #1812720: Implement the new panels-ish controller [it's a good purple]).

basically, this is a required conversion if we want any of SCOTCH to be viable, which is required if we want the ESI/structured page model/promise of WSCCI. so, i'm switching this back to 8.x and calling it a task. let the argument begin :)

@sdboyer Basically you have to take this with the maintainers, it is my impression that you guys have and still are focused on API fundamentals. There is not enough man power and or vision, to provide a good UI for this. Even if we do manage to hash out something, it will still not match an MVP that is desirable for users - which as we already researched goes beyond the simplistic approach taken here. I appreciate your sturdiness, but its been my impression for the past few months that Spark already threw in the towel and with that the largest resource available to making this happen.

yep - a conversation to be had with the maintainers, indeed.

the reality is that we're going to be tweaking and improving the API for some time to come. there's no denying that. what's different now is that, once we can get controllers in, anyway, the pieces of the API that this UI would be reliant on are taken care of. there's a much simpler conversation that could be had about this than the one we've had in the past.

I think it's appropriate to keep this as an 8.x task issue for now, but my hunch is that the scope needs to be significantly reduced to something like:

- Keep layout.module (or the concept of layouts as plugins, even if that concepts moves to a non-module location).
- Once #1812720: Implement the new panels-ish controller [it's a good purple] is complete, ensure that the entire page.tpl.php rendering pipeline is using layout plugins + display configuration entities instead (this is an implementation task, not a UI affecting one).
- In core, provide a preset 1:1 mapping between theme and layout (i.e., each core theme provides 1 layout plugin and Display entity) (this is an implementation task, not a UI affecting one).
- Ensure there are no critical UX regressions of admin/structure/block relative to D7: #1875252: [META] Make the block plugin UI shippable.

What this issue originally set out to do, however, in terms of a UX for adding displays, or configuring them with a radically better UI than D7's admin/structure/block, seems out of reach for core. Though with the API support reflected in the above, D8 Panels can shed a lot of its former baggage.

sdboyer and I have discussed the fact that we need to get a summary of what we think the way forward looks like, but given the limited feedback we've gotten on this issue already I feel pretty positive about where everyone is at in relation to where Blocks & Layouts looks like it's going right now. We'll get a blog post up detailing what we think is left and how that all jives with a post-18th world in the next few days. Thanks for this feedback thus far, it's greatly appreciated.

Eclipse

any update here?

For reference: http://groups.drupal.org/node/287563

There's a much simpler implementation proposed in #1875252-47: [META] Make the block plugin UI shippable

temporarily tagging. :)

This seems to be D9 at this point.

Updated issue summary.

Not impossible to add in a minor version.

Patch needs re-roll

call for contrib

Reroll patch as per #94