Proposal for improving nested controller interaction in JavaFX 2.2

[Daniel Zwolenski]

Hi Greg,

Thanks for the reply. I did get that the current controller approach was a
deliberate design decision. To my mind the discussion in December was to
work through the fact that, although applicable/helpful in some
architectures, this design decision was severely limiting ways in which
FXML could be used in other popular architectures, particularly 'clean'
MVP-based architectures. As such, I was hoping we could find ways to make
FXML applicable to as many of the common/popular design patterns as
possible without compromising on the existing support.

>From this latest proposal it looks like the decision on that one is to
stick with the current path and focus on just making it better for the
current "backing controller" pattern. That's fine if that's the case, it
just means that FXML becomes less desirable in the style of apps I am
building (i.e. true MVP-based, business-style applications, based around DI
toolkits such as Spring/Guice) and I'll start investing time in alternate
approaches rather than fighting the FXML API to fit my needs. I'm just
looking to confirm if this is the path being taken or not?

Just for clarity the design goals that FXML currently does not support but
needs to support for it to truly fit in my style of application are:

*1. Technology containment*: I see FXML as a View replacement technology
only (i.e. it provides the 'V' in the MVP or MVC, and not the 'C' or 'P').
For me the fact that I am using FXML would ideally not be visible at all in
the controller/presenter or anywhere outside of the view, apart from in the
loading/factory code. I should be able to replace my FXML view
implementation with a pure Java one and vice versa without any changes to
the controller, etc.

*2. Pattern agnosticism:* for me I want to use FXML as a low-level plumbing
tool for building scene graphs and nothing more. It's not part of a RAD
tool, and I don't want it to provide any kind of "application framework",
which includes controller/presenter instantiation, modularisation and
life-cycle management. FXML should not have any kind of influence around
how I structure/modularise/use my code outside of the view layer. If I
decide I want to have one monolithic 'controller' for my entire application
or an individual micro-handler for every callback method in my application,
FXML shouldn't stop me.

*3. Reusabilty/testability*: the view and presenter elements of my
architecture need to be reusable. I should be able to attach a different
controller to a view and a different view to a controller without any
problems. In practice this doesn't happen all that often in a running GUI
(with the possible exception of sub-controllers where I often want to use
my parent controller as the sub-controller), but it is the cornerstone of
testing. To test my view I should be able to attach a specific instance of
a controller to it and have that controller throw different bits of data at
it, etc. Same goes for my controller - I should be able to easily test it,
without using the FXMLLoader in my tests.

I think that the above could all be achieved through a fairly simple
application of the Inversion of Control
pattern<http://stackoverflow.com/questions/3058/what-is-inversion-of-control>(which
is the pattern behind the modern popular trend towards Dependency
Injection oriented frameworks). Basically FXML could act less like the boss
of the GUI dictating to everything else how things need to be done. Instead
it could just be a humble worker, which is handed the resources it needs to
do its job of building a scene graph and handing that scene graph back to
whoever requested it.

As I said, if these are not the design goals of FXML, that's fine. It just
means I need to start working with (or on) something that is inline with my
design goals instead.

Cheers,
Dan


On Wed, Feb 22, 2012 at 6:42 AM, Greg Brown <greg.x.brown at oracle.com> wrote:

> Should we assume based on this proposal that there's no intent/interest in
> addressing the issues around FXML having such an explicit coupling with its
> controller (as discussed back in December:
> http://mail.openjdk.java.net/pipermail/openjfx-dev/2011-December/000175.html
> )?
>
>
> As I've mentioned before, this is by design. What we're currently calling
> the "controller" is really just the backing logic for the view. As a
> result, there is an inherently tight relationship between the markup and
> the controller code, analogous (but obviously not identical) to .NET's
> partial classes.
>
> One way to minimize the level of this association is by using a controller
> factory. By specifying the name of an interface or an abstract class as
> your document's controller, your factory can determine at runtime which
> concrete factory to provide for a given document.
>
> Another option is to use an external controller, which I believe we had
> been calling a "presenter". The presenter would be responsible for
> instantiating both the view and the model and performing any necessary
> wiring. As far as I know, there's nothing within the current design that
> prevents you from adopting this model within your application.
>
> My point is that, just because we're calling this construct a "controller"
> does not mean that it has to play the role of "controller" in your design.
> Unfortunately the term "controller" has been heavily overloaded, which
> leads to a number of, often conflicting interpretations of its meaning.
>
> G
>
>