Skip to content
Alex Weissman edited this page Jul 21, 2016 · 3 revisions

All development for UF4 shall take place in the dev branch of the main repo. I propose that we use something like this git flow model to collaborate. So, once we've got the basic structure down and working, we should create feature branches for each feature as we implement it.

The first thing we need to do is nail down the extension system. v4 will consist of a very minimal "core" system, and then additional functionality will be added through packages, which we call sprinkles. A sprinkle can extend or override core functionality, and can contain any of:

  • config files
  • assets (JS, CSS, images, etc)
  • routes
  • templates
  • classes (in /src)
  • locale maps
  • installation scripts (migrations)
  • validation schema

So, an example directory structure would look like:

  • sprinkles
    • core
      • assets
      • config
      • locale
      • routes
      • schema
      • src
      • templates
      • composer.json
      • sprinkle.json
    • account
      • assets
      • routes
      • schema
      • src
      • templates
      • composer.json
      • sprinkle.json
    • nyx
      • assets
      • templates
      • composer.json
      • sprinkle.json

The first thing to figure out is how sprinkles will mesh with the core functionality and each other. We want to avoid hooks, in favor of extending or replacing entire resources. In chat, we proposed the following system:

  • Each sprinkle will have a sprinkle.json file, similar to composer.json for PHP modules, that specifies other sprinkles upon which it depends.
  • When the UserFrosting application is instantiated, the dev will also specify an ordered list of sprinkles to load. Before loading each sprinkle, UF will check that the dependent sprinkles have already been loaded. For efficiency, we won't do any kind of recursive processing or autoloading. e.g.:
// Sets up the Slim app and loads the core UF dependencies, routes, template directory, etc
$uf = new UserFrosting();

// Loads the desired sprinkles, recursively loading any dependencies they have that aren't already loaded
$uf->load([
    "account",
    "nyx"
]);

// Calls the Slim app's run() method
$uf->run();
  • What does it mean to "load a sprinkle", anyway? Each type of resource might require a different sort of behavior:
    • routes: override
    • templates: override
    • classes: override
    • validation schema: override
    • locale maps: extend
    • config files: extend
    • assets: ?? See #560
    • services: extend/override?

I don't see sprinkles calling any methods other than the one to register a custom services container so, this part: https://github.com/userfrosting/bones/blob/master/public/index.php#L15-L20 for each sprinkle's service provider anything that needs to be run immediately can be placed in the DI container and there will be some listing of init services in sprinkle.json. Since DI dependencies are automatically run when first invoked, we won't need any additional hook system for specifying the run order dependencies will get resolved as needed by Pimple 😀

Migrating code

I've tried to split up the "core" code into three main sprinkles - core, account, and admin. core should just have the features that you would need for a basic, unauthenticated website. account should handle auth, access control, registration, password reset, basic user dashboard pages, etc. admin should handle group management, site settings, auth rules, and those goodies.

Right now we need to:

  • Get the controllers moved over to a Slim 3 compatible structure
  • Move request processing over to use Fortress 2
  • Get rid of DatabaseTable and just use the table name directly in the model class
  • Rename Group to Role, and "primary groups" to just "group"