-
-
Notifications
You must be signed in to change notification settings - Fork 366
Roadmap for UserFrosting 5
Main goals : Rework core Sprinkle structure
Status: Planning stage. See UF5 Prototype, UserFrosting 5.0 Planning
Related Milestone: 5.0
The main goal of V5 is to separate the default sprinkles in their own repo that will be managed by Composer (#830), effectively making UF a Skeleton repo. This will make testing and integration easier, butt also easier to develop your own app with UF from the skeleton.
Finally, since Composer is handling all the magic, sprinkle and core dependencies for sprinkle could be introduced. Composer extras could also be used.
In details :
- Automatic management of sprinkles with autogeneration of the sprinkle.json file and dependencies management (#747)
- Adding vendor name to sprinkles (#831)
- Factor our core, account and admin as independent sprinkles (#830)
Since all Services Provers in UF4 resides in a single ServiceProvider class, it make it very difficult to properly test them. Plus, some are becoming long hard mess making it even more difficult to test and extend.
The idea for UF5 is to mode back each providers in it's own class. This class, which would extend a new ServiceProvider interface, would be able to be properly extend by sprinkle, while also making it easier to test individual classes.
Providers to load should also be declared in a list from the config, inspired by Laravel list. Since all sprinkles config are already loaded on top of each other, many sprinkle registering an already registered provider would automatically extend it. The only drawback is in sprinkle inheritance. Right now, if one sprinkle register the service, and two other extend it, they would all piggy back on each other. Using class definition could lead to problem, similar to the user extension issue. This would need to be thought of when implementing the system.
A preview of this was released in version 4.4.0
Along proposed changes in #830, starting UF5 there should be a clear separation between admin / normal UI. Plus, all default non-admin pages should be moved away from core and into a base site Sprinkle. In fact, a minimalist install of UF should be possible using only the Core sprinkle, which would itself contain no front facing pages.
This will make easier for users to use their own UI and a totally custom admin panel if they chose too.
The account sprinkle could provide the necessary tools for the admin part if admin is installed, but admin shouldn't be necessary to use account.
Finally, this would make it possible to make use of two different admin UI. One with traditional JQuery, one with Vue.js.
Starting with UF5, only the English locale will be shipped in a default install of UserFrosting. Other locale should be available as custom sprinkles and managed by composer,
- Upgrade Slim from V3 to V4
- Upgrade Twig from V2 to V3
For the Bakery part, a skeleton repo, or template repo could be used in association with composer create-project command.
- Allow for users to be managed using the CLI, making the need for the admin interface to be optional if one choses so.
- Transition from Jquery/Handlebar to Vue.js
- Introduce Typescript support
Start thinking about using user-defined classes to supplement and eventually replace schema-based whitelisting/transformation/validation.
While storing permissions in the database is useful from a management/interface point of view, storing condition expressions in the database is probably not really necessary, and probably hurts performance because they need to be parsed, executed, and evaluated every time that permission is checked. Seems like we could probably move the logic itself out of the database, and use a naming convention or explicit pointer to tell the authorization module where to find the logic for a particular permission. See Laravel's Authorization module for some ideas.
Use UF's new NotFoundException instead of Slim's. This removes dependencies on Request and Response.
- change
beforeSubmitCallbacktobeforeSubmit("callback" is redundant and smells of Hungarian notation)