Java - best practice for getting values from complex dialogs

arooaroo · 2005-03-16 20:47:20

Hi,

Java is a language I use quite a bit, but much of my work hasn't required GUIs. Now, I'm developing an app which will contain a number of custom-made dialogs (which will obviously extend JDialog). Take a typical Options dialog which typically stores many parameters for a given application.

Simple dialogs that ship with Java allow to 'get' a given value. As they assume that the dialog only consists of obtaining a single piece of data, think JFileChooser.

So, what is the best way to cope with a dialog that could potentially hold hundreds of parameters? It's surely unfeasible to implement getters for each field. I was thinking either creating a hashmap object to hold key-value pairs, and 'get' that from the dialog. Or, I could encapsulate that a little more by creating a new class that manages these values, ProgramOptions or such like. That can be passed around between the dialog and the main app.

I hope this makes sense

TIA

Dusty · 2005-03-16 21:03:13

Personally, I'd take your second option; create a new class to hold the objects (General rule of thumb in Java: creating new classes is a Good Thing (tm)). You could make this class Serializable or a JavaBean and then you would find it relatively simple to persist the data if you need to do so at a later time.

Another option would be to use the Java properties system to store system properties for the dialog. Then they can be accessed anywhere in the application without having a reference to the dialog itself. System.getProperty() and System.setProperty() can be used for this.

Dusty

arooaroo · 2005-03-16 21:44:23

Dusty wrote:

Personally, I'd take your second option; create a new class to hold the objects (General rule of thumb in Java: creating new classes is a Good Thing (tm)). You could make this class Serializable or a JavaBean and then you would find it relatively simple to persist the data if you need to do so at a later time.
Another option would be to use the Java properties system to store system properties for the dialog. Then they can be accessed anywhere in the application without having a reference to the dialog itself. System.getProperty() and System.setProperty() can be used for this.
Dusty

Seems fair enough. Thanks for reassuring me

phrakture · 2005-03-16 22:24:48

IANAJD (I Am Not A Java Developer), but I would do it as follows:
The FunkyDialog class would have accessors for the "return values" (no mutators)

That is (in c++):

FunkyDialog d;
bool ret = d.display(); //hang and wait for return
if(ret) // clicked "ok" not "cancel"
{
   std::cout << "Selected Letter : " << d.letter();
   std::cout << "Something Else : " << d.something_else();
}

but that's probably poor java design.
c++ design tends to be more towards stand-alone objects...

sudman1 · 2005-03-17 01:42:40

I doubt it's the most efficient method, but the way I've delt with things like this in the past is to set up the fields in either an Array or ArrayList, then use a for loop that gets the data and drops it into an Array/ArrayList which is then returned.

class MyDialog extends JDialog {
...
// Global variable
private ArrayList dialogFieldsArray= new ArrayList();
...
    private void initGUI() {
        ...
        for (int i=0 ; i <numRequiredFields ; i++) {
            dialogFieldsArray.add(new JTextField(10));
        }
        ...
    }
    ...
    private ArrayList getDialogData() {
        ArrayList rval = new ArrayList();
        for (int i=0 ; i < dialogFieldsArray.size() ; i++) {
            String tempString = ((JTextField) dialogFieldsArray.get(i)).getText();
            rval.add(tempString);
        }
        return rval;
    }
...

The only thing to remember with the above method is the castings involved, but you could implement your own subclasses of ArrayList that deal only with JTextFields and Strings seperately to get around that.

Dusty · 2005-03-17 01:45:07

sudman1 wrote:

The only thing to remember with the above method is the castings involved, but you could implement your own subclasses of ArrayList that deal only with JTextFields and Strings seperately to get around that.

Sounds like a prime case for generics to me.

Dusty

phrakture · 2005-03-17 02:13:38

Dusty wrote:

Sounds like a prime case for generics to me.

C++ has had "generics" since like 1995

Dusty · 2005-03-17 02:18:42

You mean templates, I assume... they're not the same as generics... much more powerful... meaning much more likely to hurt yourself, IMHO. But that's me being a Java coder and you being a C++ coder...

Dusty

arooaroo · 2005-03-17 08:45:56

sudman1 wrote:

I doubt it's the most efficient method, but the way I've delt with things like this in the past is to set up the fields in either an Array or ArrayList, then use a for loop that gets the data and drops it into an Array/ArrayList which is then returned.
class MyDialog extends JDialog {
...
// Global variable
private ArrayList dialogFieldsArray= new ArrayList();
...
    private void initGUI() {
        ...
        for (int i=0 ; i <numRequiredFields ; i++) {
            dialogFieldsArray.add(new JTextField(10));
        }
        ...
    }
    ...
    private ArrayList getDialogData() {
        ArrayList rval = new ArrayList();
        for (int i=0 ; i < dialogFieldsArray.size() ; i++) {
            String tempString = ((JTextField) dialogFieldsArray.get(i)).getText();
            rval.add(tempString);
        }
        return rval;
    }
...
The only thing to remember with the above method is the castings involved, but you could implement your own subclasses of ArrayList that deal only with JTextFields and Strings seperately to get around that.

I personally wouldn't go for this exact style, instead I'd opt for a Map collection instead. This because you need to know which field is at which exact index. Imagine you make a form that has the fields: forename, surname, date of birth. And so you know that forename is .get(0) of your ArrayList, etc.

But then, you decide to put a new field, saluation (Mr, Miss, etc) at the beginning. This now shifts all your olds fields along by one, and so you need to edit that code. Sure, no biggie with a handful of fields, but large dialogs could cause headaches.

Dusty · 2005-03-17 16:42:47

arooaroo wrote:

But then, you decide to put a new field, saluation (Mr, Miss, etc) at the beginning. This now shifts all your olds fields along by one, and so you need to edit that code. Sure, no biggie with a handful of fields, but large dialogs could cause headaches.

In the arraylist, using an ArrayList with index values, you would use static final int constants to access the indexes of the array so they could be changed if necessary. In the Map case, you would use static final String constants as the keys, to ensure compile-time type checks (no spelling errors).

Nowadays, I'd suggest using typesafe enums to perform either of these tasks.

Dusty

arooaroo · 2005-03-17 16:55:22

Dusty wrote:

In the arraylist, using an ArrayList with index values, you would use static final int constants to access the indexes of the array so they could be changed if necessary. In the Map case, you would use static final String constants as the keys, to ensure compile-time type checks (no spelling errors).

Ah, getcha.

phrakture · 2005-03-17 17:03:03

Dusty wrote:

Nowadays, I'd suggest using typesafe enums to perform either of these tasks.
Dusty

are java enums converted to ints when compiled, as C/C++ enums are?

phrakture · 2005-03-17 17:03:57

arooaroo wrote:

Dusty wrote:
In the arraylist, using an ArrayList with index values, you would use static final int constants to access the indexes of the array so they could be changed if necessary. In the Map case, you would use static final String constants as the keys, to ensure compile-time type checks (no spelling errors).
Ah, getcha.

In that case, I'd suggest using the int indexes, as it's much faster, unless the hashing algorithm the map collection uses is ungodly fast

Arch Linux

#1 2005-03-16 20:47:20

Java - best practice for getting values from complex dialogs

#2 2005-03-16 21:03:13

Re: Java - best practice for getting values from complex dialogs

#3 2005-03-16 21:44:23

Re: Java - best practice for getting values from complex dialogs

#4 2005-03-16 22:24:48

Re: Java - best practice for getting values from complex dialogs

#5 2005-03-17 01:42:40

Re: Java - best practice for getting values from complex dialogs

#6 2005-03-17 01:45:07

Re: Java - best practice for getting values from complex dialogs

#7 2005-03-17 02:13:38

Re: Java - best practice for getting values from complex dialogs

#8 2005-03-17 02:18:42

Re: Java - best practice for getting values from complex dialogs

#9 2005-03-17 08:45:56

Re: Java - best practice for getting values from complex dialogs

#10 2005-03-17 16:42:47

Re: Java - best practice for getting values from complex dialogs

#11 2005-03-17 16:55:22

Re: Java - best practice for getting values from complex dialogs

#12 2005-03-17 17:03:03

Re: Java - best practice for getting values from complex dialogs

#13 2005-03-17 17:03:57

Re: Java - best practice for getting values from complex dialogs

Board footer