Summary
Placeholder handling currently revolves around a simple string-replacement chain plus bridge-specific registration logic.
Current pieces include:
PlaceholderHandler chaining multiple placeholder APIs over a message string
TextPlaceholder for internal {usb_*} placeholders
- bridge-specific setup in
PlaceholderModule
- optional MVdWPlaceholderAPI integration behind config and plugin checks
Problem
This works, but it leaves placeholder integration awkward to extend and reason about:
- placeholder sources are modeled as generic string replacers
- bridge wiring and plugin checks live alongside internal placeholder registration
- the abstraction does not express the difference between internal placeholder definitions and external placeholder bridges
Goal
Refactor placeholder handling around clearer typed placeholder sources and bridge adapters while keeping current behavior working.
Requirements
- preserve existing internal placeholder behavior
- keep external bridge support possible
- make it easier to add new placeholder integrations without spreading setup logic
- separate placeholder definition from bridge registration where practical
Notes
This is an internal cleanup issue. The goal is clearer extension points and maintainability, not a user-visible placeholder syntax change.
Summary
Placeholder handling currently revolves around a simple string-replacement chain plus bridge-specific registration logic.
Current pieces include:
PlaceholderHandlerchaining multiple placeholder APIs over a message stringTextPlaceholderfor internal{usb_*}placeholdersPlaceholderModuleProblem
This works, but it leaves placeholder integration awkward to extend and reason about:
Goal
Refactor placeholder handling around clearer typed placeholder sources and bridge adapters while keeping current behavior working.
Requirements
Notes
This is an internal cleanup issue. The goal is clearer extension points and maintainability, not a user-visible placeholder syntax change.