Building Applications - eXist: A NoSQL Database and Application Development Platform - page 203

<cache-control cache = "yes" | "no" />
Setting the cache attribute to "yes" adds an entry for the dispatch rule to an internal
map and prevents the controller from being triggered again for the input URL. For
instance:

<dispatch xmlns= "http://exist.sourceforge.net/NS/exist" >
<redirect url= "home" />
<cache-control cache= "yes" />
</dispatch>

URL rewrite caching has nothing to do with HTTP caching; only
the dispatch rule is cached, not the response.

Advanced URL Control
URL rewriting is capable of more than just passing on or redirecting a request. It can
also pass on the results of a forwarded request to a pipeline (a.k.a. sequence or view)
of additional processing steps (usually XQuery and/or XSLT scripts).
The most common use case for this is probably the Model-View-Controller or MVC
pattern, separating the application logic from its presentation. In the case of URL
rewriting, controller.xql is the controller in the MVC pattern. Then we create an
XML document, describing the contents of the response (but not its presentation).
This becomes the model in the MVC pattern. Subsequent processing steps add the
presentation to this, usually by transforming it to (X)HTML. This is the view in the
MVC pattern.

URL rewriting allows you to specify such actions in the XML fragment output of the
URL rewriting controller. To do this, add a view element after the forward element,
containing the additional processing steps.
Here is a simple example of such an XML fragment. You can see this example in
action

by browsing to http://localhost:8080/exist/apps/exist-book/building-

applications/views/ :

<dispatch xmlns= "http://exist.sourceforge.net/NS/exist" >
<forward url= "{concat($exist:controller, " /createmodel.xq")}" />
<view>
<forward servlet= "XSLTServlet" >
<set-attribute name= "xslt.stylesheet"
value= "{concat($exist:root, $exist:controller, " /xslt/view1.xslt")}" />
</forward>
</view>
</dispatch>