Framework integration · Yii
Yii
Register only the selected reusable Yii capability providers and keep application composition explicit, including documented fallbacks.
Installation and ownership¶
Install Fight Common, yiisoft/di, and only the Yii/provider packages selected by the
application. The project-yii starter owns the booted configuration,
package groups, environment values, and lifecycle.
Yii uses its current package set rather than a framework major-line range. Check the support matrix before changing resolved Yii packages.
Select providers¶
Register only the matching bounded service provider from
Fight\Common\Adapter\ServiceContainer\Yii for persistence, routing, messaging, HTTP, mail, view, or
filesystem. The application owns the provider list and supplies each provider's collaborators through its own
container definitions.
Persistence uses the selected Yii DB connection. Routing uses Yii's URL generator. Messaging supplies the application's synchronous Fight bus and dispatcher; it does not imply stable Queue transport. HTTP registers the configured Fight transport. Mail, view, and filesystem make their fallback or application policy explicit.
Native and provider paths¶
Shipped native paths cover Yii DB transactional UnitOfWork and URL generation. Yii cache and logging use their standard interfaces or the shared PSR lane. Shared adapters provide HTTP, file storage, process, SMS, publication, observability, and other portable capabilities.
Yii Mail, View, and Filesystem remain native conformance prototypes. The supported paths use Symfony Mailer, Twig/provider templating, and Symfony Filesystem where the native API has not proven the complete Fight contract. A fallback is an intentional supported composition, not silent degradation.
Queue is not stable support¶
Fight Common 1.2 does not publish a stable Yii Queue adapter because compatible stable yiisoft/queue and
production broker releases have not met the gate. A starter may experiment behind the neutral
CommandMessageHandler and EventMessageHandler seam, but that transport is not a stable framework claim.
Future support requires stable upstream releases plus serialization, acknowledgement, retry, failure, signal, and long-running-state evidence. Until then, use synchronous Fight messaging or an explicitly application-owned transport and disclose its status.
Application-owned operations¶
The application owns database schema and transactions, cache/log providers, route definitions, templates, mail transport, filesystem policy, HTTP transport, process limits, scheduled invocation, credentials, health and metrics publication, and deployment. Provider registration does not choose these policies.
Use the Repositories, Messaging, Routing, and Templating guides for component behavior and failure contracts.