javafx.scene.input.*Event classes construction

[Richard Bair]

Hi Martin,

Another use here is that you may want to intercept an event in a filter and create a new synthetic event (possibly of a different type) and the dispatch the new event.

As for the approach, I think you do the constructors with all params (since events are immutable you have no choice really -- static factory or constructor and I prefer in this case a constructor) + builder (auto generated).

Cheers
Richard



On Jun 14, 2012, at 3:39 AM, Martin Sladecek <martin.sladecek at oracle.com> wrote:

> Hello,
> I'd like to discuss possible solutions to the following issue: " Add proper constructors & factory methods to event classes, remove impl" ( http://javafx-jira.kenai.com/browse/RT-9383 ).
> 
> Current situation is that we have many impl_*event and impl_copy factory methods on Event subclasses in javafx.scene.input package. These methods exists are called from Scene, which processes events from Quantum a creates new Event objects. These methods will be removed and replaced with public methods/constructors.
> 
> There are 2 main issues that need to be discussed:
> 
> #1 - possible ways to construct Event objects
> Currently, we have impl_*event methods that have all the possible event fields as parameters + impl_copy methods that copies the event with some of it's fields modified.
> 
> The straightforward solution is to convert impl_*event methods to constructors (and possibly add some shorter constructors) and convert impl_copy methods to standard public (factory) methods.
> One drawback is that we'd have to add more (and bigger) constructors in the future, when some other properties are added to events, although this is going to happen only really occasionally.
> 
> Another possibility is to use builders instead of constructors / factory methods and avoid the very long parameters lists. Or at least add them for convenience.
> 
> #2 - possible use-cases for user-constructed events
> I think testing is the most obvious use-case. In the original JIRA issue, the use-case was to record the events and then "replay" them during the test. This is however not going to work with current API and Scene implementation. To replay the events, we would need to let the Scene process the events and there's not API for this.
> 
> Event.fireEvent applied on a Scene will just send these events to the appropriate event handlers, but won't trigger Scene processing that is done before these events are normally created in the scene, e.g. drag & drop processing.
> To support this, Scene event processing would have to be rewritten and a new method for passing Event objects to Scene would have to be created.
> 
> 
> -Martin