Proposal for improving nested controller interaction in JavaFX 2.2

[Jeff McDonald]

>
> 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.
>

There really are two different threads going on here. One thread is
question about a specific "controller" implementation. The second thread
asks a more fundamental question about is the current design of FXML the
best approach.
On the topic of the proposed changes to the controller implementation ...
the proposed changes solve the nested controller problem it was intended to
solve. Being a devil's advocate the explicit use of a Map to store
controllers made me wonder ... what happens if I really want a a list of
controllers (say I want fallback controllers) or what if there's some sort
of conditional use controller? At that point it might be easier just to
have a scene graph and wire things up by hand or use some controller naming
convention (hmmmm ... sounds like a lot of work). Just random thoughts.



> >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?
>

Nothing in JavaFX requires the use of controllers, so how does the
inclusion of "controller" support affect FXML's usability? The downside to
working on controller code is that there's a lot of low lying fruit that
could add greater value to FXML than the controller code.


> 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.


+1 This brings me to my next question. Once you bring a scene graph into
memory, what utils/tools does the JavaFX offer or support for traversing
the scene graph? FXML would benefit from having tools/utils that make it
easier to query and traverse the scene graph. A DOM like API would be nice.
A DOM would allow developers to do something like:
Button submitButton scene.getById("submit_button"); //Gets the object with
an fx.id == "submit_button"
submitButton.onMouseClicked(clickHandler);

XPath could be used to traverse and query the graph. The graph can be
treated like XML and the graph is essentially a DOM instance.


> *2. Pattern agnosticism:* for me I want to use FXML as a low-level plumbing
> tool for building scene graphs and nothing more.


+1 Hopefully the reasoning is just intuitive. As I mentioned above, the low
level support seems to be lacking, how would you


> 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.
>

FXML might not be a part of a RAD tool, but I'd rather use a RAD tool than
hand code lots of things. There's nothing inherently wrong with having a
monolithic controller, but what's the design or productivity win by
blessing a monolithic controller in the library code?


> *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.
>

Good points.


> 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.
>

The other pink elephant in the room ... what's the FXML plan for supporting
custom components and composite components?

Cheers,
Jeff