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 

        // Type Confirm: Boolean response
        DialogBox dbox = new DialogBox("Sanity Check"); 
        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"); 

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!

Reply via email to