[REVIEW REQUEST] RT-24088 Add API to JavaFX to allow vetoing the closing of a Tab in a TabPane
Lubomir Nerad
lubomir.nerad at oracle.com
Fri Dec 14 02:51:51 PST 2012
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).
>
> An option is to add a new property to TabEvent that makes it clearer
> to developers that they are telling the tab not to be closed. Richard
> suggested having a 'vetoOnClose' property on TabEvent, and to use this
> rather than consume.
>
> Regarding the location from where the event is fired, the primary
> requirement is to ensure that this event is fired in all cases when a
> Tab is closed. If that requirement is met I don't think there is a
> massive concern about where the event itself fires from.
>
> Other than that the patch looks fine.
>
> -- Jonathan
>
> On 7/12/2012 10:51 a.m., Tom Schindl wrote:
>> Hi,
>>
>> I've uploaded a revised patch which now works using the event system
>> sending out an TabEvent of type "TAB_CLOSE_REQUEST".
>>
>> So the revised API on Tab would now be:
>> + ObjectProperty<EventHandler<TabEvent>> onCloseRequestProperty()
>> + EventHandler<TabEvent> getOnCloseRequest()
>> + setOnCloseRequests(EventHandler<TabEvent> value)
>>
>> and vetoing a close would look like this:
>>
>> Tab tab1 = new Tab("Hello");
>> tab1.setOnCloseRequests(new EventHandler<TabEvent>() {
>>
>> @Override
>> public void handle(TabEvent event) {
>> event.consume();
>> }
>> });
>>
>> Thanks for the input Werner, Steven and Richard.
>>
>> One thing I was not sure is who is supposed to deliver an event. I used
>> the TabPaneBehavior maybe the Tab itself should send out this event?
>>
>> Tom
>>
>> Am 06.12.12 17:04, schrieb Richard Bair:
>>> Indeed, this sounds like the same idea Werner had. Good find.
>>>
>>> On Dec 6, 2012, at 7:54 AM, steve.x.northover at oracle.com wrote:
>>>
>>>> Stage has the onCloseRequest property. Might make sense to have a
>>>> similar API in Tab.
>>>>
>>>> Steve
>>>>
>>>> On 06/12/2012 8:33 AM, Tom Schindl wrote:
>>>>> Hi,
>>>>>
>>>>> This is an interesting idea. I'm not that deep in the FX-API to
>>>>> understand if this the advised way in other areas so. I let
>>>>> Richard and
>>>>> Jonathan comment on it.
>>>>>
>>>>> Tom
>>>>>
>>>>> Am 06.12.12 12:32, schrieb Werner Lehmann:
>>>>>> Would it also be possible to have a simple onClosing event and
>>>>>> require a
>>>>>> handler to Event.consume() it? Maybe slightly less obvious than an
>>>>>> explicit "*veto*" but more flexible/resuable, too (as a general
>>>>>> pattern
>>>>>> in similar situations).
>>>>>>
>>>>>> Werner
>>>>>>
>>>>>> On 06.12.2012 07:08, Tom Eugelink wrote:
>>>>>>> Just a remark to see if we can make this more reusable; would it be
>>>>>>> an idea to actually veto the close action? Like veto the removal
>>>>>>> of a
>>>>>>> tab from a list? In that way veto-ing would be available to other
>>>>>>> usages of such lists as well, a uniform API.
>>>>>>>
>>>>>>> Tom
>>
>
More information about the openjfx-dev
mailing list