Introducing To Writing W3 Applications
========================================
1.0 Hello World
---------------
W3 applications are easy to develop. A hello-world program is as follows:
>
#!/usr/bin/w3tclsh
package require w3
proc w3-default {} {
w3-subst {<h1>Hello, World!</h1>\n}
}
w3-start $::argv
Every W3 application defines one or more procedures that accept HTTP
requests and generate appropriate replies.
For an HTTP request where the initial portion of the URI path is "abcde", the
procedure named "w3-page-abcde" will be invoked to construct the reply.
If no such procedure exists, "w3-default" is invoked instead. The latter
technique is used for the hello-world example above.
The hello-world example generates the reply using a single call to the "w3-subst"
command. Each "w3-subst" command appends new text to the reply, applying
various substitutions as it goes. The only substitution in this example is
the \\n at the end of the line.
The "w3-start" command starts up the application.
1.1 Running A W3 Application
------------------------------
To run this application, copy the code above into a file named "main.tcl"
and then enter the following command:
>
w3tclsh main.tcl
That command will start up a web-server bound to the loopback
IP address, then launch a web-browser pointing at that web-server.
The result is that the "Hello, World!" page will automatically
appear in your web browser.
To run this same program as a traditional web-server on TCP port 8080, enter:
>
w3tclsh main.tcl --server 8080
Here the built-in web-server listens on all IP addresses and so the
web page is available on other machines. But the web-browser is not
automatically started in this case, so you will have to manually enter
"http://localhost:8080/" into your web-browser in order to see the page.
To run this program as CGI, put the main.tcl script in your web-servers
file hierarchy, in the appropriate place for CGI scripts, and make any
other web-server specific configuration changes so that the web-server
understands that the main.tcl file is a CGI script. Then point your
web-browser at that script.
Run the hello-world program as SCGI like this:
>
w3tclsh main.tcl --scgi 9000
Then configure your web-server to send SCGI requests to TCP port 9000
for some specific URI, and point your web-browser at that URI. By
default, the web-server must be on the same machine as the w3 script.
The --scgi option only accepts SCGI requests from IP address 127.0.0.1.
If your webserver is running on a different machine, use the --remote-scgi
option instead, probably with a --fromip option to specify the IP address
of the machine that is running the webserver.
1.2 Using Plain Old Tclsh
-------------------------
W3 applications are pure TCL code. You can run them using an ordinary
"tclsh" command if desired, instead of the "w3tclsh" shown above. We
normally use "w3tclsh" for the following reasons:
+ W3tclsh is statically linked, so there is never a worry about
having the right shared libraries on hand. This is particularly
important if the application will ultimately be deployed into a
chroot jail.
+ W3tclsh has SQLite built-in and SQLite turns out to be very
useful for the kinds of small applications where W3 excels.
+ W3tclsh knows how to process "package require w3". If you
run with ordinary tclsh, you might need to change the
"package require w3" into "source w3.tcl" and ship the separate
"w3.tcl" script together with your application.
We prefer to use w3tclsh and w3tclsh is shown in all of the examples.
But ordinary "tclsh" will work in the examples too.
2.0 Longer Examples
-------------------
W3 keeps track of various [parameters](params.md) that describe
each HTTP request. Those parameters are accessible using routines
like "w3-param _NAME_"
The following sample program gives some examples:
>
package require w3
proc w3-default {} {
set B [w3-param BASE_URL]
w3-trim {
<h1>Hello, World!</h1>
<p>See the <a href='%html($B)/env'>W3
Environment</a></p>
}
}
proc w3-page-env {} {
w3-allow-xorigin-params
w3-subst {<h1>W3 Environment</h1>\n<pre>\n}
foreach var [lsort [w3-param-list]] {
if {[string index $var 0]=="."} continue
w3-subst {%html($var) = %html([list [w3-param $var]])\n}
}
w3-subst {</pre>\n}
}
w3-start $argv
In this application, the default "Hello, World!" page has been extended
with a hyperlink to the /env page. The "w3-subst" command has been
replaced by "w3-trim", which works the same way with the addition that
it removes surplus whitespace from the left margin, so that the generated
HTML text does not come out indented. The "w3-trim" and "w3-subst"
commands in this example use "%html(...)" substitutions. The "..." argument
is expanded using the usual TCL rules, but then the result is escaped so
that it is safe to include in an HTML document. Other supported
substitutions are "%url(...)" for
URLs on the href= and src= attributes of HTML entities, "%qp(...)" for
query parameters, "%string(...)" for string literals within javascript,
and "%unsafe(...)" for direct literal substitution. As its name implies,
the %unsafe() substitution should be avoided whenever possible.
The /env page is implemented by the "w3-page-env" proc. This proc
generates HTML that describes all of the query parameters. Parameter names
that begin with "." are for internal use by W3 and are skipped
for this display. Notice the use of "w3-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 "w3-debug-env" command
to render the text for us. Using "w3-debug-env", the program
above can be simplified to the following:
>
package require w3
proc w3-default {} {
set B [w3-param BASE_URL]
w3-trim {
<h1>Hello, World!</h1>
<p>See the <a href='%html($B)/env'>W3
Environment</a></p>
}
}
proc w3-page-env {} {
w3-allow-xorigin-params
w3-trim {
<h1>W3 Environment</h1>\n<pre>
<pre>%html([w3-debug-env])</pre>
}
}
w3-start $argv
Many W3 applications contain an /env page for debugging and
trouble-shooting purpose. Examples:
<https://sqlite.org/src/ext/checklist/top/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 w3
proc w3-default {} {
set B [w3-param BASE_URL]
w3-trim {
<h1>Hello, World!</h1>
<p>See the <a href='%html($B)/env'>W3
Environment</a></p>
<p>Broccoli: <img src='broccoli.gif'></p>
}
}
proc w3-page-env {} {
w3-allow-xorigin-params
w3-trim {
<h1>W3 Environment</h1>\n<pre>
<pre>%html([w3-debug-env])</pre>
}
}
proc w3-page-broccoli.gif {} {
w3-mimetype image/gif
w3-cache-control max-age=3600
w3-unsafe [binary decode base64 {
R0lGODlhIAAgAPMAAAAAAAAiAAAzMwBEAABVAABmMwCZMzPMM2bMM5nMM5nMmZn/
mczMmcz/mQAAAAAAACH5BAEAAA4ALAAAAAAgACAAAAT+0MlJXbmF1M35VUcojNJI
dh5YKEbRmqthAABaFaFsKG4hxJhCzSbBxXSGgYD1wQw7mENLd1FOMa3nZhUauFoY
K/YioEEP4WB1pB4NtJMMgTCoe3NWg2lfh68SCSEHP2hkYD4yPgJ9FFwGUkiHij87
ZF5vjQmPO4kuOZCIPYsFmEUgkIlJOVcXAS8DSVoxB0xgA6hqAZaksiCpPThghwO6
i0kBvb9BU8KkASPHfrXAF4VqSgAGAbpwDgRSaqQXrLwDCF5CG9/hpJKkb17n6RwA
18To7whJX0k2NHYjtgXoAwCWPgMM+hEBIFDguDrjZCBIOICIg4J27Lg4aGCBPn0/
FS1itJdNX4OPChditGOmpIGTMkJavEjDzASXMFPO7IAT5M6FBvQtiPnTX9CjdYqi
cFlgoNKlLbbJfLqh5pAIADs=
}]
}
w3-start $argv
This application is the same as the previous except that it adds the
"broccoli.gif" image on the main "Hello, World" page. The image file is
a separate resource, which is provided by the new "w3-page-broccoli.gif"
proc. The image is a GIF which has been encoded using base64 so that
it can be put into an text TCL script. The "[binary decode base64 ...]"
command is used to convert the image back into binary before returning
it.
Other resources might be added using procs like "w3-page-style.css"
or "w3-page-script.js".
3.0 General Structure Of A W3 Application
-------------------------------------------
W3 applications all follow the same basic template:
>
package require w3;
proc w3-page-XXXXX {} {
# code to generate page XXXXX
}
proc w3-page-YYYYY {} {
# code to generate page YYYYY
}
proc w3-default {} {
# code to generate any page not otherwise
# covered by w3-page-* procs
}
w3-start $argv
The application script first loads the W3 code itself using
the "package require" at the top. (Some applications may choose
to substitute "source w3.tcl" to accomplish the same thing.)
Next the application defines various procs that will generate the
replies to HTTP requests. Different procs are invoked based on the
first element of the URI past the W3 script name. Finally,
the "w3-start" routine is called to start W3 running. The
"w3-start" routine never returns (or in the case of CGI, it only
returns after the HTTP request has been completely processed),
so it should be the very last command in the application script.
3.1 W3 Applications As Model-View-Controller
----------------------------------------------
If you are accustomed to thinking of web applications using the
Model-View-Controller (MVC) design pattern, W3 supports that
point of view. A basic template for an MVC W3 application
is like this:
>
package require w3;
# procs to implement the model go here
proc w3-page-XXXXX {} {
# code to implement controller for XXXXX
# code to implement view for XXXXX
}
proc w3-page-YYYYY {} {
# code to implement controller for YYYYY
# code to implement view for YYYYY
}
proc w3-default {} {
# code to implement controller for all other pages
# code to implement view for all other pages
}
w3-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 W3 does support MVC, but without a lot of complex
machinary and syntax.