Added ScaledVirtualized class

[JordanMartinez]

How's this?
I'm also not sure if there might be some unwanted implications of adding the Scale object to the ScaledVirtualized wrapper and not the Virtualized content itself

[JordanMartinez]

One issue I came across was the lack of access to layoutChildren() after one of the scale's values changes.
For example, if I use ScaledVirtualized, it doesn't redisplay its content properly because, when the one of the scale's values changes, it's layoutChildren() method needs to be called, which isn't public.
However, if I create a class called VirtualizedScaler that extends ScaledVirtualized, and implement my code within VirtualizedScaler, I can now use layoutChildren() where needed.

With that being said, I think ScaledVirtualized should be made abstract.

[JordanMartinez]

On second thought, it would be better to refactor ScaledVirtualized to call layoutChildren() whenever one of Scale's values changes.

[TomasMikula]

I think the correct way is to call requestLayout() instead of layoutChildren() directly. layoutChildren() is then called from layout() during layout pass.

[TomasMikula]

I didn't realize that we don't need an ObjectProperty<Scale>, because Scale's fields can be modified. Then the method is probably better named getScale() instead of scaleProperty().

[JordanMartinez]

K, I've updated the code

[JordanMartinez]

I wonder if the getter should be renamed. It is annoyingly close to Node#getScaleX/Y() in that a developer might use the wrong Scale object mistakenly.

[JordanMartinez]

What about getVirtualizedScaler() or something like that?

[TomasMikula]

You have a point. What do you think about calling it zoom instead of scale?

[JordanMartinez]

Sounds good!

[JordanMartinez]

I added some javadoc to help clarify the name as well

[TomasMikula]

👍