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
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
|
0.07 Wed Jan 27 1999
- Speed improvements. Now faster than XML::XQL (DOM) for all cases
- Some minor bug fixes
- Fixes to Stream mode - see README - needs to patch XML::Parser version
2.19
====================================================================
*** WARNING *** WARNING *** WARNING *** WARNING ***
This module requires XML::Parser version 2.20, but that's not been released
yet. To get around this you need to make 2 patches to XML::Parser (1 of them
is non-essential). First, the non-essential bug fix:
In XML::Parser, the Stream style has a function doText which looks like:
sub doText {
...
if ($_) {
...
}
}
change that to:
sub doText {
...
if (defined $_) {
...
}
}
And the other, required fix is to add the following function to Expat.pm:
sub finish {
my ($self) = @_;
foreach (keys %{$self->{_Setters}}) {
&{$self->{_Setters}->{$_}}($self->{Parser}, undef);
}
}
The first patch fixes a bug where you have <tag>0</tag> and the finish function
allows you to break out of a parse phase.
END OF WARNING.
====================================================================
NAME
CGI::XMLForm - Extension of CGI.pm which reads/generates
formated XML.
This is currently alpha software, and I'm looking for feedback.
Note though that it is proving quite stable in our mod_perl
environment, so it is ready for production use.
NB: This is a subclass of CGI.pm, so can be used in it's place.
SYNOPSIS
use CGI::XMLForm;
my $cgi = new CGI::XMLForm;
if ($cgi->param) {
print $cgi->header, $cgi->pre($cgi->escapeHTML($cgi->toXML));
}
else {
open(FILE, "test.xml") or die "Can't open: $!";
my @queries = ('/a', '/a/b*', '/a/b/c*', /a/d');
print $cgi->header,
$cgi->pre($cgi->escapeHTML(
join "\n", $cgi->readXML(*FILE, @queries)));
}
DESCRIPTION
This module can either create form field values from XML based
on XQL style queries (full XQL is _not_ supported - this module
is designed for speed), or it can create XML from form values.
There are 2 key functions: toXML and readXML.
toXML
The module takes form fields given in a specialised format, and
outputs them to XML based on that format. The idea is that you
can create forms that define the resulting XML at the back end.
The format for the form elements is:
<input name="/body/p/ul/li">
which creates the following XML:
<body>
<p>
<ul>
<li>Entered Value</li>
</ul>
</p>
</body>
It's the user's responsibility to design appropriate forms to
make use of this module, although coming later will be a small
module that uses my XML::DTDParser to create all the form
elements given a DTD.
Also supported are attribute form items, that allow creation of
element attributes. The syntax for this is:
<input name="/body/p[@id="mypara" and @onClick="someFunc()"]/@class">
Which creates the following XML:
<body>
<p id="mypara" onClick="someFunc()" class="Entered Value"></p>
</body>
Also possible are relative paths. So the following form
elements:
<input type="hidden" name="/table/tr">
<input type="text" name="td">
<input type="text" name="td">
<input type="text" name="../tr/td">
Will create the following XML:
<table>
<tr>
<td>value1</td>
<td>value2</td>
</tr>
<tr>
<td>value3</td>
</tr>
</table>
SYNTAX
The following is a brief syntax guideline
Full paths start with a "/" :
"/table/tr/td"
Relative paths start with either ".." or just a tag name.
"../tr/td"
"td"
Relative paths go at the level above the previous path, unless
the previous path was also a relative path, in which case it
goes at the same level. This seems confusing at first (you might
expect it to always go at the level above the previous element),
but it makes your form easier to design. Take the following
example: You have a timesheet (see the example supplied in the
archive) that has monday,tuesday,etc. Our form can look like
this:
<input type="text" name="/timesheet/projects/project/@Name">
<input type="text" name="monday">
<input type="text" name="tuesday">
...
Rather than:
<input type="text" name="/timesheet/projects/project/@Name">
<input type="text" name="monday">
<input type="text" name="../tuesday">
<input type="text" name="../wednesday">
...
If unsure I recommend using full paths, relative paths are great
for repeating groups of data, but weak for heavily structured
data. Picture the following paths:
/timesheet/employee/name/forename
../surname
title
../department
This actually creates the following XML:
<timesheet>
<employee>
<name>
<forename>val1</forname>
<surname>val2</surname>
<title>val3></title>
</name>
<department>val4</department>
</employee>
</timesheet>
Confusing eh? Far better to say:
/timesheet/employee/name/forename
/timesheet/employee/name/surname
/timesheet/employee/name/title
/timesheet/employee/department
Or alternatively, better still:
/timesheet/employee/name (Make hidden and no value)
forename
surname
title
../department
Attributes go in square brackets. Attribute names are preceded
with an "@", and attribute values follow an "=" sign and are
enclosed in quotes. Multiple attributes are separated with " and
".
/table[@bgcolor="blue" and @width="100%"]/tr/td
If setting an attribute, it follows after the tag that it is
associated with, after a "/" and it's name is preceded with an
"@".
/table/@bgcolor
readXML
readXML takes either a file handle or text as the first
parameter and a list of queries following that. The XML is
searched for the queries and it returns a list of tuples that
are the query and the match.
It's easier to demonstrate this with an example. Given the
following XML:
<a>Foo
<b>Bar
<c>Fred</c>
<c>Blogs</c>
</b>
<b>Red
<c>Barbara</c>
<c>Cartland</c>
</b>
<d>Food</d>
</a>
And the following queries:
/a
/a/b*
c*
/a/d
it returns the following result as a list:
/a
Foo
/a/b
Bar
c
Fred
c
Blogs
/a/b
Red
c
Barbara
c
Cartland
/a/d
Food
(NB: This is slightly incorrect - for /a and /a/b it will return
"Foo\n " and "Bar\n " respectively).
The queries support relative paths like toXML (including parent
paths), and they also support wildcards using ".*" or ".*?"
(preferably ".*?" as it's probably a better match). If a
wildcard is specified the results will have the actual value
substituted with the wildcard. Wildcards are a bit experimental,
so be careful ;-)
Caveats
There are a few caveats to using this module:
AUTHOR
Matt Sergeant msergeant@ndirect.co.uk,
sergeant@geocities.com
Based on an original concept, and discussions with, Jonathan
Eisenzopf. Thanks to the Perl-XML mailing list for
suggesting the XSL syntax.
Special thanks to Francois Belanger (francois@sitepak.com)
for his mentoring and help with the syntax design.
SEE ALSO
CGI(1), CGI::XML
|
