Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / December 2006

Tip: Looking for answers? Try searching our database.

File loader architecture

Thread view: 
Philipp - 05 Dec 2006 17:44 GMT
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 - 05 Dec 2006 19:08 GMT
> 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 - 06 Dec 2006 11:41 GMT
> Hello,
> I would like some input on an architecture problem (or maybe some best
[quoted text clipped - 34 lines]
> 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


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.