Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extract some low-level code into independent open-source packages #262

Closed
1 of 4 tasks
tobyzerner opened this issue Aug 27, 2015 · 2 comments
Closed
1 of 4 tasks
Labels
stale Issues that have had over 90 days of inactivity type/cleanup

Comments

@tobyzerner
Copy link
Contributor

tobyzerner commented Aug 27, 2015

To reduce Flarum's scope and make it more maintainable, we should consider extracting some application-agnostic code into external packages. Specifically:

  • Our component paradigm that sits on top of Mithril (i.e. the base Component class).
  • Some of the Mithril utilities, like classList and SubtreeRetainer.
  • The whole JavaScript data layer: Store and Model.
  • More of the JSON-API layer, specifically the Actions and Request/Response stuff may be within the scope of the tobscure/json-api package.

Keen to get some thoughts on whether or not this is a good idea, and more than happy for anyone to have a go at extracting some stuff.

tobyzerner added a commit that referenced this issue Oct 8, 2015
- Reorganised all namespaces and class names for consistency and structure. Following PSR bylaws (Abstract prefix, Interface/Trait suffix).
  - Move models into root of Core, because writing `use Flarum\Core\Discussion` is nice. Namespace the rest by type. (Namespacing by entity was too arbitrary.)
  - Moved some non-domain stuff out of Core: Database, Formatter, Settings.
  - Renamed config table and all references to "settings" for consistency.
  - Remove Core class and add url()/isInstalled()/inDebugMode() as instance methods of Foundation\Application.
  - Cleanup, docblocking, etc.

- Improvements to HTTP architecture
  - API and forum/admin Actions are now actually all the same thing (simple PSR-7 Request handlers), renamed to Controllers.
  - Upgrade to tobscure/json-api 0.2 branch.
  - Where possible, moved generic functionality to tobscure/json-api (e.g. pagination links). I'm quite happy with the backend balance now re: #262

- Improvements to other architecture
  - Use Illuminate's Auth\Access\Gate interface/implementation instead of our old Locked trait. We still use events to actually determine the permissions though. Our Policy classes are actually glorified event subscribers.
  - Extract model validation into Core\Validator classes.
  - Make post visibility permission stuff much more efficient and DRY.

- Renamed Flarum\Event classes for consistency. ref #246
  - `Configure` prefix for events dedicated to configuring an object.
  - `Get` prefix for events whose listeners should return something.
  - `Prepare` prefix when a variable is passed by reference so it can be modified.
  - `Scope` prefix when a query builder is passed.

- Miscellaneous improvements/bug-fixes. I'm easily distracted!
  - Increase default height of post composer.
  - Improve post stream redraw flickering in Safari by keying loading post placeholders with their IDs. ref #451
  - Use a PHP JavaScript minification library for minifying TextFormatter's JavaScript, instead of ClosureCompilerService (can't rely on external service!)
  - Use UrlGenerator properly in various places. closes #123
  - Make Api\Client return Response object. closes #128
  - Allow extensions to specify custom icon images.
  - Allow external API/admin URLs to be optionally specified in config.php. If the value or "url" is an array, we look for the corresponding path inside. Otherwise, we append the path to the base URL, using the corresponding value in "paths" if present. closes #244
@franzliedke franzliedke added this to the 0.1.0 milestone Apr 7, 2016
@tobyzerner tobyzerner removed this from the 0.1.0 milestone Jul 22, 2017
@stale
Copy link

stale bot commented Jan 19, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We do this to keep the amount of open issues to a manageable minimum.
In any case, thanks for taking an interest in this software and contributing by opening the issue in the first place!

@stale stale bot added the stale Issues that have had over 90 days of inactivity label Jan 19, 2020
@stale
Copy link

stale bot commented Feb 18, 2020

We are closing this issue as it seems to have grown stale. If you still encounter this problem with the latest version, feel free to re-open it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale Issues that have had over 90 days of inactivity type/cleanup
Projects
None yet
Development

No branches or pull requests

2 participants