DP44/enriched-qwen3-coder-next/Common/DTS.Common/Events/Groups/GroupsList.md

source_files, generated_at, model, schema_version, sha256

source_files	generated_at	model	schema_version	sha256
Common/DTS.Common/Events/Groups/GroupsList/GroupListEditGroupEvent.cs Common/DTS.Common/Events/Groups/GroupsList/GroupListGroupSelectedEvent.cs	2026-04-16T03:26:07.948442+00:00	Qwen/Qwen3-Coder-Next-FP8	1	bca3088a7f9f7005

GroupsList

Documentation: Group List Events Module

1. Purpose

This module defines two Prism-based pub/sub events used to communicate group selection and editing actions within the group list UI layer. Specifically, GroupListEditGroupEvent signals that a single group should be edited (via its numeric ID), while GroupListGroupSelectedEvent signals that a set of groups has been selected (via an array of IDs). These events decouple UI components (e.g., a group list view) from handlers (e.g., a view model or controller responsible for launching an edit dialog or performing bulk operations), enabling flexible event-driven interactions in the application’s MVVM architecture.

---

2. Public Interface

GroupListEditGroupEvent

• Signature: public class GroupListEditGroupEvent : PubSubEvent<int> { }
• Behavior: A Prism PubSubEvent<int> used to publish when a single group is selected for editing. The payload is the group’s integer ID. Subscribers receive this ID to initiate editing logic (e.g., opening an edit dialog for the group with that ID).

GroupListGroupSelectedEvent

• Signature: public class GroupListGroupSelectedEvent : PubSubEvent<int[]> { }
• Behavior: A Prism PubSubEvent<int[]> used to publish when multiple groups are selected (e.g., via multi-select UI). The payload is an array of group IDs (int[]) representing the currently selected groups. Subscribers may use this to enable bulk operations (e.g., delete, assign) or update selection state.

Note

: Both event classes have no public methods, properties, or constructors beyond the inherited PubSubEvent<TPayload> behavior (e.g., Subscribe, Publish). Their sole purpose is to define strongly-typed event payloads.

---

3. Invariants

• GroupListEditGroupEvent always carries a single non-null int payload representing a valid group identifier.
• GroupListGroupSelectedEvent always carries a non-null int[] payload. The array may be empty (indicating deselection of all groups) but must not be null.
• IDs in both events are expected to correspond to existing groups in the system’s data model (though validation is not enforced by the event classes themselves).
• No ordering guarantee is provided for int[] payloads in GroupListGroupSelectedEvent; the order of IDs is implementation-dependent (e.g., reflects UI selection order or internal storage order).

---

4. Dependencies

• Depends on:
  • Prism.Events.PubSubEvent<T> (from the Prism library) — base class for both events.
  • DTS.Common namespace — shared common library (implied by DTS.Common.Events namespace).
• Depended on by:
  • UI components (e.g., group list views) that publish these events on user interaction.
  • View models or services that subscribe to these events to handle group editing or selection logic.
  • Inferred: Any module handling group lifecycle operations (e.g., editing, bulk actions) will likely reference these events.

---

5. Gotchas

• Misleading XML documentation: Both events’ <summary> and <remarks> incorrectly reference "GroupTemplateListGroupTemplateSelectedEvent" and "called when a template is selected". This appears to be copy-paste error or outdated documentation; the actual purpose relates to groups, not templates.
• Ambiguous selection semantics: GroupListGroupSelectedEvent’s payload (int[]) does not distinguish between user-initiated selection changes (e.g., adding/removing items) and explicit "apply" actions. Subscribers must infer intent from context or additional state.
• No validation in event: Neither event validates that IDs exist or are non-negative. Invalid IDs may propagate to subscribers, requiring defensive handling.
• Thread-safety: As Prism PubSubEvent instances, events are published on the UI thread by default (unless configured otherwise), but subscribers must ensure thread-safe operations if they perform non-UI work.
• None identified from source alone for behavioral quirks beyond the above.