[REVIEW] Make controller instantiation customizable

[Tom Schindl]

Hi Daniel,

Looks like you read my mind. I had drafted mail yesterday which had
fairly the same content.

Am 15.12.11 23:18, schrieb Daniel Zwolenski:
> Maybe we should put all the future "what more could FXML be" discussion
> aside - let's spawn that one off to another thread so you can move forward
> on this one. So just looking at your original request for review of the
> factory mechanism:
> 
> In general the factory looks great, except there are some options on how
> the fx:controller value gets passed to the Factory (and consequently the
> URL resolving):
> 
> 1. *getController(Class)* : The FXMLLoader resolves the class from the
> fx:controller attribute and passes this Class into the factory.
> 
> 2. *getController(String)* : The FXMLLoader just passes the String exactly
> as it is defined in the FXML straight to the factory. The factory is
> responsible for resolving the class. By convention the FXML should use a
> 'classname', exactly as it is now but this is enforced by the factory, not
> the FXMLLoader.
> 
> 3. *getController(Class, String)* : The FXML splits the string on a colon
> (:) and resolves the first part to a class (exactly as in option 1). The
> optional second part is passed as the String directly to the factory (much
> like option 2).
> 
> 
> Option 2 is the lowest common denominator and is the most
> flexible/extensible solution. i.e. Option 1 and Option 3 (and many other
> options) could both be supported by option 2 (i.e. the parsing logic just
> moves into the factory).

This makes the Toolig developer in me having a hard time because I don't
have a generic concept I can teach the tooling. You are using a colon
between classname and additional info, next one uses a @ but adds the
extra info in the beginning, ... you get the point ;-)

> 
> All 3 options use the convention that the controller is a well-known class
> in order for tooling support to work. In option 2 however this is enforced
> only by the factory so a custom factory could choose not to enforce this.
> This allows for future extensions (e.g. the fx:controller is actually a
> reference to a groovy script, or is a URL to a controller class not on the
> current classpath, etc). It also allows those using FXML in a non-standard
> way (such as myself) to hook in and hijack this method for custom usage
> sacrificing tool support (this could be viewed as a 'pro' or a 'con' - you
> decide).

I have never thought about scripting but I don't see how option 3 would
not make that impossible:

fx:controller="java.lang.Object:mygroovyscript"

Here once more if the groovy script follows an interface

fx:controller="my.package.MyInterface:mygroovyscript"

the tooling can provide autocompletion, ... .

> 
> Option 1 and 3 introduce the need for special class loading support in case
> the factory wishes to load the controller from one or more external
> classloaders as the FXMLLoader will first need to load the class. In option
> 2 this is avoided, all classloader specifics can be handled internally
> within the factory (where I feel they belong). If we go for either option 1
> or 3 we probably need some more discussion on the classloader mechanism.
> 
> Option 2 has been noted to be inconsistent with the BuilderFactory API but
> this has also been identified as not overly important by Richard.
> 

I'm with Greg on this - to me this feels inconsitent. I can see
Richard's and your point that they don't have anything to do with each
other and so this is just a feeling.

The most important thing for tooling is that you have meta information
which a string is not carrying with it. I know you say you don't need
tooling but I guess if you get it for free (even if you use scripting,
di, ...) you'd not say no.

My option is a tradeoff between what a tooling provider would need to
provide good tooling and you would need to get the most flexible solution.

> I obviously vote heavily for option 2. Over to the floor and/or Richard I
> guess.
> 

I heavily vote for option 3 because it makes all of us happy you as a
DI, Scripting user and me as an Tooling implementor.

> Regardless of the decision, in general, I am very happy that we are getting
> controller factory support and appreciate that the community was listen to
> on this. Nice work.

Same from me. Even if option 1 is the one that finally gets the approval
its a big step forward.

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
http://www.BestSolution.at                      phone    ++43 512 935834