Module System Refactoring

Proposal.md

As you may know, hopefully for GSOC I'll be working on refactoring the module system to one based on composer. However, before this can be done the existing module layer will need to be reworked to provide an actual module API, rather than the current heap of random bits and pieces. I think this should have the following goals:

• Provide a reflection API for getting information about the modules running.
• Allow modules to be installed in subfolders.
• Implement a resource loader system which loads classes, templates and assets from modules, taking into account module priority,

To that end, I'd like to propose a number of pretty radical changes:

• Separate the framework into SilverStripe\Base and SilverStripe\Framework namespaces (or something similar, maybe SilverStripe\Core) - the idea is that the Base namespace is responsible for registering modules and loading resources from them, while the Framework namespace is the actual functionality you're all familiar with. This makes it a bit easier to test and enforces a strict separation of concerns. The initial development will be easier as well.
• Rather than auto-discovering modules, they will need to be registered. Once composer has been integrated this should be fairly transparent with composer modules being automatically registered, but until then you'll need to do something like $modules->add(new Module('name', 'modules/name', PRIORITY_MODULE));. I don't think scanning all directories is a feasible solution when modules can be installed in subdirectories.
• Change the standard directory structure to make folder names and locations consistent (css/javascript -> css/js), and store code in the src directory according to PSR-0 standards. Manifest-based class loading will still be supported though, so you could still use the old conventions. See the end of this post for my proposed modules directory structure (using the framework as an example). The new asset directories would only be a convention, you could still use whatever layout you want.
• Change the bootstrap code to be class oriented rather than a procedural file. Each application will then have an index.php which requests hit - this includes a bootstrap class, registers the modules and calls the request handling function.
• I think we should remove the class name with underscore convention - it encourages strict coupling and is a bit messy. Classes with underscores should be renamed to a more sensible full class name.

Proposed Directory Structure

framework/
  src/
    SilverStripe/
      Base/
      Framework/
  tests/
  templates/
  assets/
    css/
    js/
    img/
  vendor/
  bootstrap.php
  composer.json

Proposed Webroot Structure

application/
vendor/
framework/
index.php