-
Notifications
You must be signed in to change notification settings - Fork 42
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
Refactor skin factory? #6
Comments
I tried to port my application to the new version and failed. Some parts can be fixed on my side, but it seems that programmatically adding new connections (you may remember our earliert conversation on this) is even harder: I got lots and lots of NullPointerExceptions of Skins that do not exist. So I implented this issue (refactoring to CallBack) and refactored the SkinManager to functional programming style to prevent the NullPointerExceptions: eckig/graph-editor@34cb1a6 |
Since the other changes got merged, may I create a pull request for the refactored SkinManager? |
I think this is a good idea but I need some more time to consider how the API should behave exactly. Don't submit a pull request just yet. If you are getting NPE's there must be something else going wrong. Is this the same issue as #10? |
I fixed most of the NPE's, the only remaining is the one in the mentioned issue. |
Currently the skin factories work this way:
In my opinion this has many disadvantages, mostly costing flexibility.
JavaFX uses the very elegant javafx.util.Callback interface to the same thing.
So I would like to propose to change the skin factories as follows:
Instead of using the error prone way of reflection API you can simple call
This way it is of no interest to you how the third party developer implemented his skin and how it is created.
The text was updated successfully, but these errors were encountered: