[REVIEW] Make controller instantiation customizable

[Daniel Zwolenski]

Fine by me.

One last go at it: I still would really rather a String though for the
factory. It solves the classloader issue without further changes needed and
in a much more flexible way to the proposed FXMLLoader.setClassLoader idea.
It also allows for future change (i.e. use a URL or a groovy script file as
the fx:controller variable at some point in the future - in negotiation
with the tooling guys, etc).

*You can still have a rule* that the fx:controller must be a classname,
it's just that the factory does the class.forName instead of the FXMLoader
doing it. Tiny little shift of code from one spot to the next. To me that's
the job of the factory anyway, since it is responsible for turning the
String in the FXML file into a Controller instance.

If I choose, in my own little codespace to hack like a cowboy and slot
something else into that string - well that's me being dodgy and I
certainly wouldn't expect the tooling to support that - the tools should
throw an almighty error and send me packing.

I'll live if you go for a class though (my hack will just be to use a
generic com.zenjava.Controller for every fx:controller) but I really do
think it is an argument around classloading and not limiting yourselves for
the future. Enough said on my end, you guys make a call and I'll run with
it.


On Sat, Dec 17, 2011 at 11:53 AM, Richard Bair <richard.bair at oracle.com>wrote:

> >> <?param name="presenter"
> type="com.zenjava.contacts.search.ContactSearchPresenterInterface"/>
> >> <?param name="model"
> type="com.zenjava.contacts.search.ContactSearchModelInterface"/>
> >
> > OK, that's what I thought. You basically want a way to declare typed
> arguments to the document. I understand why this might be appealing, but I
> do think it requires some additional thought.
> >
> > I also think that this discussion is independent of the current
> discussion about ControllerFactory. It basically represents a possible
> alternative to the existing controller construct. However, the controller
> is currently part of the public API and works well in many scenarios, so it
> probably isn't going away any time soon. Since ControllerFactory addresses
> a valid requirement with respect to that controller, I'd suggest that we go
> ahead with the proposed (typed) version of ControllerFactory and revisit
> the param concept in a later release.
>
> That's what I was thinking too. If the <param> approach turns out to be
> taken, then in many ways the ControllerFactory becomes less important
> because for all those custom dependency injection sort of scenarios, you
> can actually just use the <param> approach instead (and probably would?).
> But ControllerFactory isn't painful, especially if it is just a Callback ;-)
>
> Richard
>
>