Do Transitions really need to be final?

[Daniel Zwolenski]

Thanks for the feedback. The events will help, but they can not cover all
of my use cases. I'm still interested in having animations not be 'final'
and I don't follow the arguments for them being so. Can you expand on this:
'they were not designed to be extended'. Is there some implementation
aspect forcing this, or is it your preferred API?

In the API's of JFX that I've used there are no 'final' classes
(properties, control, concurrent, bindings, etc) and yet they all *could* be
done in a similar non-extending sort of fashion as suggested for
animations. What is it about animations that justify this special
treatment?  For example, 'BorderPane' is not final and this allows me to
define my own custom views as extensions instead of just setting properties
on one. Why would the same logic not relate to ParallelAnimation? I'd like
to be able to create my custom animation class as an extension from this,
just like I create custom views.

In my specific case (as just one example) the event is nothing to do with
the 'animation' life-cycle but it is part of the life cycle of my custom
'Page Transition' class. The animation life cycle is a small part of that
bigger life-cycle so I would like to extend from Animation to include the
normal life cycle but add my own steps to it. In particular I want to do
some pre-initialisation before the Node is added to the scene, which is
well before the actual animation is started.

Cheers,
Dan

On Mon, Dec 19, 2011 at 11:22 PM, Michael Heinrichs <
michael.heinrichs at oracle.com> wrote:

> Hi Dan,
>
> the Transition classes are final, because they were not designed to be
> extended.
>
> There is a request in JIRA to add more events to Animation, which would
> introduce them also in all Transition classes. Can you please take a look
> and comment on which events you are missing.
> http://javafx-jira.kenai.com/browse/RT-14455
>
> The suggested way to add custom transitions is to extend the Transition
> class (there is an example in the JavaDocs). I have to admit though, that
> this story is not finished yet, because of the missing events. Hopefully I
> will be allowed to add them in the 2.1 release.
>
> Thanks,
> Michael
>
>
>
> On 17.12.2011, at 08:25, Daniel Zwolenski wrote:
>
> Hey Guys,
>
> Just wondering if there is a reason for the various transition classes
> (FadeTransition, PathTransition, etc) being final? I'm guessing it's some
> sort of performance thing but I can't really see it.
>
> The reason I ask is because I just went to create a FadeTransition that
> also implemented a custom interface (in my case EntryTranstion, which has a
> setupBeforeAnimation method on it, and a few other things) and discovered I
> couldn't.
>
> I could also see it being useful to be able to extend transitions to form a
> library of transition classes. I could use a factory, but it would seem
> more inline with what's there if I could create a CircularPathTransition
> that extended PathTransition, etc.
>
> Cheers,
> Dan
>
>
>