A BEAR.Sunday app has a run order of
$app application object is created through
AOP configuration depending on a specified context.
$app is made up of service objects as it’s properties that are needed to run the application such as a
$app then connects these object together depending on whether it is owned by another or contains other objects.
This is called an Object Graph.
$app is then serialized and reused in each request and response.
- router - Converting external input to resource requests
- resource - Resource client
- transfer - Output
An application resource request and resource object is created based on the HTTP request.
A resource object which has methods that respond to
onPost etc upon request sets the
body property of it’s own resource state.
The resource object can then
#[Link] other resource objects.
Methods on the resource object are only for changing the resources state and have no interest in the representation itself (HTML, JSON etc).
Before and after the method, application logic bound to the method, such as logging and authentication, is executed in AOP.
Renderer is injected into the resource object, then the state of resource is represented as HTML, JSON etc or however it has been configured, it is then transfered to the client.
To run an application, we need just two lines of code.
An entry point for a web server or console application access is usually set to
As you can see below, we need to pass an application context to
bootstrap.php the application script.
<?php require dirname(__DIR__) . '/autoload.php'; exit((require dirname(__DIR__) . '/bootstrap.php')('prod-html-app'));
Depending on your context choose a boot file.
// fire php server php -S 127.0.0.1:8080 public/index.php
// console access php bin/app.php get /user/1
The composition of the application object
$app changes in response to the defined context, so that application behavior changes.
Depending on the defined context the building of the application object
$app changes, altering the overall behavior.
WebRouter is bound to
RouterInterface by default.
Cli mode is set (instead of HTTP) the
CliRouter is bound to the
RouterInterface and it will then take console input.
There are built-in and custom contexts that can be used in an application.
app, resources are rendered in JSON.
api changes the default resource schema from page to app; web root access (GET /) is from page://self/ to app://self/.
cli to be a console application.
prod` makes it a production application with cache settings, etc.
You can also use a combination of these built-in contexts and add your own custom contexts.
If you set the context to
prod-hal-api-app your application will run as an API application in production mode using the HAL media type.
Place it in
src/Module/ of the application; if it has the same name as the builtin context, the custom context will take precedence. You can override some of the constraints by calling the built-in context from the custom context.
Each application context (cli, app etc) represents a module.
For example the
cli context relates to a
CliModule, then binds all of the DI and AOP bindings that is needed for a console application.
The context value is used only to create the root object and then disappears. There is no global “mode” that can be referenced by the application, and the application can not know what context it is currently running in. The behavior should only change through code that is dependent on an interface1 and changes of dependencies by context.