Ideas on Generic Parser
Firstly, i never created any parser. Now, whats my idea is, i want to create a parser that takes the configuration file content and modify its params at run time. Say for example a simple configuration file may be:
//some comments wherever required in file
host: IP
Port: 80
.....
.....
etc..
The configuration file content format may be different (varies file to file). I mean, like, their commenting style format, any tabs or spaces in between etc...
I am still in learning stage. I need your valuable ideas as to how and where to start. Are there any design pattern which i can refer and start with.
Hope i am clear with my problem.
regards
[742 byte] By [
@a] at [2007-10-3 3:11:23]
Just use the Properties class load method http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.htmlTed.
If the format is going to change from file to file, then essentially you're going to have to write multiple parsers, one per format, and then have some kind of switch that chooses which parser to use for a given file. Perhaps the switch will look at the first couple lines, figure out the format, and then send the file to the correct parser.
If worse comes to worst you can have every parser attempt a parse on the same file, and then keep the results of the one that didn't fail.
Looks to me like you should be using XML. You can use the built in XML functionality to read the XML into a DOM document The DOM document can then be updated from within your Java program before being written out again.
If the sematics are simple then it's not too hard. You could do a fair bit with regular expressions, for exaple. Allow a RE to be specified to remove comments, then another to split the line into key and value.
Thanks alot for everyone in this thread for your valuable suggestions. I will try with all your suggestions.
@a at 2007-7-14 21:02:14 >
> If the sematics are simple then it's not too hard.
> You could do a fair bit with regular expressions, for
> exaple. Allow a RE to be specified to remove
> comments, then another to split the line into key and
> value.
How RE can be used to remove comments?
@a at 2007-7-14 21:02:14 >
I imagine that you can do it by writing a regex that matches a comment (both the comment characters and the content of the comment) and then use Matcher.replaceAll, passing in an empty string. Try that.
If you're doing //-type comments (where the comment starts at the start-comment signifier and extends to the end of the line) plain old String.indexOf and String.substring might work as well.
BufferedReader br = new BufferedReader(new FileReader(confFile));
while ((line = br.readLine()) != null) {
if (line.matches("^#"))
continue;
// wasn't a comment
}
As simple as it is, "^#" is still a RE.
Brian
I'd make that RE "^\\s*#" for convenience.kind regards,Jos
JosAHa at 2007-7-14 21:02:14 >
but what if it's adoSomething(); /* comment like this? */
Or actually a better example:
while(someCondition) /* comment */ {
Message was edited by:
paulcw
Well, the problem to be solved was how to parse a configuration file that contains comments. I don't see that a configuration file is likely to be so complicated as to allow commenting as you have described. If it is, then maybe it's best to use an XML configuration file and use the commenting features there.
Really there's 3 choices:
1) Use a properties file. This allows you to specify simple key<->value configuration options, as well as key<->list-of-values options. It also supports a basic commenting style where a line that begins with '#' is considered a comment.
2) Use your own configuration file. You'll have to write your own parser (obviously) and then you can define your own commenting style. The line-beginning-with '#' commenting style is by far the easiest to handle. The only reason I would even consider this is if it's somehow simpler than option 1) above. (Somebody has an example of why this option is appropriate?)
3) Use an XML configuration file. You can use a standard XML parser and use standard XML comments. This is typically used for complex configuration files that are broken into multiple sections and/or shared between multiple applications. I find that people overuse this option. An XML file is 1) time-consuming to write 2) resource-intensive to process and 3) more difficult to extract simple key<->value configurations than either of the above options.
As interesting as it is to think about the difficulty of parsing these types of comments, I don't think that it really applies to this problem.
Brian
He said the formatting is going to change between files though. So who knows what the format will be.
