(cayenne) 01/07: A draft of the Modeler component architecture

[aa...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

asf-gitbox-commits pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cayenne.git

commit 4542c315d49439eb8f53c2a3d5f4cdec84eb2b0d
Author: Andrus Adamchik <an...@objectstyle.com>
AuthorDate: Fri Apr 24 08:59:20 2026 -0400

    A draft of the Modeler component architecture
---
 .claude/rules/modeler/modeler-architecture.md | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/.claude/rules/modeler/modeler-architecture.md b/.claude/rules/modeler/modeler-architecture.md
new file mode 100644
index 000000000..4ba3603cc
--- /dev/null
+++ b/.claude/rules/modeler/modeler-architecture.md
@@ -0,0 +1,20 @@
+---
+paths:
+  - "modeler/**"
+description: CayenneModeler UI components architecture
+---
+
+CayenneModeler is a Swing application for visually managing Cayenne OR mapping files. 
+
+## CayenneModeler Architecture
+
+The architecture follows the MVP (Model-View-Presenter) pattern with own specifics:
+
+1. MVP instead of MVC ("presenter", not "controller")
+2. Not using interfaces for views (no goal to uncouple controllers from Swing yet)
+3. Views take their presenters in constructor to perform action bindings to the view controls. This keeps presenter
+   at least nominally Swing-agnostic, and in many cases removes the need for getters for the view parts.
+4. Each Presenter creates its own View. Parent Presenter can access that View to add to its own view.
+5. We are NOT yet using Presenter-level listeners for parent sake. We have a fixed hierarchy of Presenters, so this is an overkill.
+
+