cathive / fx-guice Goto Github PK

Not sure it matters, since this looks like a dead and abandoned project (no activity in over 3 years), but for what it's worth ...

The class PersistentPropertyBinder is not found in the Java 8 release jar (not in Maven repository, nor in your own Ocicat).

It's here in the code for this project. But not in the releases.

It would be helpful if GuiceFXMLLoader was mock-able by frameworks like Mockito. This makes it possible to wright more unit tests for UI interface code. Currently, attempts to mock GuiceFXMLLoader fail due to:

org.mockito.exceptions.base.MockitoException:
Cannot mock/spy class com.cathive.fx.guice.GuiceFXMLLoader
Mockito cannot mock/spy following:

• final classes
• anonymous classes
• primitive types

This is an example test that would pass if GuiceFXMLLoader was mock-able:
@mock GuiceFXMLLoader guiceFxmlLoader;

@Before
public void setup() {
    MockitoAnnotations.initMocks(this);
}

@Test
public void test() {
    assertNotNull(guiceFxmlLoader);
}

Current snapshot build does not execute in maven because the javafx jar is not added to the buildpath. The install instructions speak of a javafx-runtime-jar parameter but this is not used in the pom itself.

tested with Oracle jdk 1.7.0_40 on Arch with maven 3.1.0

Using the @PersistentProperty annotation; During the call of

updatePropertyField(instance, prefs.get(annotation.key(), null));

the resulting value is null of get(), which then throws and error in the resulting call.

Do you think nulls should be treated special? This is happening at startup when the prefs have not yet been assigned.

title says it all :)

please remove jfx dependency from maven

Hi headcr4sh,

I'm using fx-guice for a day now. I found it easy to set up but I stumbled upon a behavior I'm not sure I fully understand so far but which would probably be a deal breaker for my current project at hand if it turns out the way I think it is. I'd appreciate it if you could help me understand it.

Is it true and intended that a @FXMLComponent controller always has to be its own root node (extends Node) and that the FXML of such a controller must use an <fx:root> without specifying an fx:controller, because otherwise a javafx.fxml.LoadException: Root value already specified. is thrown? And is it therefore true that FXMLs using an actual Node (like <StackPane ...>) as root and/or specifying a fx:controller attribute can only be loaded using GuiceFXMLLoader, hence never be @Injected?

As far as I can see the former cannot be any different since FXMLComponentMembersInjector supplies the controller instance to both FXMLLoader.setController and FXMLLoader.setRoot in FXMLComponentMembersInjector.injectMembers(...). I'm aware that using <fx:root> along with a component controller of Node is a common way to build reusable components but I'm missing the ability to also inject controllers not following this pattern, which are not a Node and whose FXML root node is not <fx:root> but an actual Node with a fx:controller attribute. Do you think you could implement that, are you interested in doing it or do you think it cannot or should not be done? If so, could you please elaborate why?

My last question targets the exception handling. Do you see any way to actually handle a FXMLLoader specific Exception thrown while injecting (see the Runnable created in FXMLComponentMembersInjector.injectMembers(...)) in user code? Right now, if something goes wrong, you end up with a half initialized injected controller instance with all @FXML fields unbound and still null and without any way to react to the failure. I think it would be very desirable to be able to handle those Exceptions gracefully.
I don't know why but setting a Thread.currentThread().setUncaughtExceptionHandler(...) for the Application Thread did not work out of the box. But that would be a crutch anyway.

Edit: Forgot sth. yesterday. About the limitation, which somewhat impairs productivity, the FXML may not declare a 'fx:controller' when used in conjunction with @Inject because this would cause a javafx.fxml.LoadException: Controller value already specified.: I think using fxmlLoader.setControllerFactory(clazz -> instance) instead of fxmlLoader.setController(instance) in FXMLComponentMembersInjector.injectMembers(...) will safely get around that issue while still allowing allowing IDEs to infer the controller of an FXML. So all the nice inspections and code completions work in the controller and the FXML. Also, SceneBuilder can see the controller.

Thanks for your attention, appreciate your reply, regards,
paxbit

Is ControllerLookup still a relevant feature?

As fx-guice is now targeting JavaFX8, and thus supports all features introduced in JavaFX2.2, it also supports getting access to child-controllers as follows:

<VBox fx:controller="com.foo.MainController"> 
...
    <fx:include fx:id="dialog" source="dialog.fxml"/>
...
</VBox>

public class MainController extends Controller { 
    @FXML private Window dialog;
    @FXML private DialogController dialogController;

    ...
}

(source: http://docs.oracle.com/javafx/2/fxml_get_started/whats_new2.htm)

For me, it seems best to remove this class, as - to be useful-, it relies on ParentID, which is broken in JavaFX8.

I've been playing with fx-guice in order to reduce boilerplate fxml loading in a large Javafx application. I have a root Pane that embeds other custom components. I am able to annotate the root Pane with @FXMLComponent and @Inject it, using the injected object as the root of the scene. The custom components that are embedded in the root Panes FXML are not, however, initialized. Before I put any effort into implementing this as a PR, I wanted to see if there is already a way to do this. Maybe I missed something?

Hello,

I have been trying to get your example code for the FXML howto working on the wiki. The first problem I see is this:

Parent root = fxmlloader.load(getClass().getResource("/fxml/Scene.fxml"));

It looks like it returns a "Result" vs a Parent. Is this example non longer how you do this?

I'm having trouble understanding the difference between these two annotations and when to use one or the other. Could someone elaborate?

I'd be happy to add something to the readme if only I could figure it out first :-)

I received a bug report about a wrong version declarartion in the MANIFEST of fx-guice. Looks like the API version of package com.google.inject is 1.3.0 and NOT 3.0.
Changing the version seems to do the trick ... Some kind of unit test to ensure that fx-guice can run within an OSGi context would be nice, though as kind of an additional meassure to prevent further possible errors within the MANIFEST.

I am currently trying to figure out gow to use your GuiceFXMLLoader. from the JavaDocs, you say, you just need to use

@Inject
private GuiceFXMLLoader loader;

whereever you want, though if I use it outside of my GuiceApplication (which are injected classes) the loader is always null.

I tried to understand it with using one of your smaller (great) examples

App: http://pastebin.com/AekWne6d
View: http://pastebin.com/5a44USap
FXML: http://pastebin.com/1b66QhLp
Error: http://pastebin.com/qMcs2nmM

basically the loader is null, so I get a NPE, so my question is: what to do, to initialize it via @Inject?

Thank you already for reading it :)

Your latest release in the github version section is 3.1.3

Isn't it 2.1.3

Missing licence File in Project

I have the problem that there are multiple instances of a class are created in a situation where I would only expect a single instance to be created. I don't know if this is a issue with your framework, with guice or I'm just misunderstanding something :-)

For example in your CalculatorApp: You are injecting an instance of 'CalculatorAppPane' but there are two instances of this class created. You can see this behaviour with this modification to the code of CalculatorAppPane:

public CalculatorAppPane(){
    System.out.println("CalculatorAppPane");
}

public void initialize() {
    System.out.println("initialize");
   ...
}

When I start the app I get:

CalculatorAppPane
CalculatorAppPane
initialize
initialize

I would expect that only one instance should be created or am I wrong?

After a little debugging I found the place where the two instances are created: The first one is created with the call to createInjector(modules) in GuiceApplication, line 104.
The second one is created on line 107. I don't know what exactly is happening under the hood of guice so I don't know what the expected behaviour is but I would say that only with injector.injectMembers(instance) on line 107 the dependencies should be created?

I started with a different way of dealing with preferences injection. Are you interested to add it into your project? It's heavily inspired by your way.

https://github.com/comtel2000/fx-properties-module

Rgrds,
Joerg

Hi there,
it would be cool if you could do a maven central release with the bugfix pullrequest #14 included.

We are using fx-guice as a base for our own framework mvvmfx and are affected by the underlaying bug (#12). We would be happy if we could include a fixed version of fx-guice in our next release.

regards, manuel