Application Laravel Package

Getting Started

Start by installing via Composer: composer require joomla/application "~3.0". Then create a basic application class extending AbstractApplication (for generic apps), AbstractWebApplication (for HTTP apps), or use the ready-made WebApplication for minimal web apps. Override initialise() for setup and doExecute() for core logic—this is where your app’s main behavior lives. The constructor should call parent::__construct() last, and always configure PSR-3 logging in initialise() using setLogger()/getLogger().

Implementation Patterns

• Web apps: Extend AbstractWebApplication or use WebApplication directly; inject Input, Registry, and PSR-3 logger. Use setHeader(), setBody(), getBody() to manage responses. Leverage URI config (uri.request, uri.base.full, etc.) for route/media resolution.
• CLI apps: Note: CLI classes were removed in v2 — migrate to joomla/console instead. For legacy/adjacent use, still rely on AbstractApplication but avoid built-in CLI helpers like <info> tags (those were in removed CLI classes).
• Testing: Use Joomla\Application\Tests\Mocker to generate mocks for AbstractApplication, AbstractWebApplication, etc., with minimal method stubs. Customize mock behavior via mockWeb* helper methods in test classes.
• Logging: Initialize PSR-3 logger in initialise() based on config; use hasLogger() for optional logging. Avoid direct logger access—always go through getLogger().

Gotchas and Tips

• Breaking changes in v2: getBody() no longer has a toBody param; checkToken() now validates tokens (not just presence); $input property is now protected and accessed via getInput(); CLI classes moved to joomla/console. Update notes are essential for migration.
• Session handling: Sessions are opt-in via SessionAwareWebApplicationInterface and trait—don’t assume they’re available by default.
• Mocking pitfalls: The Mocker only mocks common read/write methods; complex logic may need manual mocking of doExecute() or DI injection. Don’t rely on mocked methods mimicking full behavior (e.g., header replace logic is simplified).
• PHP version: Requires ≥7.2; for PHP 8.3/8.4 compatibility, ensure you’re on ≥3.0.1 (fixes deprecations in WebClient).
• Extending core classes: If swapping PSR-7 response implementations (e.g., Symfony instead of Diactoros), override setHeader, getHeaders, setBody, etc., manually.
• Configuration quirks: site_uri and media_uri must be fully qualified if set (e.g., https://example.com/) to avoid relative path issues; unset config values fall back to uri.base derived from request.