Proposal for improving nested controller interaction in JavaFX 2.2

[Dr. Michael Paus]

Hi Dan,

I have to admit that you somehow lost me in this discussion :-)
Could you explain or provide an as simple as possible example
of what you want to achieve and cannot do by either using the
controller factory feature of JavaFX 2.1 or by simply not using
any controller at all?

Especially the last option, not to use any controller, makes sense
to me in your case and I currently have the feeling that this
might actually lead to better separation of concerns anyway.

You said that "I see FXML as a View replacement technology only [...]" 
and so do I.
So the consequence is to use FXML only to define the scene graph but not 
to do
any wiring in there because that can be done equally well in your code
outside of any controller.

         Pane pane = ... (get pane from FXMLLoader)
         TextField firstNameField = 
(TextField)pane.lookup("#firstNameField");
         firstNameField.hook that up to whatever you like.

To my opinion this would also make the separation between
the programmers and the designers work cleaner. I would like
to be able to tell a designer to create a few proposals for an
input panel for example. My only requirement might be that this
panel should have an input TextField and some action button each with
a given ID. The designer should not be concerned with wiring that up
to my program logic. That would be the sole responsibility of the
programmer which can be done without knowing anything about
the designers work as long as the basic contract, as defined above,
is satisfied.

What do you think?

Michael


Am 22.02.2012 01:58, schrieb 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
>>
>>


-- 
--------------------------------------------------------------------------------------
Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS).
For more information visit www.jugs.de.