You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
public class ViewA implements FxmlView<ViewAModel>, Initializable {
@InjectContext
private Context ivContext;
@Override
public void initialize( final URL aUrl, final ResourceBundle aResourceBundle ) {
System.out.println( "Context is " + ivContext );
}
}
In this scenario, the context is injected as expected. Now I convert the view into a JavaView:
public class ViewA extends VBox implements JavaView<ViewAModel>, Initializable {
@InjectContext
private Context ivContext;
@Override
public void initialize( final URL aUrl, final ResourceBundle aResourceBundle ) {
System.out.println( "Context is " + ivContext );
}
}
In this case, the context is null in the initialize method. This is very troublesome for me, as I have no FXML views, but only Java views.
I have a main view which creates further sub views (tabs) and needs to communicate with them via a Scope. The scope is available in the main view model, but is currently not transported to the sub view models, as mvvmFX cannot determine that the subviews are in the same hierarchy as the main view. Therefore I want to use the context of the main view as parent context so that the hierarchy is correct. With this bug this is currently not possible. As the scope cannot be injected into the main view either, I have no chance to create the sub views in the main view currently. Is there any possible workaround?
Thanks and best regards,
Nils
The text was updated successfully, but these errors were encountered:
Hi,
you are right: Scopes aren't working with JavaViews at the moment. The scopes are still in "beta" state because we only have a limited number of applications that are using them and therefore only limited feedback yet. And in our applications we are using FXML for most views which is the reason why we have implemented them for FXML first.
Adding support for JavaViews is on our todo-list but it's not an easy task. I hope I can find the time to take a closer look at it withing the next days but I can't guarantee anything :-)
Until then using FXML based Views would be the best approach. Is there a reason why you can't use FXML? If you need to create your UI in Java-Code maybe you could still use a minimal FXML file that only consists of a container element like this:
publicclassMyViewimplementsFxmlView<MyViewModel> {
@FXMLprivateVBoxroot;
publicvoidinitialize() {
// use Java code to create the ui and add it to "root" container.
}
}
Thank you. I understand that FXML views have a higher priority than the plain Java views for the mvvmFX project. I will try and use the approach with the minimal FXML for the moment, but we should keep this ticket still open.
It is not that I cannot use FXML, I just don't want to. In my opinion the FXML files have more disadvantages compared to views designed in Java.
From the looks of it - shouldn't it be enough to inject the context right after the injection of the view model in the JavaViewLoader, similar to the code in the FxmlViewLoader? A quick test seems to confirm this.
Hi,
Assume following view:
In this scenario, the context is injected as expected. Now I convert the view into a JavaView:
In this case, the context is null in the initialize method. This is very troublesome for me, as I have no FXML views, but only Java views.
I have a main view which creates further sub views (tabs) and needs to communicate with them via a Scope. The scope is available in the main view model, but is currently not transported to the sub view models, as mvvmFX cannot determine that the subviews are in the same hierarchy as the main view. Therefore I want to use the context of the main view as parent context so that the hierarchy is correct. With this bug this is currently not possible. As the scope cannot be injected into the main view either, I have no chance to create the sub views in the main view currently. Is there any possible workaround?
Thanks and best regards,
Nils
The text was updated successfully, but these errors were encountered: