Hello, after a long silence in this website!
After my Erasmus experience in Warsaw (which was greatly great) I returned back to my school and studies, and as soon as I came back, I was supposed to do my Junior Project, which is a generic settings file editor.
The idea behind this editor is as follows: There are various kinds of settings files in this universe. Any program may have one kind of it’s own. A systems administrator, a curious child, or anyone who somehow has to do something with these files, has to open the file in a conventional text editor like notepad or vi, and understand its contents, and do what he/she needs to do. This is the normal way to edit these files. But this normal way, has some drawbacks:
- There are many, many formats in which the contents of these files organized. So you may try to edit an INI, XML or conf based configuration file. In order to do so, you have to know the corresponding syntax. If you violate the syntax rules while editing, your program may not work properly, or may not work at all.
- Even if you are acquaintant with the syntax of the file, still you may erase a “<” sign by mistake, causing your program probably to crash again.
In this project, I tried to come up with a solution to the both of these problems, and I did some research. I’ve realized that I have to make an editor, which will be “generic”, that is, regardless of the type of the configuration file, my editor should be able to view and edit it. This way, I could get rid of the “variation of syntax” problem. One user may just edit the file using my program, and he/she doesn’t need to know the real syntax of that file.
So how do you design a program that will edit any (or most of) type of configuration file that can be found? The solution was simple: Most popular configuration file formats (i.e INI, XML and conf) are or could be considered as based on a tree structure. So that a program which lets the user edit the file in a tree format, might have been useful.
Another point to consider is the flexibility of the program. How to design the program that it will require minimum changes in the source code to add the ability to view/edit a new file format? Here I used some extra help from OOP, and designed well-defined interfaces for abstraction and wrote a code in compliance with Open-Closed Principle. So that when adding new functionality, one just have to define the classes which override the interfaces defined previously, and that’s all.
The result of my work is below, a program based on the Model/View/Controller pattern which has no idea on actually what data structures are present, some interfaces to fill the gap between actual data files and the Model/View/Controller based program, and that’s all.
Interface Classes:
I thought configuration files consisting of (key, value) pairs which are put together in a hierarchical way, just like XML. For example, an INI file consists of sections which in turn consists of key=value pairs. In the INI example, the document might be considered as root node of the tree, each section is a child of the root and every pair is a child of it’s owner section. An XML file is directly an XML tree so there is no need to comment furhter on it.
For the reason I explained in the above paragraph, I’ve designed these interfaces to be used by the GUI (or editor program) to manipulate an abstract settings file:
- SettingsNode (a node in that tree)
- SettingsFile (represents the file that is opened, and provides the rood node (a SettingsNode object) of it.)
A SettingsNode has a name, an AttributeMap(will be explained later) and a value.
Also some additional classes were defined, i.e: AttributeMap to manipulate the attributes of a node. An attribute may refer to an attribute of an XML element, for example. Another additional class was StackTrace which’s duty was to keep the track of the function call stack. The class StackTrace writes down in a “trace.txt” file whenever a function is entered in it’s constructor’s code, and whenever a function is exited in it’s destructor’s code. It also handles the indentation, any function call inside another, will be written down with a tab of more indentation than it’s callee. Of course, whenever a function call wanted to be traced, a StackTrace object is created in the beginning of the function, and the rest is done automatically. StackTrace function also can write down some extra debugging information on the “trace.txt” file, by the help of its member function “addExtraInfo()“
After defining the interfaces, it was time to design the program (GUI) which opens a file, manipulates it over these interfaces, then saves it to disk when required. I coded this program in C++ with Qt Framework. Using Qt’s MVC, it was very easy to seperate actual representation of data from the way it’s accessed, and within the program it was impossible to tell if the file being edited corresponds to a certain file format.
Interfaces were defined, GUI application was designed, so it was time to implement some real file parsers. In this project, I coded parser for two kinds of files, for XML and for INI. Actually, for XML I used Qt’s DOM parser, and I wrote some wrapper classes to use Qt DOM parser within the project. Similarly, with INI I used an INI parser which I’ve found on the Internet, and I wrote some wrapper classes for it as well. The INI parser which I used can be seen here.
Additionally, the GUI defers the syntax check to parser wrapper modules, so that any attempt to break the rules of the syntax is not allowed by corresponding parser. In example, “=” sign in a key name or value is not allowed in INI files, but it is allowed in XML. GUI does not take any action about this, parser modules do the work.
After all, I do not have a mature program as a commercial product or something, but this is because I do not have more time to spend on it, since I have to focus on my Senior Project now. I am providing some screenshots and the source code here, source code is written entirely in Standard C++ with Qt, so on any platform on which Qt is supported, you may easily compile, link and execute the program.
Thank you, have a nice day!
Hayri Uğur KOLTUK
Screenshots:
Editing an XML
As seen above, editing an XML file is completely without knowing anything about the XML file format. And as seen below, editing an INI file is done in the same way, regardless of the INI file format. User do not have to know anything about these formats, and user is protected from doing some syntax errors by the parser modules. In example, an attempt to change the name of timer to timer= in the file below, is prohibited by the parser module of INI. However, GUI, just like the user, doesn’t know anything about syntax either.
Editing an INI file.
