I agree that the four showXXX() methods are a slight complexity, but I think
they are simpler than the alternative. They quickly communicate the implied
"Type" of the DialogBox and response:
// Type Message: No response
DialogBox dbox = new DialogBox("FYI"); dbox.setMessage("Just
saying...");
dbox.showMessageDialog(focusedNode);
// Type Confirm: Boolean response
DialogBox dbox = new DialogBox("Sanity Check");
dbox.setMessage("Really???");
boolean response = dbox.showConfirmDialog(focusedNode);
// Type Option: Integer response
DialogBox dbox = new DialogBox("Which One"); dbox.setMessage("Select
One"); dbox.setOptions(myOptions);
int response = dbox.showOptionDialog(focusedNode, defaultOption);
// Type Input: String response
DialogBox dbox = new DialogBox("Tell Me"); dbox.setMessage("Tell me
what you want:");
String response = xbox.showOptionDialog(focusedNode, default);
The only alternative I see would be to explicitly set a DialogBox type and
return a DialogBoxResponse, which could embody any of the above. That seems
cumbersome to me. I also think it would be over-engineering to try to support
any kind of response (say like a Color or a Font). In these cases, I think it's
better to have your ColorChooserPane or FontChooserPane act as content:
// Type ColorChooser: Boolean response plus Color
DialogBox dbox = new DialogBox("Please Pick a Color");
dbox.setContent(myColorChooserPane);
if(dbox.showConfirmPanel(focusedNode))
setColor(myColorChooserPane.getSelectedColor());
In fact, your ColorChooserPane could have a showColorDialog() method that would
just be the above code.
Jeff Martin
On Jun 20, 2014, at 10:15 AM, Stephen F Northover
<steve.x.northo...@oracle.com> wrote:
> This essentially matches my current thinking, however, I would have DialogBox
> as an abstract superclass of Alert. Further, I would not have many different
> types of show() methods.
>
> Want to take the discussion further in the JIRA? That way, is will track
> everyone's thinking on the various issues. The downside is that JIRA does
> not provide threaded conversations and it can be hard to follow.
>
> Steve
>
> On 2014-06-20, 9:41 AM, Jeff Martin wrote:
>> That is a great post. I think the big problem with dialogs in Swing was the
>> permutations problem. There were four basic types of dialogs (Message,
>> Confirm, Option, Input) with six different parameters (Title, Message, Icon,
>> Content, MessageType, Options) - so JOptionPane ended up with a sea of
>> static methods that were confusing to navigate.
>>
>> I don't think you could go wrong with a simple DialogBox class like this (I
>> love simple):
>>
>> // Constructor
>> public DialogBox(String aTitle);
>>
>> // Options
>> public String getTitle();
>> public void setTitle(String aTitle);
>> public String getMessage();
>> public void setMessage(String aMessage);
>> public MessageType getMessageType();
>> public void setMessageType(MessageType aMessageType);
>> public Node getContent();
>> public void setContent(Node aNode);
>> public Node getGraphic();
>> public void setGraphic(Node aNode);
>> public String[] getOptions();
>> public void setOptions(String ... theOptions);
>>
>> // Convenience methods to set Message + MessageType
>> public void setErrorMessage(String aMessage);
>> public void setWarningMessage(String aMessage);
>> public void setQuestionMessage(String aMessage);
>>
>> // Show methods
>> public void showMessageDialog(T aComp);
>> public boolean showConfirmDialog(T aComp);
>> public int showOptionDialog(T aComp, String aDefault);
>> public String showInputDialog(T aComp, String aDefault);
>>
>> // Programatic dismissal
>> public void confirm();
>> public void cancel();
>>
>> Then most common invocations would look something like this:
>>
>> // Get user confirmation
>> DialogBox dbox = new DialogBox("Sanity Check");
>> dbox.setWarningMessage("Are you sure you want to do this? It could kill
>> you.");
>> if(!dbox.showConfirmationDialog(focusedNode)) return;
>>
>> Using instance methods instead of static methods gives opportunity to
>> subclass and override various methods. And notice the Content attribute -
>> for the standard case when no Content is provided, it is built
>> programmatically based on the parameters (essentially just the message and
>> either an Option combo, an input textfield or nothing).
>>
>> I've been using this in my JavaFX app for a while and it is working great
>> and makes porting from Swing easy. I even built it on a convenient
>> FormBuilder class that makes building a simple stack of form controls easy,
>> and can also be used for advanced DialogBoxes.
>>
>> Jeff Martin
>> 214.513.1636
>>
>>
>> On Jun 20, 2014, at 7:05 AM, Stephen F Northover
>> <steve.x.northo...@oracle.com> wrote:
>>
>>> Great post Jonathan. The summary is that whatever direction we take, we'll
>>> have a plan for the future. So if we run out of time and provide only a
>>> very scaled back API, we'll have prototyped how it can evolve to handle
>>> more complex cases.
>>>
>>> Steve
>>>
>>> On 2014-06-20, 12:37 AM, Jonathan Giles wrote:
>>>> Hi all,
>>>>
>>>> Dialogs are something everyone wants, and also something most people seem
>>>> to have an opinion on! JavaFX 8u40 will have dialogs, but what form they
>>>> take (API-wise) is not yet defined. I've posted a relatively long
>>>> discussion on this over at FX Experience [1] and your feedback is highly
>>>> welcome. As I note in the blog post, the Jira issue for this feature is
>>>> RT-12643. If you have any thoughts, please do post them there (rather than
>>>> spam the many good people subscribed to openjfx-dev).
>>>>
>>>> [1] http://fxexperience.com/2014/06/bringing-dialogs-to-javafx/
>>>>
>>>> Thanks!
>>>>
>
