New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support SceneLifecycle for Java based Views #470

Open
lestard opened this Issue Feb 3, 2017 · 4 comments

Comments

Projects
None yet
2 participants
@lestard
Collaborator

lestard commented Feb 3, 2017

With #381 we introduced a basic lifecycle concept for ViewModels.
At the moment this is only available for ViewModels that belong to a FXML-based view.
With this issue the same feature should be implemented for Java-based views.

@georgeVasiliu

This comment has been minimized.

Show comment
Hide comment
@georgeVasiliu

georgeVasiliu Jan 5, 2018

Just throwing this as a comment, if one really needs to access a dispose/clean-up method in a View, wouldn't the following logic apply: (?)

  • ViewModel that implements SceneLifecycle has it's onViewRemoved() called;
  • in that method, the user implements the view model's cleanup, after that, he adds as a last line in that method the following: publish("Clean view");
  • in the View that implements that ViewModel, the user subscribes to that messages, and when it arrives, it triggers a private method designated by him, in which he performs the view's cleanup and finally unregisters the listener for that message;
  • thus, when the ViewModel has it's onViewRemoved() called, the View's own private method gets called by the use of publish/subscribe;

Just throwing this as a comment, if one really needs to access a dispose/clean-up method in a View, wouldn't the following logic apply: (?)

  • ViewModel that implements SceneLifecycle has it's onViewRemoved() called;
  • in that method, the user implements the view model's cleanup, after that, he adds as a last line in that method the following: publish("Clean view");
  • in the View that implements that ViewModel, the user subscribes to that messages, and when it arrives, it triggers a private method designated by him, in which he performs the view's cleanup and finally unregisters the listener for that message;
  • thus, when the ViewModel has it's onViewRemoved() called, the View's own private method gets called by the use of publish/subscribe;
@lestard

This comment has been minimized.

Show comment
Hide comment
@lestard

lestard Jan 5, 2018

Collaborator

Hi @georgeVasiliu
thanks for your comment. Basically this is correct. It's a valid strategy for cleaning up the View if nessessary.

However, this aspect is not directly related to this issue here. It is not the goal to introduce a dispose/clean-up method in Views. Instead, the goal here is to enable clean-up via lifecycle listeners for ViewModels that belong to Non-FXML views. At the moment the SceneLifesycle only works for ViewModels that belong to an FXMLView, not JavaView. This is what needs to be implemented.

Collaborator

lestard commented Jan 5, 2018

Hi @georgeVasiliu
thanks for your comment. Basically this is correct. It's a valid strategy for cleaning up the View if nessessary.

However, this aspect is not directly related to this issue here. It is not the goal to introduce a dispose/clean-up method in Views. Instead, the goal here is to enable clean-up via lifecycle listeners for ViewModels that belong to Non-FXML views. At the moment the SceneLifesycle only works for ViewModels that belong to an FXMLView, not JavaView. This is what needs to be implemented.

@georgeVasiliu

This comment has been minimized.

Show comment
Hide comment
@georgeVasiliu

georgeVasiliu Jan 5, 2018

@lestard

This comment has been minimized.

Show comment
Hide comment
@lestard

lestard Jan 5, 2018

Collaborator

I'm happy to review Pull-Requests for this.
For the topic of your initial comment, we have a separate issue that intends to introduce a lifecycle method for View classes here: #471
I think both approaches are valid. Using a lifecycle in Views or use the publish/subscribe mechanism that you've described.

Collaborator

lestard commented Jan 5, 2018

I'm happy to review Pull-Requests for this.
For the topic of your initial comment, we have a separate issue that intends to introduce a lifecycle method for View classes here: #471
I think both approaches are valid. Using a lifecycle in Views or use the publish/subscribe mechanism that you've described.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment