ad_headerin /tcl/ad-defs to do something more dramatic (e.g., display a company logo at the top right of each page).
ad_footerin /tcl/ad-defs to do something consistent at the bottom of all the pages on a site
ad_serve_html_page(in /tcl/ad-html) to consistently change the appearance of outgoing pages.
If you're building from scratch, you could build in ADP instead of HTML
ns_register_adptag to augment the HTML a bit.
ad_headeror 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 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 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 pages (and that is also called by the ADP subsystem)
Caveat nerdor: remember that AOLserver sources private Tcl libraries
alphabetically. So your calls to
be in a Tcl file that sorts alphabetically after "ad-style" (we
suggest that you stick to a convention of "sitename-styles", e.g.,
"photonet-styles" would be the photo.net styles).
|Language Name||Code||Language Family|
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.
If you need to set a cookie, bash
ad_return_template work? It goes up one Tcl
level so that it can have access to all the local vars that bar
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).
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.
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 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 will only look for cookies if PlainFancyCookieP and LanguageCookieP parameters are turned on.