Could FXML use an interface and dynamic proxy for the passive view interface?

Daniel Zwolenski zonski at
Mon Dec 12 14:03:27 PST 2011

Check out my last post on this page of this forum discussion:

I started that whole forum topic when I was first using FXML and was trying
to put together a clean MVP pattern in my code (before I had fully resigned
myself to the 'FXML Compromise' outlined in my latest post).

In the post I give an example of injecting the controller, I don't see why
it couldn't be done with everything (including resource bundles), so
anything that is a setFoo(Foo myFoo) could be accessed in the FXML via a
${}. This could be for assigning values such as <Label
text="${}"/>, or binging properties such as <Label
text="${}/> or even hooking up callbacks, such as <Button

This is a big jump from the current FXML approach though. A less drastic
change might be the original proposal that was the start of that thread:

All of these things need serious working through - there's a lot of hidden
complexity. e.g. defining a CellFactory for a list is near impossible in
FXML at the moment, the interface approach would need some way to solve
this. Also there is the whole issue of contained FXML, where one FXML file
calls out to another - there needs to be a way to share
values/controllers/etc between them but also decouple the called-FXML so it
has no real knowledge of its caller.

We'd also be indirectly addressing or having to think about the following: (fixed, but using a callout to
a factory instead of simpler 'injection') (same as above) (my personal bugbear)

On Tue, Dec 13, 2011 at 6:46 AM, Tom Schindl <tom.schindl at>wrote:

> Am 12.12.11 20:39, schrieb Richard Bair:
> >
> >>> Which got me thinking. Can't we have FXMLLoader use dynamic proxies to
> allow the FXML file to refer to a passive view interface rather than a
> concrete controller implementation? That at least would allow for the
> "Passive View" design pattern to apply extremely cleanly. It still would
> mean, from the developer's perspective, 2 classes instead of 1 (an
> interface for the view and a controller which talks to that interface). I
> would have to think through this a little more (I guess the controller is
> still required, so that the FXML document has something to call for event
> handlers and such, but that the controller would only talk to the view via
> this Passive View interface rather than by grabbing nodes and binding
> things directly??)
> >>>
> >>
> >> See RT-17268 did I get you wrong?
> >
> > I think this covers the ControllerFactory -- ie delegate controller
> construction to the developer -- but is separate from dynamically
> generating an implementation of a Passive View interface.
> >
> > Cheers
> > Richard
> You are right but to seperate the controller from the view this is most
> important one.
> I'm having a hard time making up in my mind how you would envision your
> passive dynamic view interface to work. Could you show us/me some pseudo
> code?
> Tom
> --
> B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
> ------------------------------------------------------------------------
> tom schindl                 geschäftsführer/CEO
> ------------------------------------------------------------------------
> eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
>                      phone    ++43 512 935834

More information about the openjfx-dev mailing list