This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Very quick question... Is the format of the suncertify.properties file restricted in any way? I'm asking because I'd rather work with preferences than properties and so, I want to populate the file with XML.
Champion, you have to store the properties that your program require in a file called suncertify.properties that must be saved in the folder in which the application is running. This is a must. And you may define the properties that your program will require, according to its needs.
You have to store the configuration settings in suncertify.properties and that is a must. I don't think there is a must on how the data should be stored, so xml, plain text, binary,... everything is allowed.
But of course why making it hard for yourself, if there is a Java class which is made perfectly for the job (java.util.Properties): loading, saving, retrieving properties is as simple as possible with this class.
Yes, I understand the requirements (storing properties the app requires in the file, in the current directory, etc) and that there is a Properties class. The reason why I want to use preferences is because it provides a clean way to separate my client properties from the server ones (by specifying the parent node). For example, I can write out changed client properties without having to code the logic to skip properties that only apply to the server (because I have them in separate nodes)... Does this help explain my question more?
My original question is really will I be penalized (failed) if the contents are XML?
With this code I set 2 properties and save it to file:
Like I previously said: I think you are making it more difficult than it should be. But there is no requirement about how the properties (format) are saved in the suncertify.properties, so if you prefer XML just use it.
Joined: Sep 21, 2009
Hey Roel... you're still not understanding me... I know how to set properties... the problem with your example is that I have properties specific to the server and another set specific to the client. Because they are both in one file (per the requirements), if I only want to load and/or write those specific to the client, it requires additional code. There isn't (at least I haven't found it) a way of specifying the "group".... So, when I write client prop changes back to the file, I either have to deal with the server ones or lose them... and the reverse is true when working with the server props...
Hopefully this example will help
- client properties
-- show splash screen
-- database location (server remote or local)
-- database file (only valid when server is local)
- server properties
-- database file