Very nice! Does this mean, however, that the traditional hook-based workflow will get replace by an event-driven one? Or will this change be more of a end-user transparent change in core and for modules defining hooks?
We have build a prototype that explores how the Blocks & layout initiatives it's ideas could look in Drupal 8. This following the page & component library and concept model discussions.
Any module should be able to extend the system by providing additional thingies that can be chosen from, but at any given time, only the actually chosen one(s) should be invoked. For example, the Image module lets you create image styles by choosing from a set of image effects (scale, crop, rotate, desaturate, etc.). Any module can add more effects to the system. However, a particular image style is configured as a particular sequence of effects, and when it's time to generate an image of that style, the Image module wants to invoke just that particular sequence of effects.
Previewing is a big part of creating content, and people are currently very confused by preview being shown in the back-end instead of front-end.
The meta tools we present users; menu, revisioning, authoring information are cumbersome and often result to conflicting mental models.
Text formats are still somewhat of a mystery to most of our users, they miss a WYSIWYG editor.
The lack of a common workflows like save as draft is a disappointment.
Tools for moderating content are almost non existent, our filters are hard to use and search is non existent.
Drupal
Drupal\Component\$component
Drupal\Core\$subsytem
Drupal\Module\$module
Drupal\Hook and Drupal\Module\$module\Hook
Modules and themes (and engines) would have a namespace such as
namespace drupal\taxonomy;
or
namespace drupal\bartik;
Function prefixes, such as 'taxonomy_' would be dropped.
However, this makes Drupal code really ugly.
Calling functions not in a module from a module would look like this:
\drupal\set_message();
Calling a db function would look like this:
\drupaldb\select('node');
Calling an API function in another module would look like:
\drupal\taxonomy\select_nodes();
The solution? Namespace importing.
At the very least (if we are on PHP 5.3) we could have something like:
namespace drupal\dblog;
at the top of every file.
Files in the includes directory would have:
namespace drupal;
The only time 'drupal' would be seen in a function name would be when calling an API function in a different module, e.g.
\drupal\system\flush_caches();
1) We've been discussing how and if to leverage PHP namespaces in Drupal 8, now that we have access to them in PHP 5.3. To date most of the discussion has been on tricking out modules-as-namespace, a discussion that has stalled as it is a much more complicated problem space than it seems at first glance.
There are three ways to access a file in a file system:
Relative file name like foo.txt. This resolves to currentdirectory/foo.txt where currentdirectory is the directory currently occupied. So if the current directory is /home/foo, the name resolves to /home/foo/foo.txt.
Relative path name like subdirectory/foo.txt. This resolves to currentdirectory/subdirectory/foo.txt.
Absolute path name like /main/foo.txt. This resolves to /main/foo.txt.
After a good chunk of discussions, all were in agreement to scale back the scope of the initiative to just the "Web Services" piece, and spin off the Layout/blocks/related-UI parts to a separate effort.
Furthermore, some efforts, such as PSR-0 and Unified Plugin system, were only semi-related to the WSCCI initiative in the first place, and just happened to become relevant for it. Work on those efforts will continue as part of the general Framework community efforts.
