Discussing FX inspired composable dsl pattern

[ivan-velikanov]

Hi @hjohn — reviving this closed thread ( #1 ) only to show you where your feedback led, not to reopen anything. I went ahead and built the composable DSL we'd debated — luvjfx (https://github.com/luvml/luvjfx) — and I ended up adopting most of your objections as hard constraints rather than arguing them. The two libraries are fully independent and coexist happily; I mostly wanted to show you the parts that came straight from your comments, and how I lean on your reactive layer rather than reinventing it.

Things you were right about, now baked in:

• Discoverability is non-negotiable. I dropped the free-static t()/value() idea entirely. Every property is a fluent method on a typed wrapper, so it's pure IDE autocomplete — you learn ~50 factory names (which mirror the JavaFX class names: VBox→vbox) and the IDE surfaces the rest. Your "t/onAction out of nowhere" smell is gone, because the target type is always visible at the call site.
• No forced .build(). Factories return a thin wrapper holding the real node in a public .node field; .attr(n -> …) hands you the typed node for anything uncovered. Nothing is ever blocked.
• "Compose shared behaviour via default methods on interfaces" — that's literally the spine: a self-typed FxNodeOps<S,N> base, one trait-interface per property, bundled per control, all default methods. And I don't hand-write them (your "it grows every release" worry): the whole surface is generated from JavaFX by reflection — 367 property-traits across 51 controls, re-runnable per release. What you write stays plain Java.

The one idea I'd offer back. Your sticking point was: "if I had a way to mark Node as one of the accepted vararg parameters, I'd be all for a type-safe solution." Typing the vararg as a functional interface — Consumer<? super N> — turns out to be that key. A bare configurator lambda and typed children then share one argument list, all checked against the node:

import static luvjfx.Fx.*;

var form = vbox().spacing(8).padding(16).nodes(
    label("Name"),
    textField().promptText("Your name"),
    button("OK").defaultButton(true).onAction(e -> submit())
);

// config-lambda + children in one varargs; raw/foreign nodes wrap via fx(...):
vbox(v -> v.spacing(8), label("Name"), fx(existingJavaFxNode));

It reads like SwiftUI/Flutter — but stays plain Java. The same little form across three declarative UIs:

// SwiftUI
VStack(spacing: 8) {
    Text("Name")
    TextField("Your name", text: $name)
    Button("OK") { submit() }
}

// Flutter (Dart)
Column(children: [
  const Text('Name'),
  TextField(onChanged: (v) => name = v),
  ElevatedButton(onPressed: submit, child: const Text('OK')),
]);

// luvjfx (Java)
vbox().spacing(8).nodes(
    label("Name"),
    textField().promptText("Your name"),
    button("OK").onAction(e -> submit())
);

Same nested tree, same terseness (actually more terse than flutter) — but no new language, no compiler plugin, no build(), and .node is a real TextField you can do anything with. That was the whole motivation: JavaFX can read as cleanly as the declarative-UI crowd without anyone leaving Java.

Your reactive layer, used as-is. I deliberately didn't rebuild Observe/Domain/Model — that part of FX is genuinely well-designed, so luvjfx just binds to it. luvjfx builds the tree, fx-values owns value+validity, and they meet only at ObservableValue/Property:

var roundTrip  = BooleanModel.of(false);
var departure  = ObjectModel.of(today, Domain.bounded(today, today.plusYears(1)));
var returnDate = ObjectModel.<LocalDate>of(today.plusDays(7), Domain.any());

// the return date's *domain* depends on departure — your Observe + Domain:
Observe.values(roundTrip, departure)
    .compute((rt, dep) -> Boolean.TRUE.equals(rt) && dep != null
        ? Domain.bounded(dep, dep.plusYears(1)) : Domain.inapplicable())
    .subscribe(returnDate::setDomain);

datePicker().disable(roundTrip.map(rt -> !rt))          // generated ObservableValue binding overload
    .attr(dp -> Models.edits(dp.valueProperty(), returnDate));   // edits = a 3-line control→model bridge
button("Book").disable(Observe.booleans(departure.valid(), returnDate.valid()).allTrue().map(v -> !v));

(fx-core/fx-values aren't on Central yet, so I clone + mvn install them locally — a release would make this an ordinary dependency.)

The model↔control bridge is still a hair verbose (.attr(dp -> Models.edits(...))); I think it can collapse into a fluent .model(returnDate) overload so the wiring disappears entirely — but that's a refinement for another day.

That's all — shared in the spirit of the original exchange. Both libraries stand on their own; if any of this is useful to FX, take it freely, and I'm indebted to your reactive design either way. Thanks for the original pushback — it shaped the whole thing.

[hjohn]

Hi Ivan, sorry for taking a bit to respond, I've been real busy this week trying to push through a major (internal) refactor of FX Flow (the ModelLinker code primarily).

Hi @hjohn — reviving this closed thread ( #1 ) only to show you where your feedback led, not to reopen anything. I went ahead and built the composable DSL we'd debated — luvjfx (https://github.com/luvml/luvjfx) — and I ended up adopting most of your objections as hard constraints rather than arguing them. The two libraries are fully independent and coexist happily; I mostly wanted to show you the parts that came straight from your comments, and how I lean on your reactive layer rather than reinventing it.

Things you were right about, now baked in:

• Discoverability is non-negotiable. I dropped the free-static t()/value() idea entirely. Every property is a fluent method on a typed wrapper, so it's pure IDE autocomplete — you learn ~50 factory names (which mirror the JavaFX class names: VBox→vbox) and the IDE surfaces the rest. Your "t/onAction out of nowhere" smell is gone, because the target type is always visible at the call site.

Yes, this is always a huge help. It's basically Hamcrest vs AssertJ. You mean there is a static import that gets you 50 factory methods, similar to static importing FX -- I think that's really nice.

• No forced .build(). Factories return a thin wrapper holding the real node in a public .node field; .attr(n -> …) hands you the typed node for anything uncovered. Nothing is ever blocked.

Yeah, slightly different idea here, but this also works. Be careful not to reference the builder from the node somehow.

• "Compose shared behaviour via default methods on interfaces" — that's literally the spine: a self-typed FxNodeOps<S,N> base, one trait-interface per property, bundled per control, all default methods. And I don't hand-write them (your "it grows every release" worry): the whole surface is generated from JavaFX by reflection — 367 property-traits across 51 controls, re-runnable per release. What you write stays plain Java.

That works of course. I've chosen an approach where only often used properties are exposed that can't be styled via CSS, so it is mostly behavioral properties. The rest you are expected to style via CSS (too tempting otherwise to do something direct that will not scale well). I may have to see if this can be applied to FX as well, but I fear I may be stuck with an inheritance hierarchy there (but as long as the user doesn't notice, that's fine I suppose).

The one idea I'd offer back. Your sticking point was: "if I had a way to mark Node as one of the accepted vararg parameters, I'd be all for a type-safe solution." Typing the vararg as a functional interface — Consumer<? super N> — turns out to be that key. A bare configurator lambda and typed children then share one argument list, all checked against the node:

I do like the Consumer<? extends N> idea; it's definitely powerful with only a tiny downside. However, I've since sort of embraced the fact you can provide anything. Where as before I had a simple internal solution that did:

• instanceof Node -> Node
• instanceof Builder b -> b.build()
• instanceof String s -> new Label(s)
• null -> skip
• anything else -> new Label("error")

...I've now made this public in a ChildrenStrategy. The strategy has one method that you must provide:

void apply(Node node, List<Object> inputChildren, Consumer<List<Node>> setter)

Basically the strategy gets the node, the "raw" children, and a Consumer to set the actual resolved children. In the strategy you can decide what you want to do for each input. Some use cases:

• Allow null to skip (useful when you want to include a child conditionally)
• Allow plain strings to become labels
  • As you have full control, you can even have special strings
    • If it starts with $ use the key as a resource bundle lookup
    • Other patterns can lead to common controls, images, etc (but can use enums for that!)
• Use enums
  • Like an Icon enum for common icons: Icon.EXCLAMATION, Icon.QUESTION -> translate to an image
• Pass through Node types directly
• And of course the now somewhat mundane auto .build caller

I've done something similar in other places. There is also a TextStrategy and ContentStrategy, which allows you to configure exactly what happens with say an input for a text or promptText (mainly useful for automatic resource lookups). Because these now also accept object, resource keys can come from an enum.

Same nested tree, same terseness (actually more terse than flutter) — but no new language, no compiler plugin, no build(), and .node is a real TextField you can do anything with. That was the whole motivation: JavaFX can read as cleanly as the declarative-UI crowd without anyone leaving Java.

Yes, same reason I build FX Flow. I strongly dislike DSL's (like FXML) and UI coding with many "button1", "button2", etc variables. My UI hierarchy should be visible in the code itself, and I shouldn't have to assign anything to a sea of variables to make a UI.

This is also why I have the NodeEventHandler which is an EventHandler that receives the Node as parameter -- no need to assign a control to a variable if you happen to need it in the handler. Trigger exists for a similar reason.

Your reactive layer, used as-is. I deliberately didn't rebuild Observe/Domain/Model — that part of FX is genuinely well-designed, so luvjfx just binds to it. luvjfx builds the tree, fx-values owns value+validity, and they meet only at ObservableValue/Property:

I'm glad to hear this turned out to be a useful abstraction. I've made many improvements there in the past few weeks, tweaking Domain and Model abstractions to be even tighter. You may run into a few compatibility problems (but this library is still new) that mostly should be easy to resolve. Most recently I added the Rule system that can be used to surface exactly why a value was invalid, which with ValidationMarkerPane you can surface on top of your controls (if you sent out the ValidationEvent). This does require some work when you construct your controls (I use the ModelLinker for this internally), but there is nothing stopping you from sending out ValidationEvent on your own.

The Observe type now also has a multi-subscribe:

Observe.values(a, b).subscribe((a, b) -> { ... });

This will call the subscriber whenever either value changes (or both).

var roundTrip = BooleanModel.of(false);
var departure = ObjectModel.of(today, Domain.bounded(today, today.plusYears(1)));
var returnDate = ObjectModel.of(today.plusDays(7), Domain.any());

// the return date's domain depends on departure — your Observe + Domain:
Observe.values(roundTrip, departure)
.compute((rt, dep) -> Boolean.TRUE.equals(rt) && dep != null
? Domain.bounded(dep, dep.plusYears(1)) : Domain.inapplicable())
.subscribe(returnDate::setDomain);

datePicker().disable(roundTrip.map(rt -> !rt)) // generated ObservableValue binding overload
.attr(dp -> Models.edits(dp.valueProperty(), returnDate)); // edits = a 3-line control→model bridge
button("Book").disable(Observe.booleans(departure.valid(), returnDate.valid()).allTrue().map(v -> !v));

Hah, nice to see you used a similar example :-)

(fx-core/fx-values aren't on Central yet, so I clone + mvn install them locally — a release would make this an ordinary dependency.)

Ah, fx-values is quite old, but fx-core is a bit more recent. There is 0.6.1 that you can get now. There is likely to be some changes though that you'll run into, the API isn't 100% stable yet, and sometimes I need to move things around or rename things to avoid clashes. Nothing is removed though so there should be an alternative.

I think the pipeline also produces snapshots that go to Maven Central.

The model↔control bridge is still a hair verbose (.attr(dp -> Models.edits(...))); I think it can collapse into a fluent .model(returnDate) overload so the wiring disappears entirely — but that's a refinement for another day.

Yeah, that's what the FX Flow builders have. The model method there links the control up to the model, uses the Views that the domain provide, and hooks up validation logic (with pseudo classes and ValidationEvent).

That's all — shared in the spirit of the original exchange. Both libraries stand on their own; if any of this is useful to FX, take it freely, and I'm indebted to your reactive design either way. Thanks for the original pushback — it shaped the whole thing.

Thanks for sharing this, it is really cool to see alternative ideas and implementations, I'll be sure to take a closer look soon!