Problem
The SDK already provides low-level placement operations (placement.bind, placement.unbind, placement.get) and typed IM helpers such as bindTextarea(), but installer code still has to orchestrate placement registration manually.
In practice this makes installer code more fragile than event handler registration. A typical installer flow wants to declare a small set of placements and register them in one place, similar to eventManager()->bindEventHandlers([...]).
A concrete example from an application installer:
- bind
ONAPPINSTALL / ONAPPUNINSTALL via bindEventHandlers([...])
- bind
IM_TEXTAREA placement separately via bindTextarea(...)
The second step is much more awkward:
- there is no high-level bulk/helper API
- installer code must decide when to call
bind, get, or unbind
- repeated install/reinstall flows can hit REST errors such as
ERROR_CORE: Unable to set placement handler: Handler already binded
So the SDK has typed placement primitives, but no installer-oriented abstraction for declaring and synchronizing placement handlers.
Proposed solution
Add a high-level placement registration service/helper for installer workflows, similar in spirit to bindEventHandlers([...]).
Possible shape:
- a metadata DTO for placement declarations, similar to
EventHandlerMetadata
- a registrar service that accepts a list of placement declarations
- internally it can use
placement.get to inspect current state
- if a placement is already bound to the same handler/configuration, it should skip it
- if a placement is bound but needs to be changed, it can decide whether to unbind+bind or expose that policy explicitly
- return a structured result describing which placements were bound, skipped, updated, or failed
This would make installer code much simpler and reduce repeated boilerplate around placement registration.
Acceptance criteria
Problem
The SDK already provides low-level placement operations (
placement.bind,placement.unbind,placement.get) and typed IM helpers such asbindTextarea(), but installer code still has to orchestrate placement registration manually.In practice this makes installer code more fragile than event handler registration. A typical installer flow wants to declare a small set of placements and register them in one place, similar to
eventManager()->bindEventHandlers([...]).A concrete example from an application installer:
ONAPPINSTALL/ONAPPUNINSTALLviabindEventHandlers([...])IM_TEXTAREAplacement separately viabindTextarea(...)The second step is much more awkward:
bind,get, orunbindERROR_CORE: Unable to set placement handler: Handler already bindedSo the SDK has typed placement primitives, but no installer-oriented abstraction for declaring and synchronizing placement handlers.
Proposed solution
Add a high-level placement registration service/helper for installer workflows, similar in spirit to
bindEventHandlers([...]).Possible shape:
EventHandlerMetadataplacement.getto inspect current stateThis would make installer code much simpler and reduce repeated boilerplate around placement registration.
Acceptance criteria
bindEventHandlers([...])is ergonomic for event handlers