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
|
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
|
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
+
+
-
-
-
|
the %unsafe() substitution should be avoid whenever possible.
The /env page is implemented by the "wapp-page-env" proc. This proc
generates HTML that describes all of the query parameters. Parameter names
that begin with "." are for internal use by Wapp and are skipped
for this display. Notice the use of "wapp-subst" to safely escape text
for inclusion in an HTML document.
The printing of all the parameters as is done by the /env page turns
out to be so useful that there is a special "wapp-debug-env" command
to render the text for us. Using "wapp-debug-env", the program
above can be simplified to the following:
>
package require wapp
proc wapp-default {} {
set B [wapp-param BASE_URL]
wapp-trim {
<h1>Hello, World!</h1>
<p>See the <a href='%html($B)/env'>Wapp
Environment</a></p>
}
}
proc wapp-page-env {} {
wapp-allow-xorigin-params
wapp-trim {
<h1>Wapp Environment</h1>\n<pre>
<pre>%html([wapp-debug-env])</pre>
}
}
wapp-start $argv
Most Wapp applications contain an /env page for debugging and
trouble-shooting purpose. Examples:
<https://sqlite.org/checklists/env> and
<https://sqlite.org/search?env=1>
2.1 Binary Resources
--------------------
Here is another variation on the same "hello, world" program that adds an
image to the main page:
>
package require wapp
proc wapp-default {} {
set B [wapp-param BASE_URL]
wapp-trim {
<h1>Hello, World!</h1>
<p>See the <a href='%html($B)/env'>Wapp
Environment</a></p>
<p>Broccoli: <img src='broccoli.gif'></p>
}
}
proc wapp-page-env {} {
wapp-allow-xorigin-params
wapp-trim {
wapp-subst {<h1>Wapp Environment</h1>\n<pre>\n}
foreach var [lsort [wapp-param-list]] {
<h1>Wapp Environment</h1>\n<pre>
<pre>%html([wapp-debug-env])</pre>
if {[string index $var 0]=="."} continue
wapp-subst {%html($var) = %html([list [wapp-param $var]])\n}
wapp-subst {</pre>\n}
|
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
|
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
|
-
+
-
+
|
-------------------------------------------
Wapp applications all follow the same basic template:
>
package require wapp;
proc wapp-page-XXXXX {} {
# code to generate page XXXX
# code to generate page XXXXX
}
proc wapp-page-YYYYY {} {
# code to generate page YYYY
# code to generate page YYYYY
}
proc wapp-default {} {
# code to generate any page not otherwise
# covered by wapp-page-* procs
}
wapp-start $argv
|
248
249
250
251
252
253
254
255
256
|
276
277
278
279
280
281
282
283
284
|
-
+
|
wapp-start $argv
The controller and view portions of each page need not be coded
together into the same proc. They can each be sub-procs that
are invoked from the main proc, if separating the functions make
code clearer.
So Wapp does support MVC, but without a lot of extra
So Wapp does support MVC, but without a lot of complex
machinary and syntax.
|