-
-
Notifications
You must be signed in to change notification settings - Fork 366
TODO list for UF4
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
- core
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 tocomposer.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 😀
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
toRole
, and "primary groups" to just "group"