The event subscriber approach means that dependencies have to be
injected (and thus instantiated, along with all *their* dependencies) at
the time of registering event listeners - even when events are never
fired within a request's lifecycle.
This is unnecessary and causes more classes than necessary to be loaded.
In this case, we can explicitly register event listeners that will
resolve their dependencies when the event is fired, not before.
Refs #1578.
We had added a `storage/locale` directory to our skeleton, but we had
forgotten to hook it up with the translator. Enabling caching saves
parsing that locale YAML files on every pageload which should be good
for performance.
The locale cache will be cleared whenever an extension that uses the
`Locales` or `LanguagePack` extenders is enabled/disabled. If debug
mode is ON, then the caching mechanism will automatically check if any
of the loaded YAML files are dirty and update accordingly.
- Simpler class naming:
Frontend\CompilerFactory → Frontend\Assets
Frontend\HtmlDocumentFactory → Frontend\Frontend
Frontend\HtmlDocument → Frontend\Document
- Remove AssetInterface and simply collect callbacks in Frontend\Assets
instead
- Remove ContentInterface because it serves no purpose (never type-
hinted or type-checked)
- Commit and add asset URLs to the Document via a content callback
instead of in the Document factory class itself
- Add translations and locale assets to Assets separate to the assets
factory, as non-forum/admin asset bundles probably won't want them
- Update Frontend Extender to allow the creation of new asset bundles
- Make custom LESS validation listener a standalone class instead of
extending RecompileFrontendAssets
This can be achieved using the Route extender, which is more
flexible, as it does not necessary connect the URL with the current
frontend's router.
(Example use-case: The ext-embed frontend will be a new frontend,
however any routes using this frontend will be part of the forum
route group.)
Refs #851.
Refactor Frontend + Asset code
- Use Laravel's Filesystem component for asset IO, meaning theoretically
assets should be storable on S3 etc.
- More reliable checking for asset recompilation when debug mode is on,
so you don't have to constantly delete the compiled assets to force
a recompile. Should also fix issues with locale JS files being
recompiled with the same name and cached.
- Remove JavaScript minification, because it will be done by Webpack
(exception is for the TextFormatter JS).
- Add support for JS sourcemaps.
- Separate frontend view and assets completely. This is an important
distinction because frontend assets are compiled independent of a
request, whereas putting together a view depends on a request.
- Bind frontend view/asset factory instances to the container (in
service providers) rather than subclassing. Asset and content
populators can be added to these factories – these are simply objects
that populate the asset compilers or the view with information.
- Add RouteHandlerFactory functions that make it easy to hook up a
frontend controller with a frontend instance ± some content.
- Remove the need for "nojs"
- Fix cache:clear command
- Recompile assets when settings/enabled extensions change
* Run extenders exported by extensions
* Add some basic extenders
* Patch Mithril as the very first thing so extension code can run safely
* Load the payload into the app before booting extensions
* Setup default routes before booting extensions
In the future we may have multiple Formatters, so by moving the config
callback to its own instance method we can leave the constructor
available to specify which formatter (like Assets and Routes). This
format also allows for other methods to be added.
Additionally, this adds logic to automatically flush the Formatter cache
whenever the extension is enabled or disabled.
* Replace gulp with webpack and npm scripts for JS compilation
* Set up Travis CI to commit compiled JS
* Restructure `js` directory; only one instance of npm, forum/admin are "submodules"
* Refactor JS initializers into Application subclasses
* Maintain partial compatibility API (importing from absolute paths) for extensions
* Remove minification responsibility from PHP asset compiler
* Restructure `less` directory
Now we have two extenders:
- `Extend\LanguagePack` is the "convention over configuration" loader
for complete language packs.
- `Extend\Locales` can be used to load files (by locale) from a given
directory - useful for extensions that bring along their own locales
in multiple different languages.
Refs #851.
Turns out Container::call() does not work with invokable classes.
Thus, we need to wrap callables in a custom extender class to
support injecting any resolvable type-hint automatically.
Refs #851.
This simplifies the API and gives extension developers more
flexibility, for a) maintaining backwards compatibility, and
b) doing advanced stuff that extenders do not allow.
Note that only extenders are guaranteed to work across
different versions of Flarum (once the API surface is stable).
See the discussion in https://github.com/flarum/core/pull/1335.
This makes it more consistent with other existing extenders,
while also making registration of multiple routes more
comfortable for extension developers, and likely slightly
more performant. :-)
Loading the activated extensions now means retrieving an array of
extenders (classes that implement a certain type of extension of a core
feature in Flarum).
For now, the only existing extender is the Compat extender which is used
to handle old-style bootstrappers that simply return a closure that
receives all of its dependencies via auto injection.
In the future, extensions will be able to return an array of extender
instances from their bootstrapper instead. These extender classes will
be implemented in the next step.
- Use contextual namespaces within Flarum\Core
- Clean up and docblock everything
- Refactor Activity/Notification blueprint stuff
- Refactor Formatter stuff
- Refactor Search stuff
- Upgrade to JSON-API 1.0
- Removed “addedPosts” and “removedPosts” relationships from discussion
API. This was used for adding/removing event posts after renaming a
discussion etc. Instead we should make an additional request to get all
new posts
Todo:
- Fix Extenders and extensions
- Get rid of repository interfaces
- Fix other bugs I’ve inevitably introduced
A good start I think, but still some work to do. If we go ahead with
https://github.com/flarum/core/issues/132#issuecomment-117507974 (which
I am in favour of), we can extract the entity-related stuff into some
smaller service providers (e.g. discussion repo, an event listener,
permissions, and gambits stuff could all go in
Flarum\Core\Discussions\DiscussionsServiceProvider).
Type hinting User should take place in the callbacks. Theoretically
these traits could be used for another project now, where something
else has permissions (like a Sheep class, or a number)
