Since everything after the host part of the URL is sent to the server as is,
after transport encoding, the server in practice decides the meaning of that
part of the URL. Normally that part of the URL consists of a path part,
containing the path to a file the client wants, and a query part, containing
variables that may affect the way the server accomplishes the request.
http://roxen.com/products/platform/tech-features.xml?page=9 |
|
In the URL above we request the file /products/platform/tech-features.xml from
the host roxen.com with the variable page set to 9. Note that there is in
principle nothing that prevents us from making a server that returns the same
result with the following URL.
http://roxen.com/SELECT_page_FROM_features_WHERE_product=platform_AND_page=9 |
|
This is however not a good idea for several reasons, usability being the number
one. Users are used to alter the URL of a page to get to index-pages higher up
in the web site structure.
Index pages
The most common sidestep from the rule that the path part of the URL explicitly
denotes a file is directory URLs.
http://roxen.com/products/platform/ |
|
The above URL does not denotes a specific file in the /products/platform/
directory, but does instead point at the directory itself. The common approach
is to find an index file in the directory and send that file instead. This is
handled by the directory module, which by default looks for the files "index.html",
"index.xml", "index.htm", "index.pike" and "index.cgi" in that order.
Path info
Somtimes it can be practical to fake a directory structure, but let all requests
to the files in that directory lead to the same file. The example with the
tech-features.xml URL above could look like this:
http://roxen.com/products/platform/tech-features.xml/9/ |
|
The part of the URL after the actual file will then be provided to the file/script in
a special variable during its parsing.
Prestates
When developing and debugging is a great help to be able to turn on and off specific
parts of the code that generates the current page. This is an ideal application for
prestates, a mechanism invented by Roxen to enable the user to turn certain switches
on and off. The name and function of the prestates is decided by the page developer.
One example of how prestates are used is the Table/Image Border Unveiler module,
which is used on the community.roxen.com web site.
http://community.roxen.com/(tables)/developers/ |
|
This URL signifies that we want to fetch file at the path /developers/ from the host
commuinity.roxen.com with the protocol HTTP and with the prestate tables set. In the
WebServer the Table/Image Border Unveiler module recognizes the table prestate and
knows that the user wants all tables highlighted in the page. Compare the result with
how the page look without the prestate. It is also possible to add several prestates
to the same page in a comma separated list, e.g.
http://community.roxen.com/(tables,images)/developers/ |
|
Prestates can of course be used for many other things than switching debugging flags,
e.g. moving states between pages like a browser window local cookie. See
<apre> and <if prestate> for
more information about how to control and detect prestates in your RXML applications.
Config states
A variation of prestates is the config state. Looks very similar to the prestates,
but stores its value in a cookie. Looking at the following URL will store the value
"bacon" in the cookie RoxenConfig, which will be valid for two years since its latest
change. After the cookie has been set, the server will redirect to the page you came
from, or it it was unable to dermine that page, to the same URL but without the config
state.
http://community.roxen.com/<bacon>/ |
|
Removing a config state value is a little trickier than with prestates, since you can
not edit them by hand, as with the URL. Prepending a minus sign before a config state
flag indicates that it should be removed from the RoxenConfig cookie. As with prestates
it is possible to combine several states at the same time, both with and without minus
signs.
http://community.roxen.com/<egg,-bacon>/ |
|
See <aconf> and <if config> for
more information about how to control and detect config stats in your RXML applications.
