![]() |
| Frontier Tutorials / Writing an ObjectNotFoundHandler / Mode 1 Example |
When it finds an objectNotFound entry in the page table, and that entry points to a script, mainResponder.respond assumes that the script will return the page body text to be inserted in the template.
The script constructs and returns the entire body text for the page. This may include website framework calls to render data from elsewhere in the ODB--even from other websites or guest databases. It could even include calls outside of Frontier--to the file system or an SQL database, for example.
mainResponder.respond will insert whatever your script returns into the site template, as though it were a normal page. The script is simply rendered as a website page.
In this example, we will generate a page-not-found page with a site search form, and return it as the page content.
In your #tools table, create a script called "PageNotFound". For the moment, leave it very simple:
|
|---|
As you can see, it' simply sets the page title and HTTP return code, and returns very simple page text. (Thanks to Jason Levine for the reminder that we should set the return code.)
At the top level of your site, create an address entry named "#objectNotFoundHandler", and set its value to the address of your new "PageNotFound" script. PageNotFound is now your objectNotFoundHandler script.
Now check that it's working correctly with mainResponder. Go to your browser on the same machine, and enter the URL "http://localhost/onfhTutorial/notThere". You should get a very simple page that reads "404 - FILE NOT FOUND"; the page title should be "404 - File Not Found".
Obviously, this is not the output we want. However, it confirms for us that the site is properly configured and that the ONFH mechanism is working.
We want to add a search form to the template. For this example, the form will be non-functional, since we haven't added search engine support to the examples website. However, this will demonstrate the flexibility of the approach.
At the top level of your site, create a new subtable named "#forms". Inside that table, create a new outline named "search" with the following content:
|
|---|
At the top level of your site, create a new entry (outline or wptext) named "#notFoundText", with the following content:
|
|---|
Now open up and expand the PageNotFound script to this:
|
|---|
If #notFoundText exists, this script will insert the missing path in the page table as whatObjectNotFound. It will then return the text of #notFoundText, after calling html.processMacros on it. For the #notFoundText entry above, this would create a hot-link to the site outline (if there were one) and expand the "{whatObjectNotFound}" and "{string( forms^.search )}" macros we inserted in the text.
If #notFoundText does not exist, this script reverts to a very simple message, as in the first script, above.
Now go back to your browser and reload the page ("http://localhost/onfhTutorial/notThere"). Your page should resemble the following:
|
|---|
The "page not found" page returned by your PageNotFound script can be as simple or complex as you like.
There's a problem with the above scripts, though. Or, more properly, with the combination of the above scripts, The Walk, and the way the #objectNotFoundHandler mechanism works.
If you add the above script to a website that has other links on the page--such as navigation bars--you'll notice that the URLs in your other links will sometimes be wrong. This problem will appear any time your #objectNotFoundHandler is at a different level than that which The Walk reached before calling your objectNotFoundHandler. We'll look at this misdirected-URL problem after we look at the other operating modes in detail.