2

I'm doing a favor for an engineer friend by making him a program that helps him with the scheduling of his factory's production. Each type of product is broken down to a set of steps (they share a lot of them, but there are a few differences).

The programming issue:

Each time a new production process is registered I display a number of checkboxes representing the before mentioned steps. He can choose which steps he needs added for this particular product. If he checks a checkbox, two (or more) textfields appear where he can add additional information (starting date, duration, comments, etc...). My problem is that this is a lot of individual components and I am unsure how to handle them. Since I will need to have access to all of them at some point (the checkboxes to see if that step is needed and all the textfields for the data) I was thinking of having them all as fields, but that doesn't feel right...

Another approach could be to make a container class that groups the textfields together with the checkbox. Something like this:

ArrayList<MyComponentGroup> group;
for (MyComponentGroup cg : group) {
    if (cg.getCheckBox().isSelected()) {
        //access and read the data from all the textfields in this object
    }
}

What is the Java programming convention or the most commonly used method to handle this situation?

halfer
  • 19,824
  • 17
  • 99
  • 186
István Kohn
  • 135
  • 8
  • A JTable might allow for a decent solution actually. – Hovercraft Full Of Eels Jun 06 '13 at 20:24
  • The reason why I'm not going with JTable is because some steps require more or different input fields than others, and that would lead to columns that are only used by a single row (if selected at all) – István Kohn Jun 06 '13 at 20:38
  • 1
    Then it sounds like you'll need to create a component based on a JPanel that can be initialized with variable fields, with a JCheckBox on the left (BorderLayout.WEST) that controls visibility and state, which can be placed in a container JPanel that is held by a JScrollPane. – Hovercraft Full Of Eels Jun 06 '13 at 20:45

2 Answers2

3

Here's what I would do when dealing with tons of components and similar requirements:

  • I would model the relationship between options (available through checkbox selections) and the related data to fill (requirements). This model may already be available for you.
  • I would attempt to use PropertyEditor instances and map them to model elements.
  • When the time comes to save or use the data filled by the user, I would just walk the model represented on the screen, grab the associated editors and deal with the value of those editors.

I think that the approach that I described above will give you less work and potentially and it will bring more flexibility for your friend.

You'd only pay the initial cost of getting the components relationships/dependencies in a nice model as well as registering the relevant PropertyEditors for visual editing.

halfer
  • 19,824
  • 17
  • 99
  • 186
rimero
  • 2,383
  • 1
  • 14
  • 8
2

One approach is to consistently give each JComponent a unique name. Use something hierarchical to fit the complex process, like "Whites.Rinsecycle.enableCB". For completeness, store this String as a clientProperty in the JComponent. Then you can use that as a key in a large Map to access all the components.

Maybe not the most "elegant" (I'd tend to go with a hierarchy of JPanels with relevant fields) but for a slightly quick and dirty, moderate sized project this is reasonable.

user949300
  • 15,364
  • 7
  • 35
  • 66
  • I've accepted this answer, but Hovercraft's idea seems equally appealing, I'll be using one of these. Rimeros idea is interesting aswell, but with what I already have the before mentioned 2 seem easier to implement. Anyway, thanks for the ideas, everyone. – István Kohn Jun 06 '13 at 23:31