Jump to:

Problem/Motivation

Drupal core only supported static layouts so far, with defining characteristics of a fixed set of regions and a static markup structure with pre-baked CSS positioning. It is not possible to edit these layouts in a user friendly way, so with #1813898: [META] Add editable responsive layouts to Drupal core, we are proposing a set of modules to serve this need in Drupal core.

Proposed solution

This issue is about the dynamic region list handler, which is a very simple module that handles a list of machine name + label combinations with some pre-defined regions shipped with the module in configuration, all regions being editable and deletable. These regions are going to be used in the editable layouts later on in other modules.

Admittedly, this module has not much use without editable layouts given these regions are not expected to be used or useful outside of editable layouts.

The proposed module is named region with a configuration entity called Region and the respective form controllers and default configuration. Test coverage for creating regions, editing regions, deleting regions and doing these with built-in regions is included.

Having had this issue with both D6 and 7 I think this is a much needed, missing piece of functionality. I also think many projects currently doing page_alter injections (like admin_menu) would be better served by adding their own region and then positioning output within that. This makes projects that add to the UX/UI better fitting with the way drupal's core blocks / plugins would function in their interaction with screen output instead of being a series of one-off implementations.

I've taken a stable at creating a framework for defining regions and adding them to Drupal (theme-agnostic) at a system level with the module http://drupal.org/project/regions . Agreed though, Regions w/o layout abstraction are just kind of O.K. at best.

Can you point to a standards entry for the "missing backslash"? If I search current Drupal 8 for "@param Drupal", I find hundred if not thousands of use of that *without* a backslash to start it out. Also for the setUp() method, it is a common method of test classes, and I believe they should not be documented, similar to getInfo(). I looked through all block module tests for example and it was perfectly as-is.

So looks like no other complaints with the current code then? Sending for a retest.

A nitpick. I know your default layout is just a sample but I was wondering why you define a 'body' region when I thought the drupalism was 'content'. I just thought it confusing to not use a common drupal label and one that might get confused with html's 'body'

The data type MAY be specified (as in: recommended) for other @param or @return directives, including those with primitive data types, arrays, and generic objects (stdClass).

* @param int $number
* Description of this parameter, which takes an integer.
* @param float $number
* Description of this parameter, which takes a floating-point number.
* @param string $description
* Description of this parameter, which takes a string.
* @param bool $flagged
* Description of this parameter, which takes a Boolean TRUE/FALSE value.
* @param array $args
* Description of this parameter, which takes a PHP array value.
* @param object $account
* Description of this parameter, which takes a PHP stdClass value. * @param \Drupal\Core\Database\StatementInterface $query
* Description of this parameter, which takes an object of a class that
* implements the StatementInterface interface.
* @param string|bool $string_or_boolean
* Description of this parameter, which takes a string or a Boolean TRUE/FALSE
* value.
* @param string|null $string_or_null
* (optional) Description of this optional parameter, which takes a string or
* can be NULL.
*
* @return string
* Description of the return value, which is a string.

Also see further down on same page.

Using namespaces and namespaced classes in documentation

The following guidelines apply to the use of namespaces in documentation blocks:

When using a class or interface name immediately after any @-tag in documentation, prefix it with the fully-qualified namespace name (starting with a backslash). If the class/interface is in the global namespace, prefix it with a backslash.

Elsewhere in documentation, omit the namespace if the class/interface is within the use/namespace declaration context of the file.

If you refer to a class/interface that is not in the current file's use/namespace declaration context, or that is in the global namespace, prefix it with the fully-qualified namespace name (starting with a backslash).

Example -- given that classes Foo, Bar, and Thingy are in the A\B\C namespace, and class Baz is in the X\Y namespace:

And sorry, these are not complaints. I am learning how to contribute, and an easy entry point is coding standards.
Sorry if it seems I am being negative, not my intention.

Like you, I have also searched all core, and yes, the standards are not being used consistently. No one's fault, just some things are not clear/easy to find, and in a fast paced change environment, standards are normally applied later then earlier.

Keep up the great work, and hope to see this and other stuff your working on, committed. These are great end user features.
And I look forward to using them when D8 is released, and even before.

Well, anyway, due to core things not happening below this layer that we wanted to build on, we just need to go and focus on those things and will pretty likely not have a responsive layout builder (and therefore this module) in core. Unless someone comes and want to run with all these. Start from #1813898: [META] Add editable responsive layouts to Drupal core.