ad_header)
ad_header in /tcl/ad-defs.tcl
to do something more dramatic (e.g., display a company logo at the top
right of each page).
ad_footer in /tcl/ad-defs.tcl
to do something consistent at the bottom of all the pages on a site
regsub calls in
ad_serve_html_page (in /tcl/ad-html.tcl) to consistently
change the appearance of outgoing pages.
If you're building from scratch, you could build in ADP instead of HTML
and use ns_register_adptag to augment the HTML a bit.
ad_header or your static
HTML to reference a cascading style sheet (CSS). See the HTML chapter of
Philip and Alex's Guide to Web Publishing for an
explanation and also do a View Source on the document to see a style
sheet reference from the HEAD of a document.
This doesn't work out too great because (1) only the 4.0 browsers interpret style sheets, and (2) Brand M and Brand N browsers do very different things given the same instructions (each implements a subset of the CSS standard).
So what's the big deal? Let them write whatever HTML they want.
The problem is that they want control over pages that are generated by querying the database and executing procedures but they don't want to learn how to program. Your naive solution is to let the designers build static HTML files and show them to you. You'll work these elements into Tcl string literals and write programs that print them to the browser. In the end you'll have programs that query the database and produce output exactly like what the designer wanted... on Monday. By Friday, the designer has changed his or her mind. Would you rather spend your life attacking the hard problem of Web-based collaboration or moving strings around inside .tcl pages?
In future, a change to the look of a site won't require a programmer, only someone who knows HTML and who is careful enough not to disturb references to variables.To: Web Developers I want you to put all the SQL queries into Tcl functions that get loaded at server start-up time. The graphic designers are to build ADP pages that call a Tcl procedure which will set a bunch of local variables with values from the database. They are then to stick <%=$variable_name=> in the ADP page wherever they want one of the variables to appear. Alternatively, write .tcl scripts that implement the "business logic" and, after stuffing a bunch of local vars, call ns_adp_parse to drag in the ADP created by the graphic designer.
ad_register_styletag. This procedure will (a) record that
we've got a style we want to use site-wide, (b) register an ADP tag, and
(c) create a Tcl function to be used by straight .tcl pages (and that is
also called by the ADP subsystem)
Caveat nerdor: remember that AOLserver sources private Tcl libraries
alphabetically. So your calls to ad_register_styletag must
be in a Tcl file that sorts alphabetically after "ad-style.tcl" (we
suggest that you stick to a convention of "sitename-styles.tcl", e.g.,
"photonet-styles.tcl" would be the photo.net styles).
| Language Name | Code | Language Family |
|---|---|---|
| Abkhazian | ab | Ibero-Caucasian |
| Afan (Oromo) | om | Hamitic |
| Afar | aa | Hamitic |
| Afrikaans | af | Germanic |
| Albanian | sq | Indo-european (other) |
| Amharic | am | Semitic |
| Arabic | ar | Semitic |
| Armenian | hy | Indo-european (other) |
| Assamese | as | Indian |
| Aymara | ay | Amerindian |
| Azerbaijani | az | Turkic/altaic |
| Bashkir | ba | Turkic/altaic |
| Basque | eu | Basque |
| Bengali;bangla | bn | Indian |
| Bhutani | dz | Asian |
| Bihari | bh | Indian |
| Bislama | bi | [notgiven] |
| Breton | br | Celtic |
| Bulgarian | bg | Slavic |
| Burmese | my | Asian |
| Byelorussian | be | Slavic |
| Cambodian | km | Asian |
| Catalan | ca | Romance |
| Chinese | zh | Asian |
| Corsican | co | Romance |
| Croatian | hr | Slavic |
| Czech | cs | Slavic |
| Danish | da | Germanic |
| Dutch | nl | Germanic |
| English | en | Germanic |
| Esperanto | eo | Internationalaux. |
| Estonian | et | Finno-ugric |
| Faroese | fo | Germanic |
| Fiji | fj | Oceanic/indonesian |
| Finnish | fi | Finno-ugric |
| French | fr | Romance |
| Frisian | fy | Germanic |
| Galician | gl | Romance |
| Georgian | ka | Ibero-caucasian |
| German | de | Germanic |
| Greek | el | Latin/greek |
| Greenlandic | kl | Eskimo |
| Guarani | gn | Amerindian |
| Gujarati | gu | Indian |
| Hausa | ha | Negro-african |
| Hebrew | iw | Semitic |
| Hindi | hi | Indian |
| Hungarian | hu | Finno-ugric |
| Icelandic | is | Germanic |
| Indonesian | in | Oceanic/indonesian |
| Interlingua | ia | Internationalaux. |
| Interlingue | ie | Internationalaux. |
| Inupiak | ik | Eskimo |
| Irish | ga | Celtic |
| Italian | it | Romance |
| Japanese | ja | Asian |
| Javanese | jv | Oceanic/indonesian |
| Kannada | kn | Dravidian |
| Kashmiri | ks | Indian |
| Kazakh | kk | Turkic/altaic |
| Kinyarwanda | rw | Negro-african |
| Kirghiz | ky | Turkic/altaic |
| Kurundi | rn | Negro-african |
| Korean | ko | Asian |
| Kurdish | ku | Iranian |
| Laothian | lo | Asian |
| Latin | la | Latin/greek |
| Latvian;lettish | lv | Baltic |
| Lingala | ln | Negro-african |
| Lithuanian | lt | Baltic |
| Macedonian | mk | Slavic |
| Malagasy | mg | Oceanic/indonesian |
| Malay | ms | Oceanic/indonesian |
| Malayalam | ml | Dravidian |
| Maltese | mt | Semitic |
| Maori | mi | Oceanic/indonesian |
| Marathi | mr | Indian |
| Moldavian | mo | Romance |
| Mongolian | mn | [notgiven] |
| Nauru | na | [notgiven] |
| Nepali | ne | Indian |
| Norwegian | no | Germanic |
| Occitan | oc | Romance |
| Oriya | or | Indian |
| Pashto;pushto | ps | Iranian |
| Persian | (farsi) | Fairanian |
| Polish | pl | Slavic |
| Portuguese | pt | Romance |
| Punjabi | pa | Indian |
| Quechua | qu | Amerindian |
| Rhaeto-romance | rm | Romance |
| Romanian | ro | Romance |
| Russian | ru | Slavic |
| Samoan | sm | Oceanic/indonesian |
| Sangho | sg | Negro-african |
| Sanskrit | sa | Indian |
| Scots | gaelic | Gdceltic |
| Serbian | sr | Slavic |
| Serbo-croatian | sh | Slavic |
| Sesotho | st | Negro-african |
| Setswana | tn | Negro-african |
| Shona | sn | Negro-african |
| Sindhi | sd | Indian |
| Singhalese | si | Indian |
| Siswati | ss | Negro-african |
| Slovak | sk | Slavic |
| Slovenian | sl | Slavic |
| Somali | so | Hamitic |
| Spanish | es | Romance |
| Sundanese | su | Oceanic/indonesian |
| Swahili | sw | Negro-african |
| Swedish | sv | Germanic |
| Tagalog | tl | Oceanic/indonesian |
| Tajik | tg | Iranian |
| Tamil | ta | Dravidian |
| Tatar | tt | Turkic/altaic |
| Telugu | te | Dravidian |
| Thai | th | Asian |
| Tibetan | bo | Asian |
| Tigrinya | ti | Semitic |
| Tonga | to | Oceanic/indonesian |
| Tsonga | ts | Negro-african |
| Turkish | tr | Turkic/altaic |
| Turkmen | tk | Turkic/altaic |
| Twi | tw | Negro-african |
| Ukrainian | uk | Slavic |
| Urdu | ur | Indian |
| Uzbek | uz | Turkic/altaic |
| Vietnamese | vi | Asian |
| Volapuk | vo | Internationalaux. |
| Welsh | cy | Celtic |
| Wolof | wo | Negro-african |
| Xhosa | xh | Negro-african |
| Yiddish | ji | Germanic |
| Yoruba | yo | Negro-african |
| Zulu | zu | Negro-african |
What about language variants, e.g., British English versus correct English? The standard way to handle variants is with suffixes, e.g., "zh-CN" and "zh-TW" for Chinese from China and Taiwan respectively, "en-GB" and "en-US" for UK and US English, "fr-CA" and "fr-FR" for Quebecois and French French. We think this is cumbersome and can't imagine anyone wanting to have templates named "foobar.fancy.en-US.adp". Our system doesn't require that the two-character coding be ISO-standard. A publisher who wished to serve British and American readers could use "gb" and "us", for example. Non-standard? Yes. But in my defence, let me note that if you've flown over to England in an aeroplane, gone out in a mackintosh with a brolly, rotted your teeth on fairy cakes with coloured frosting, you probably have worse problems that non-standard file names.
ad_return_template.
If you need to set a cookie, bash ns_conn outputheaders.
How does ad_return_template work? It goes up one Tcl
level so that it can have access to all the local vars that bar.tcl
might have set. Then it looks at the user's language and graphics
preferences (from the users_preferences defined in
community-core.sql). Then it looks in the templates subtree of the file
system to see what the closest matching template is (language preference
overrides graphics preference).
Note that ad_return_template returns headers and content
bytes to the connection but does not terminate the thread. So you can
do logging or other database activity following the service of the
parsed ADP template to the user.
users_preferences. You might
want to offer casual users a choice of languages or graphics
complexity (see scorecard.org for an
example). In this case, you need to use cookies to record what the user
said he or she wanted.
It is tough to know how and where the publisher will want to present
users with language and graphics options. But we can build standard Tcl
API calls into /tcl/ad-style.tcl if we agree to standardize on cookie
names. So let's agree on the same names as the columns in
users_preferences: "prefer_text_only_p" (value "t" or "f")
and "language_preference" (two-char lowercase code).
Note that the code in ad-style.tcl will only look for cookies if PlainFancyCookieP and LanguageCookieP parameters are turned on.