[REVIEW REQUEST] RT-24088 Add API to JavaFX to allow vetoing the closing of a Tab in a TabPane

[Richard Bair]

>> On 6.12.2012 23:09, Jonathan Giles wrote:
>>> Richard and I were just chatting about this patch, and the general feeling is that it feels weird to consume an event and make that indicate the event has been vetoed (despite that being how it is already done in the Window case).
>> 
>> In the case of Window the WINDOW_CLOSE_REQUEST indicates that user wants to close the corresponding Window. As with any other event, the application can install its own handler to this event and respond to this request in its own way. If it does so, it should indicate that the event has been handled by "consuming" the corresponding event (as should be done with any other user handled event). If the event is not handled by the application code, the default handler simply closes the corresponding window. This API was approved by Richard and I am surprised he finds it weird now.
>> 
>> Lubo
>>> It just feels like a bit of a side effect, rather than the actual intent of consume() (which is to prevent event propagation, not to pass on additional information such as the state of a veto command).
>>> 
> 
> I think consuming the event is the most natural way to do this.  Preventing event propagation to the code that would otherwise act on it is exactly what we want.  There is no need to introduce a new concept here.

That make sense. I think I remember the argument now, which was basically the question of what do we do when something needs to be consumed -- do we continue propagating and have a flag and ask each listener to check the flag, or do we just stop propagation. If we wanted an API that said "cancelClose", then it could call consume() behind the scenes, but just provide a somewhat more obvious API that you are to invoke.