WorkItemManagerFactory
in package
Lazy access to {@see WorkItemManager} that breaks the circular DI dependency of the module.
WorkList is the job (historical name), WorkSheet is a work sheet inside a job.
Dependency graph ([F] = via this factory):
WorkListManager -> WorkSheetManager (creating a follow-up sheet)
WorkListManager -> [F] WorkItemManager (billable work items, preview)
WorkSheetManager -> [F] WorkItemManager (delete guard: work item counts per sheet)
WorkItemManager -> no Work* manager (the cycle is cut here)
The factory stays because WorkSheetManager and WorkItemManager are one step from a cycle:
if the work item manager ever needs something back from the sheet manager, constructor
injection in both directions cannot be built by the container, while a lazy lookup from the
already built container is immune. Reading work items with raw DBAL in the callers is not an
alternative: a second copy of the "what is billable" rule would drift from what the invoice
modal shows, which is unacceptable for money.
Table of Contents
Properties
- $container : Container
- $instance : WorkItemManager|null
Methods
- __construct() : mixed
- create() : WorkItemManager
- Returns the work item manager.
Properties
$container read-only
private
Container
$container
$instance
private
WorkItemManager|null
$instance
= null
Methods
__construct()
public
__construct(Container $container) : mixed
Parameters
- $container : Container
create()
Returns the work item manager.
public
create() : WorkItemManager
Container::getByType() returns a singleton; the local cache only saves repeated lookups
(invoicing asks twice: billable selection and the re-check before writing).