Framework Documentation - Application Package
Overview
The Application package provides the infrastructure to build and run PHP applications within the
Joomla! Framework.
It answers three questions for you, and deliberately nothing else:
- Where does configuration live? In a
Joomla\Registry\Registryowned by the application. - What is the execution lifecycle?
execute()wraps yourdoExecute()in a fixed sequence of
events, and turns any uncaughtThrowableinto an error event instead of a fatal. - How is the response produced? For web applications, a PSR-7
ResponseInterfacethat the
application sends at the end ofexecute().
Everything else — routing, templating, database access, authentication — comes from other framework
packages. The application is the place where you wire them together.
Class map
ApplicationInterface close(), execute()
└── ConfigurationAwareApplicationInterface + get(), set(), setConfiguration()
└── AbstractApplication abstract, owns config + logger + dispatcher
└── AbstractWebApplication abstract, owns input + client + PSR-7 response
└── WebApplication concrete, routes a request to a controller
WebApplicationInterface the HTTP surface (headers, body, redirect, …)
SessionAwareWebApplicationInterface + getSession(), setSession(), checkToken(), getFormToken()
SessionAwareWebApplicationTrait implementation of the above
ApplicationEvents the five event name constants
Event\ApplicationEvent carries the application
Event\ApplicationErrorEvent carries the application and the Throwable
Controller\ControllerResolverInterface resolve(ResolvedRoute): callable
Controller\ControllerResolver resolves callables, invokables and ControllerInterface
Controller\ContainerControllerResolver same, but pulls controllers from a PSR-11 container
Web\WebClient user agent detection
Exception\UnableToWriteBody thrown when the response body cannot be written
Which class do I extend?
| You are building | Extend | Notes |
|---|---|---|
| A web application with routing | (nothing) — use WebApplication |
Give it a router and a controller resolver |
| A web application with custom dispatch | AbstractWebApplication |
Implement doExecute() yourself |
| A CLI or worker process | AbstractApplication |
You get config, logger, dispatcher, events; no HTTP |
| A console application | (nothing) — use Joomla\Console\Application |
It builds on AbstractApplication |
Dependencies
Required:
joomla/registry— the configuration storejoomla/input— request input (web applications)joomla/uri— URI handling forloadSystemUris()andredirect()joomla/event— the dispatcher used for lifecycle eventspsr/log— loggingpsr/http-message+ a PSR-7 implementation — the response object
Optional, depending on which classes you use:
joomla/router— required byWebApplicationjoomla/session— required bySessionAwareWebApplicationTraitpsr/container— required byContainerControllerResolverjoomla/controller— theControllerInterfacethatControllerResolverlooks for
What this package intentionally does not do
Knowing the boundaries saves time:
- No PSR-7 request. The response is PSR-7, the request is
Joomla\Input\Inputreading from the
superglobals. There is noServerRequestInterfaceanywhere in the package. - No middleware. The lifecycle is the five events listed in
Lifecycle and events; there is no PSR-15 pipeline. - No security headers.
respond()setsContent-Type, cache headers and the status. If you
wantX-Content-Type-Options,Content-Security-PolicyorStrict-Transport-Security, set them
yourself — see Web applications. - No trusted proxy handling.
isSslConnection()looks at$_SERVER['HTTPS']only; it does not
considerX-Forwarded-Proto. Behind a TLS terminating proxy you must handle that yourself. - No error page. The
ERRORevent is dispatched and that is all. If nothing listens, the
request produces an empty response body. See Error handling.