File: parser_devel_guide.html

package info (click to toggle)
afterstep 2.2.12-18.1
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 33,184 kB
  • sloc: ansic: 201,695; sh: 5,894; xml: 3,721; makefile: 2,094; perl: 1,558; cpp: 811
file content (104 lines) | stat: -rw-r--r-- 4,636 bytes parent folder | download | duplicates (9)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
<HTML>
<HEAD><TITLE>AfterStep unifyed parsing code Developer's Guide.</TITLE></HEAD>
<BODY>
<H1><A href="http://www.afterstep.org">AfterStep</A> unifyed parsing code Developer's Guide.</H1>
<font size="2" color="blue">Copyright Sasha Vasko <A href="mailto:sasha at aftercode.net">< sasha at aftercode.net ></A></font>
<p>
<H2>Table of Contents.</H2>
<OL>
<LI><A href="#overview">Overview.</A>
<LI><A href="#structs">Data structures.</A>
<LI><A href="#functions">Functions.</A>
<LI><A href="#files">Files and Directories.</A>
<LI><A href="#confdef">Creating Config definition.</A>
<LI><A href="#confdata">Defining custom config data structure.</A>
<LI><A href="#exceptions">Writing exception handling function.</A>
<LI><A href="#reader">Writing config reader.</A>
<LI><A href="#memcleanup">Memory cleanup notes.</A>
<LI><A href="#linking">Linking application to the Config Reader Code.</A>
</OL>

<p><hr><p>

<OL>
<H2><LI><A name="overview"></A>Overview.</H2>
The parsing code <A href="../../lib/parser.c">parser.c</A> is a part of
main AfterStep library - libafterstep. It allows for convinient parsing
of the plain text configuration files, or configuration information from plain text buffer.
<p>
Configuration information consists of two kinds of options -
<OL>
<LI>Executable name specific option.<br>This options must be prepended with '*'
character, and specific executable name - like *PagerMyOption.
<LI>Non executable name specific options. Must not begin with '*' character.
</OL>
<p>
Configuration options are defined as a <b>syntax definition</b>.<br>
<B>Syntax definition</B> includes:
<OL>
<LI><I>terminator</i> - character terminating single option;
<LI><I>config_terminator</I> - character terminating entire configuration data;
<LI><I>terms</I> - an array of term definitions.<br>
<B>Term definition</B> includes :
<OL>
<LI>term's <I>flags</I> - defining specific ways of treating that option;
<LI><I>keyword</I> - identifying this option in configuration file;
<LI><I>type</I> - definig option's data postprocessing method
<LI>unique <I>ID</I> - identifying this option to the application.
</OL>
</OL>
Prior to performing parsing - simple hash table is built from term
definition's, for faster processing.
<p>
Parsing is done in two steps :
<OL>
<LI>Building <B>FreeStorage</B> for configuration data:<br>
This step is done by <I>ParseConfig()</I> function.<br>
It creates linked list of <B>FreeStorage elements</B>, representing single configuration
option each.<br>
<B>FreeStorage elements</B> consist of:
<OL>
<LI><I>term</I> - pointer to the <B>Term definition</B> identifying option;
<LI><I>argc</I> - number of space separated data elements ( TF_DONT_SPLIT term's flag can be used
to prevent splitting of the option's data into elements - in this case argc will be equal 1)
<LI><I>argv</I> - array of pointers to space separated data elements, that will be terminated with '\0' each.
</OL>
In case option needs some special processing and possibly need not to be included into FreeStorage -
custom exception function can be supplied. ( like for processing ballons options in the module configuration.)
<LI>Processing of <B>FreeStorage</B> into the application usable format:<br>
In this step linked list is processed by custom made, application specific function,
in order to convert it into the application readable data structure.<br>
This data structure can be used later on for communication between
Centralized Configuration module and the rest of the AfterStep,
and between ascp and the rest of the AfterStep. Just my thoughts, anyway :).
</OL>
<p>
The way it is implemented now - all app-specific config reading code for the step 2
gothered together in the <A href="../../src/Config">src/Config</A> dir. It is all
organized in the lib, but modules should link to specific object files to reduce
executable's size.<br>
Header file for that stuff is : <A href="../../include/confdefs.h">confdefs.h</A><p>


<p><hr><p>
<H2><LI><A name="structs"></A>Data structures.</H2>
<p><hr><p>
<H2><LI><A name="functions"></A>Functions.</H2>
<p><hr><p>
<H2><LI><A name="files"></A>Files and Directories.</H2>
<p><hr><p>
<H2><LI><A name="confdef"></A>Creating Config definition.</H2>
<p><hr><p>
<H2><LI><A name="confdata"></A>Defining custom config data structure.</H2>
<p><hr><p>
<H2><LI><A name="exceptions"></A>Writing exception handling function.</H2>
<p><hr><p>
<H2><LI><A name="reader"></A>Writing config reader.</H2>
<p><hr><p>
<H2><LI><A name="memcleanup"></A>Memory cleanup notes.</H2>
<p><hr><p>
<H2><LI><A name="linking"></A>Linking application to the Config Reader Code.</H2>
<p><hr><p>
</OL>
</BODY>
</HTML>