Re: Resource confusion
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.
AHS
--
....wherever the people are well informed they can be trusted with their
own government...
-- Thomas Jefferson, 1789