Re: Resource confusion
On Tue, 31 Jan 2012 06:32:38 -0400, Arved Sandstrom wrote:
On 12-01-30 10:45 PM, Martin Gregorie wrote:
On Mon, 30 Jan 2012 13:33:30 -0800, Roedy Green wrote:
On Sat, 28 Jan 2012 17:47:48 +0000 (UTC), Novice <novice@example..com>
wrote, quoted or indirectly quoted someone who said :
I'm having trouble figuring out the best way of obtaining existing
files for my program to use.
I would put the read-only config files in a resource in a jar. This
means they can't get lost and they work even if the user is not
capable of configuring his own files. They are also compact. They get
updated automatically when you update the program.
You problem then becomes, where to put the user's files. JNLP lets
you allocate some space with a hideous name, not really suitable for
the user to insert things except via your game. If he creates them
with a text editor you might import them into that space or store the
filenames (not files) in your own space so he can pick them off a menu
by unqualified name, and you then go fetch them from the original
locations as needed.
Same here: I'd put the defaults in the jar and, allow the user to put
overriding files in a master location and a one local to the user: if
it was a UNIX type system the master location would be /usr/local/etc
and the local location would be the hidden directory ~/.myapp and the
program would use a search something like this;
List<String> config = new List<String>();
config.add("~/.myapp/config.txt");
config.add("/usr/local/etc/config.txt");
boolean found = false;
for (String s : config)
{
File cf = new File(s);
if (cf.exists())
{
found = true;
// use the configuration in cf
}
}
if (!found)
// use the default configuration held as a resource in the jar file
which lets the user's configuration take preference over the site
configuration in /usr/local/etc, which in turn takes precedence over
the jar file resource.
NOTE: this assumes that each configuration is complete.
Another way to do it is to read all three config files in the *reverse*
order (from jar file, then /usr/local/etc and finally from ~/.myapp)
with items read from an earlier file being overwritten by matching
items from a later file. This approach means that the config in the jar
file must give a default value for every item, but the site and user
configurations only need to provide values for items they want to
customise.
This is the way I would do things too, in general, for a configuration
file problem. One wants the average user to do as little as possible -
preferably nothing - with a file system, because a large percentage of
users don't get file systems.
I'll point out that the OP has a situation, as he/she has described it,
where there are *several/many* input files that can configure _a_ game,
and one of them is selected to configure a given game. This is not
atypical for games with numerous scenarios. Although on the UI level it
would certainly be desirable to present the user with a dropdown of
selections, rather than a file chooser, the OP's problem seems to be one
of reading *data* files, not one of reading a handful of true
configuration files. And his actual questions start with the details of
how best to _read_ a file, as I understand it.
Point, but the logic is still the same regardless of whether the file is
a configuration or a (set of) data files, since he seems to be talking
about a two level hierarchy of files where a local copy, if there is one,
takes priority over one in the jar file.
You can see a situation in which the first run can only find the copy in
the jar file and, in the course of the run, creates a modified local
version which is what it should use for all subsequent runs. In that case
I think my first suggestion would be the appropriate one and, again,
would work regardless of whether the file contains a few items
(configuration) or a lot (data).
One thing the OP may have missed is that, if the jarfile is intended to
be handed to a site admin who then distributes it to a set of users,
there may be a good case for providing a sysadmin tool that can extract
the file(s) from the jar file, apply site-specific, site-wide
customisations to them and put the result back in the jar file. Something
like this can make the package a lot easier to install.
Perhaps the most obvious example of this being a good idea would be if
its a client-server app: the site-wide customisation tool would let the
sysadmin put the site's server hostname etc. into the jar file before
distributing it to the user community. The effect is that the app should
'just run' on installation, making the users happy and saving the helldesk
from an endless stream of "why can't X find the server?" queries.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |