File loader architecture

[Philipp]

Hello,
I would like some input on an architecture problem (or maybe some best
practices).

I have some preset settings for a tool in my application which are
stored in XML files.
I would like to show a JDialog to the user where he can choose one of
the presets from a list and when he presses OK this setting is used
thereafter .

I would like to know how to make a good architecture for this.

I now have the following classes.

SettingChooser extends JDialog (is the actual window where the user
chooses from some list)

Setting (is the preset data when it is loaded. This is the form that is
used by the application later on).

The list in the dialog needs to be populated before showing, so all
possible settings need to be loaded first.
How would you brake up the different things that need to be done, namely:
- scan the directory for settings files
- for each, load the XML, parse it and create new Setting objects
- display the loaded setting in the list

All this could be done in SettingChooser. But I think that's ugly (?)
because it's a visual class.
Should there be a SettingLoader class which does all the above and
returns an array of Setting to the dialog?
Or should every Setting know how to populate itself given a filename in
the constructor. (also thinking about *saving* new settings later,
should every Setting know how to write itself to a filesystem? or should
this be delegated to some external class).


Thanks for your answers.
Phil

 

[Wesley Hall]

All this could be done in SettingChooser. But I think that's ugly (?)
because it's a visual class.

I absolutely agree.

Should there be a SettingLoader class which does all the above and
returns an array of Setting to the dialog?

Yes, this would be my preferred option. If the class loads data from XML
then consider calling it XMLSettingLoader. This leaves the door open for
PropertiesSettingLoader and JDBCSettingLoader. If there is shared
behaviour between all the different loaders consider creating the
SettingLoader as an abstract superclass of all loaders.

Or should every Setting know how to populate itself given a filename in
the constructor.

I would avoid this. You will end up coupling your Setting class to the
XML format. This wont be very flexible. Try to keep the Setting class as
a simple Java bean, completely independent of the storage mechanism.

(also thinking about *saving* new settings later,

should every Setting know how to write itself to a filesystem? or should
this be delegated to some external class).

External class again. Perhaps 'SettingStorer'. Keeping the Loader and
Storer seperate will open the possibility of using a SOAPSettingLoader
to load possible settings from a webservice and JDBCSettingStorer to
store the selected settings in a local database.... for example

 

[Ed Kirwan]

Hello,
I would like some input on an architecture problem (or maybe some best
practices).

I have some preset settings for a tool in my application which are
stored in XML files.
I would like to show a JDialog to the user where he can choose one of
the presets from a list and when he presses OK this setting is used
thereafter .

I would like to know how to make a good architecture for this.

I now have the following classes.

SettingChooser extends JDialog (is the actual window where the user
chooses from some list)

Setting (is the preset data when it is loaded. This is the form that is
used by the application later on).

The list in the dialog needs to be populated before showing, so all
possible settings need to be loaded first.
How would you brake up the different things that need to be done, namely:
- scan the directory for settings files
- for each, load the XML, parse it and create new Setting objects
- display the loaded setting in the list

All this could be done in SettingChooser. But I think that's ugly (?)
because it's a visual class.
Should there be a SettingLoader class which does all the above and
returns an array of Setting to the dialog?
Or should every Setting know how to populate itself given a filename in
the constructor. (also thinking about *saving* new settings later,
should every Setting know how to write itself to a filesystem? or should
this be delegated to some external class).


Thanks for your answers.
Phil

Fully agree with Wesley's reply.

Just one more point: design your SettingChooser so that it requires no
updates for each new setting required. See:
http://www.edmundkirwan.com/servlet/fractal/cs1/frac-cs110.html