A BEAR.Sunday application transfers the state of a resource that can be represented (REST)
using a script found in
A BEAR.Sunday app has a run order of
$app application object is created through
AOP configuration depending on a specified
$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.
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).
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.
You can also use a combination of these built-in contexts and add your own custom contexts.
appis the default application context. It will be rendered in JSON.
apimodifies page resources to an app resource by default. Also any web root access (
GET /) that is usually mapped to
page://self/will is re-mapped to
cli-apprepresents a console application. If you set the context to
prod-hal-api-appyour application will run as an API application in production mode using the HAL media type.
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 values of each context will be only used when generating an object graph. It is not recommended for your application code and libraries to change their behaviour based on the context. Instead, the behavior should only change through code that is dependent on an interface and changes of dependencies by context.