[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Configuration files
Peter MR wrote: >The installation involved re-compilation because the program holds a list >of SAXDriver classes internally (6 so far). I'd really like to do this sort >of thing (including menu re-generation) driven by declarative files from >outside the program (so recompilation isn't necessary). My question is: >*What is the best way of associating files with Java applications in a >platform independent manner?* > This is a real problem, I've talked to colleagues who know java far better than I do and they haven't come up with a good solution. In SAXON I have a class called ParserManager which allows the user to register their favourite parser from the command line, and allows the application to instantiate the user's preferred parser. What it does is to create a java Properties object containing the parser name and save this to a file called "SAXON.INI" in the directory established by the value of the system property "user.home". This largely works OK, though it suffers from the fact that the location of "user.home" depends on which java VM you are using. What I'd really like to do is to ask the system for the name of the directory that my application was loaded from. As far as I can see it is possible, but deprecated, to read environment variables from java. An environment variable to define the parser (or the configuration file in which the parser is named) would be the obvious and traditional solution. It would be possible, I think, for the user to integrate a SAX application with a SAX parser using some kind of javabeans mechanism, but only if he has development tools on his machine. I'm not expert with javabeans, perhaps someone can correct me on this. Equally, there are CORBA mechanisms but this seems over the top. There are actually two challenges. One is the simple one of the application picking up the name of a parser from a "well-known place". The other is to implement some kind of "parser manager" akin to the ODBC Driver Manager that provides a registry of which parsers are installed on the machine and enables them to be selected by a short name, etc. I suggest, unless anyone can come up with anything better, that in SAX 2 we provide a ParserManager class which maintains a configuration file akin to the one in SAXON; this class should have interfaces that: * allow a parser to register itself, supplying both the java class name and a "brand name" which the user will recognise * allow the user to see which parsers are installed and select a preferred one * allow the application to instantiate the user's preferred parser, or to offer a menu of choices based on the "brand names" of the parsers that have been registered Of course there is the dreadful prospect that more than one implementation of ParserManager exists, in which case we need to allow the user/application to choose which one to use. If I go on much longer I shall reinvent the CORBA trader. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|