Skin ListenerHelper

[John Hendrikx]

With subscriptions these kinds of helpers are really not needed anymore.

Just do:

      Subscription combined = Subscription.combine(
          property1.subscribe( ... ),
          property2.subscribe( ... )
      );

And clean it up with `combined.unsubscribe` in `dispose`.

For non-property clean-ups, you can add additional cleanup like this:

      Subscription combined = subscription.and(() -> { extra clean-up 
code });

Alternatively, you can use `when(skinActive)` on most of your observers, 
and set `skinActive` to `false` in dispose.

SkinBase was a mistake IMHO.  Helper methods that require state are 
better placed in an instanced utility, not in a base class. What does it 
mean that a "TableViewSkin" is-a "SkinBase". Using inheritance to get 
access to such helpers (which need a little bit of state) is really a 
classic mistake and misuse of inheritance. ListenerHelper is much better 
in that regard, much more generally usable (since it uses composition), 
and stores its state in its own instance.

--John

On 12/03/2024 00:19, Marius Hanl wrote:
> Since I see multiple discussions about the behaviour API and the 
> RichTextControl, I want to ask another, still important question:
> What is about the Skin cleanup ListenerHelper?
> We now have 2 implementations of such utility - the
> LambdaMultiplePropertyChangeListenerHandler
> and the
> ListenerHelper
> I would really see that this topic is closed and cleaned up, with all 
> TODOs that emerged from this than 2-3 new other open implemention 
> changes on different topics.
> The class is also not public, so extending from something else than 
> SkinBase makes it hard to write your own skin as there is no proper 
> help to register and dispose your listener.
> -- Marius
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240312/4921ff02/attachment.htm>