update PR and specs
This commit is contained in:
parent
3afeaafc2a
commit
c4f8ae5733
@ -11,9 +11,19 @@ This PR introduces the generic `StudioEventBus` foundation that later Studio cod
|
|||||||
- workspace-to-global propagation,
|
- workspace-to-global propagation,
|
||||||
- project launcher and shell interactions.
|
- project launcher and shell interactions.
|
||||||
|
|
||||||
|
The implementation should be based conceptually on the C# event system located at:
|
||||||
|
|
||||||
|
`/Users/niltonconstantino/personal/workspace.personal/unity/My-Local-Packages/Packages/intrepid-general-utilities/Runtime/SimpleEvents`
|
||||||
|
|
||||||
|
The generic bus machinery should live in shared infrastructure, not in the Studio components module.
|
||||||
|
|
||||||
|
The bus must be thread-safe because background work such as asset recognition, tree refresh triggers, diagnostics updates, and other asynchronous Studio tasks may publish events from outside the UI thread.
|
||||||
|
|
||||||
## Objective
|
## Objective
|
||||||
|
|
||||||
Implement the typed Studio event infrastructure in application code so future Studio work can publish and observe events without string routing or ad hoc direct coupling.
|
Implement the typed Studio event infrastructure so future Studio work can publish and observe events without string routing or ad hoc direct coupling.
|
||||||
|
|
||||||
|
The generic event bus core should be introduced in `prometeu-infra`, while Studio-specific bus composition remains in Studio code.
|
||||||
|
|
||||||
## Dependencies
|
## Dependencies
|
||||||
|
|
||||||
@ -22,7 +32,8 @@ Implement the typed Studio event infrastructure in application code so future St
|
|||||||
|
|
||||||
## Scope
|
## Scope
|
||||||
|
|
||||||
- introduce a generic typed `StudioEventBus`
|
- introduce a generic typed event bus foundation in `prometeu-infra`
|
||||||
|
- introduce Studio-specific global and workspace bus composition on top of that foundation
|
||||||
- introduce a workspace-local bus model
|
- introduce a workspace-local bus model
|
||||||
- support automatic workspace-to-global propagation
|
- support automatic workspace-to-global propagation
|
||||||
- introduce DTO-style event payload contracts
|
- introduce DTO-style event payload contracts
|
||||||
@ -35,37 +46,48 @@ Implement the typed Studio event infrastructure in application code so future St
|
|||||||
- integrating the full packer event lane now
|
- integrating the full packer event lane now
|
||||||
- redesigning the whole shell in this PR
|
- redesigning the whole shell in this PR
|
||||||
- moving visual controls into `prometeu-studio-components`
|
- moving visual controls into `prometeu-studio-components`
|
||||||
|
- placing the generic bus core inside `prometeu-studio-components`
|
||||||
|
|
||||||
## Execution Method
|
## Execution Method
|
||||||
|
|
||||||
1. Introduce a small event contract in `prometeu-studio`.
|
1. Use `/Users/niltonconstantino/personal/workspace.personal/unity/My-Local-Packages/Packages/intrepid-general-utilities/Runtime/SimpleEvents` as the architectural reference point.
|
||||||
2. Use typed DTO events, preferably immutable.
|
2. Port the useful baseline ideas into Java rather than copying Unity-specific structure literally.
|
||||||
3. Make subscription and unsubscription explicit and safe.
|
3. Introduce the generic event bus machinery in `prometeu-infra`.
|
||||||
4. Implement one global bus and one workspace bus type.
|
4. Keep the generic layer unaware of Studio shell semantics.
|
||||||
5. Ensure every workspace event is automatically republished to the global bus.
|
5. Introduce the Studio-specific event contract and bus composition above that generic layer.
|
||||||
6. Keep propagation one-way: workspace to global.
|
6. Use typed DTO events, preferably immutable.
|
||||||
7. Add tests for:
|
7. Make subscription and unsubscription explicit and safe.
|
||||||
|
8. Implement one global bus and one workspace bus type for Studio.
|
||||||
|
9. Ensure every workspace event is automatically republished to the global bus.
|
||||||
|
10. Keep propagation one-way: workspace to global.
|
||||||
|
11. Make publication and subscription management thread-safe.
|
||||||
|
12. Add tests for:
|
||||||
- typed subscription
|
- typed subscription
|
||||||
- unsubscription
|
- unsubscription
|
||||||
- workspace-to-global propagation
|
- workspace-to-global propagation
|
||||||
- no accidental global-to-workspace rebroadcast
|
- no accidental global-to-workspace rebroadcast
|
||||||
|
- concurrent publication and subscription safety
|
||||||
|
|
||||||
## Acceptance Criteria
|
## Acceptance Criteria
|
||||||
|
|
||||||
- `prometeu-studio` has a generic typed `StudioEventBus`
|
- `prometeu-infra` has a generic typed event bus foundation
|
||||||
|
- Studio code has a global and workspace bus composition built on top of that foundation
|
||||||
- workspace buses exist and can be attached to the global bus
|
- workspace buses exist and can be attached to the global bus
|
||||||
- every workspace-published event is observable on the global bus
|
- every workspace-published event is observable on the global bus
|
||||||
- callers do not need to publish the same event twice manually
|
- callers do not need to publish the same event twice manually
|
||||||
- event payloads are DTO-style and not string-based
|
- event payloads are DTO-style and not string-based
|
||||||
|
- publication and subscription handling are safe under concurrent access
|
||||||
- automated tests cover the propagation baseline
|
- automated tests cover the propagation baseline
|
||||||
|
|
||||||
## Validation
|
## Validation
|
||||||
|
|
||||||
- unit tests for bus behavior
|
- unit tests for bus behavior
|
||||||
- basic smoke coverage for publish/subscribe and nested propagation
|
- basic smoke coverage for publish/subscribe and nested propagation
|
||||||
|
- concurrent test coverage for thread-safe event publication
|
||||||
|
|
||||||
## Affected Artifacts
|
## Affected Artifacts
|
||||||
|
|
||||||
|
- `prometeu-infra`
|
||||||
- `prometeu-studio` application infrastructure
|
- `prometeu-studio` application infrastructure
|
||||||
- future shell integration points
|
- future shell integration points
|
||||||
- tests for Studio UI foundation code
|
- tests for Studio UI foundation code
|
||||||
|
|||||||
@ -43,14 +43,18 @@ Initial candidate controls:
|
|||||||
2. Keep each control API small and Studio-facing.
|
2. Keep each control API small and Studio-facing.
|
||||||
3. Keep styling themeable through CSS.
|
3. Keep styling themeable through CSS.
|
||||||
4. Keep user-facing text bindable and locale-safe.
|
4. Keep user-facing text bindable and locale-safe.
|
||||||
5. Refactor the shell layer in `prometeu-studio` to consume these controls instead of raw JavaFX where the controls are now available.
|
5. Establish explicit `subscribe()` and `unsubscribe()` lifecycle hooks in the control layer so event-driven controls can override them when needed.
|
||||||
6. Avoid adding speculative controls with no immediate shell use.
|
6. Establish `onAttached()` and `onDetached()` hooks that call `subscribe()` and `unsubscribe()` respectively.
|
||||||
|
7. Refactor the shell layer in `prometeu-studio` to consume these controls instead of raw JavaFX where the controls are now available.
|
||||||
|
8. Avoid adding speculative controls with no immediate shell use.
|
||||||
|
|
||||||
## Acceptance Criteria
|
## Acceptance Criteria
|
||||||
|
|
||||||
- the first shell-facing controls exist in `prometeu-studio-components`
|
- the first shell-facing controls exist in `prometeu-studio-components`
|
||||||
- those controls are used by the Studio shell code
|
- those controls are used by the Studio shell code
|
||||||
- no new shell control work lands directly on raw JavaFX when a Studio control is now available
|
- no new shell control work lands directly on raw JavaFX when a Studio control is now available
|
||||||
|
- event-driven controls have explicit subscribe and unsubscribe lifecycle hooks
|
||||||
|
- attach and detach lifecycle hooks drive subscription setup and teardown
|
||||||
- theme and i18n compatibility are preserved
|
- theme and i18n compatibility are preserved
|
||||||
|
|
||||||
## Validation
|
## Validation
|
||||||
|
|||||||
@ -51,9 +51,12 @@ Baseline event rules:
|
|||||||
- event publication is local to the process;
|
- event publication is local to the process;
|
||||||
- event publication is strongly typed;
|
- event publication is strongly typed;
|
||||||
- event payloads are DTOs and should be immutable where practical;
|
- event payloads are DTOs and should be immutable where practical;
|
||||||
|
- event publication and subscription management must be thread-safe;
|
||||||
- the baseline model should remain intentionally small;
|
- the baseline model should remain intentionally small;
|
||||||
- a large reactive framework is not baseline behavior.
|
- a large reactive framework is not baseline behavior.
|
||||||
|
|
||||||
|
Thread safety is required because background work such as asset recognition, scanning, diagnostics refresh, or other asynchronous Studio activity may publish events that eventually affect visible UI state.
|
||||||
|
|
||||||
## Global and Workspace Buses
|
## Global and Workspace Buses
|
||||||
|
|
||||||
The baseline event topology includes:
|
The baseline event topology includes:
|
||||||
@ -102,6 +105,21 @@ Shared Studio foundations include:
|
|||||||
- event publication and observation infrastructure;
|
- event publication and observation infrastructure;
|
||||||
- reusable Studio control conventions.
|
- reusable Studio control conventions.
|
||||||
|
|
||||||
|
## Subscription Lifecycle
|
||||||
|
|
||||||
|
Reusable Studio controls must have an explicit subscription lifecycle when they observe events or external state.
|
||||||
|
|
||||||
|
Baseline rule:
|
||||||
|
|
||||||
|
- Studio controls that need event observation should expose subscribe and unsubscribe lifecycle hooks that can be overridden when needed.
|
||||||
|
- Studio controls should also expose attach and detach lifecycle hooks for integration with the UI tree.
|
||||||
|
- `onAttached()` should trigger subscription setup.
|
||||||
|
- `onDetached()` should trigger subscription teardown.
|
||||||
|
|
||||||
|
This exists to make event wiring visible, testable, and safe under UI lifecycle changes.
|
||||||
|
|
||||||
|
The exact base class or interface shape is an implementation concern, but the lifecycle itself is normative.
|
||||||
|
|
||||||
Shared Studio foundations do not include:
|
Shared Studio foundations do not include:
|
||||||
|
|
||||||
- domain-specific workspace business logic;
|
- domain-specific workspace business logic;
|
||||||
|
|||||||
@ -66,6 +66,21 @@ Rules:
|
|||||||
- exhaustive mirroring of upstream JavaFX APIs is not required;
|
- exhaustive mirroring of upstream JavaFX APIs is not required;
|
||||||
- the goal is consistency and clarity, not a perfect one-to-one mirror of every JavaFX type.
|
- the goal is consistency and clarity, not a perfect one-to-one mirror of every JavaFX type.
|
||||||
|
|
||||||
|
## Control Lifecycle Hooks
|
||||||
|
|
||||||
|
Studio controls may need to observe event buses or other external state.
|
||||||
|
|
||||||
|
Rules:
|
||||||
|
|
||||||
|
- the control layer must provide explicit subscribe and unsubscribe lifecycle methods that can be overridden when needed;
|
||||||
|
- the control layer should also provide `onAttached()` and `onDetached()` lifecycle hooks;
|
||||||
|
- `onAttached()` should call `subscribe()`;
|
||||||
|
- `onDetached()` should call `unsubscribe()`;
|
||||||
|
- controls that attach subscriptions must also define how those subscriptions are released;
|
||||||
|
- event-driven controls must not hide subscription lifecycle completely inside ad hoc local wiring.
|
||||||
|
|
||||||
|
These hooks exist so event-driven controls remain predictable and safe to embed in shell and workspace UI.
|
||||||
|
|
||||||
## Typical Control Scope
|
## Typical Control Scope
|
||||||
|
|
||||||
Typical controls that belong in the module include:
|
Typical controls that belong in the module include:
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user