umonkey / ufw1
slim based website framework for pet projects
Requires
- php: >=5.5.0
- league/commonmark: 1.0.0
- league/commonmark-ext-table: ^2.1
- monolog/monolog: ^1.17
- phpmailer/phpmailer: ^6.1
- slim/php-view: ^2.0
- slim/slim: ^3.1
- twig/twig: ^2.4
Requires (Dev)
This package is auto-updated.
Last update: 2024-11-29 06:21:49 UTC
README
This projects contains components which I frequently reuse on my websites. It's based on Slim Framework, because it's clean, simple and easy to understand.
Concepts
Uses the ADR pattern (action-domain-responder). Actions are light-weight controllers, with only one action and no logic: the job is to parse input data and pass it to the domain. Domain is a service which handles the input data, does the job (probably invoking other services) and returns the response payload. Reponder renders payload to the actual HTTP response, depending on its contents and other circumstances (XHR, etc). This all makes the application open for unit testing.
Uses dependency injection, named after Symfony services. Services are isolate parts of code which are loaded on demand. Controllers receive arguments extracted from the container by name. Built in services include database, logger, node and file factory, S3, search engine, stemmer, task queue, Telegram notifications, Twig template renderer, a thumbnailer and a wiki engine.
Uses "nodes", individual pieces of content, such as a page, poll, article, forum topic, or a blog entry. This is inspired by Drupal, works well and simplifies document management greatly.
Uses task queue for background task execution. There is a separate daemon which monitors the taskq queue table and runs the task handlers. This lets the application respond quickly, offloading long tasks to the queue worker and serializing tasks. Best for uploading files to the cloud, sending mail and other notifications.
Uses the repository/entity pattern to access data. Entities are currently just wrappers around ArrayObject which enhance it a little. Entities know nothing about the storage and don't interact with it -- that's what repositories do (see the Nodes module). No ORM, no query builders -- SQL is portable and simple enough.
Services
Custom services are configured in config/services.php, standard services are set up with Util::containerSetup().
Folder structure
bin
: maintenance scripts.config
: various settings. File names are sound, comments explain details.docs
: documentation on some components.src
: all source files.templates
: built in Twig templates, can be used as fallback in real applications.tests
: phpunit files.vendor
: third party components.
Installing
$ composer require umonkey/ufw1:dev-default
TODO
Major:
- Switch to action-domain-responder.
- Uncouple wiki, admin UI, blog etc to separate packages.
Minor:
- Some common CLI functions.
- Better unit test coverage.
Recommended reading
- The twelve-factor app, best practices for developing web applications.