I am mostly done with the massive refactoring effort. So I guess I can finally 
start looking at the MCP task.

There's definitely more code to clean up, but it is fairly well isolated. At 
the top level, I think the structure is solid. The main changes:

1. Abandoned the idea of separating controllers from Swing components and 
treating components as mere "views". It only took us 20 years to give up 
fighting the framework :) Vanilla Swing components are this old-school 
beautiful OO: deep inheritance hierarchies (something frowned upon these days), 
easily composable, cleanly encapsulated. Web development is all stateless 
processors, so stateful component-based OO design is a lost art in Java.

2. All the Modeler state is stored in two classes - Application and 
ProjectSession. Common component superclasses are created to pass those two 
around the hierarchy (so there's AppPanel, AppDialog, ProjectPanel, 
ProjectDialog, etc. classes.) Make sure you use them when creating new 
components. On a side note, the use of DI in the Modeler is completely alien 
and is getting in the way. Have to keep it only for the purpose of overriding 
defaults from cayenne, cayenne-project and cayenne-dbimport (I'd rather we use 
builders in those instead of DI). 

3. Fixed preferences mess. There's a single "repository" to map prefs locations 
(PreferencesRepository), and a bunch of highly custom PreferenceAdapters. Very 
easy to create new preferences (and hence capture more user selections, 
component sizes etc.) Feature wise:

* A 5.0-specific preference tree root, so that we don't pollute common JVM 
preferences namespace
* Auto-migrations of most existing preferences to the new root
* GUI for preferences export as JSON 
* GUI for resetting preferences back to defaults (with or without 4.x 
re-migration)

(still a few issues remain around renaming DataMaps and projects... working on 
those)

4. Small UI fixes: clean window resizing behavior, borders around editable 
table fields, etc. Haven't done FlatLaf yet.

5. Proper event hierarchies (clean immutable events); removed project events 
from the core.

6. Logging console - still ugly, but consistent and functional. 

I have a request for the community - before we make an M2 release, could you 
create a local Modeler build and take it for a spin? Due to the sheer volume of 
changes, there may be some regressions. If you see anything broken, please open 
a Jira and assign to me.

Thanks,
Andrus


> On Apr 20, 2026, at 10:23 AM, Andrus Adamchik <[email protected]> wrote:
> 
> So I feel like the advent of agentic coding opens up new possibilities for 
> CayenneModeler. While some want you to think you can simply prompt Claude to 
> "Rewrite CayenneModeler in JavaFX" (or Electron or JetBrains Compose 
> Multiplatform), still with our limited resources, building and supporting an 
> entirely new thing is realistically out of reach. 
> 
> But I think we can take the current Swing app to a new level by augmenting 
> our rusty Swing skills with AI. A few of my experiments adding this or that 
> UI piece were mostly successful. A few idea on top of my mind:
> 
> 1. A built-in MCP server for DB Import and CGen. This is to close the loop on 
> agentic coding, allowing to use both of these tools from an agent CLI. (The 
> MCP idea was what prompted me to look into this to begin with)
> 2. Fix table editors UX (selections conflicting with cell editors)
> 3. Write unit tests
> 4. Modernizing L&F. Not sure how far we can get while staying in Swing, but 
> worth a try. Looking at FlatLaf lib, which is a successor of JGoodies that we 
> already use
> 5. Implement dozens of small usability features (such as showing currently 
> selected Obj|DbEntity in tab view headers, etc.)
> 
> My first pass (about 70% done) was not anything visual, but rather 
> refactoring the existing messy code to rid it of various architectural 
> experiments accumulated over the years (such as auto-bindings) and unifying 
> the MVC structure to be as close as possible to vanilla Swing. Ironically, 
> Claude was not that helpful in this process. It was good old IDE refactoring, 
> manually going through hundreds of files chasing dead code and 
> inconsistencies. 
> 
> Anyways, just putting this on the radar.
> 
> Andrus

Reply via email to