- Flow of control in a DCat application.


DCat generally expects its requests to be of the form:
http://www.DCatserver.com/dcat/appname/pagename
or
http://www.DCatserver.com/dcat/appname/pagename?somevar=somevalue& . . .
Here, "dcat" corresponds to a mod_jk JkMount directive in Apache's httpd.conf file, and the rest of the URI provides a path into the application set tree, the root of which is specified in the DCat service/daemon’s properties file.

The initial request takes the limited form:
http://www.DCatserver.com/dcat/appname
In this case the starting page is determined from the ASD.

These URIs make no attempt to specify what page should be processed next. They merely report what page submitted the request except in the case of the initial request, which just states what application is to be entered. The DCat framework will determine what page is to be served up next. You make those decisions when you write the XML for the application set. The ASD is parsed and loaded when the DCat service/daemon is started. Then the application-set data becomes available as read-only data to all worker threads in the application.

For cosmetic purposes, you may, as appropriate, add either of the pseudo page names "_start_" or "_nextpage_" to the URI. This provides information in the address bar that may make the sequencing of pages clearer to the user. For example, if the first two pages are "page1" and "page2", and the actual pages have similar headings, then when page1 submits, the address bar will show "/dcat/app1/page1", while the heading of the displayed page will be "Page 2". This is mildly confusing, and it is probably better to see "/dcat/app1/page1/_nextpage_" in the address bar. This makes it clear that the situation is not a contradiction.
[If browsers responded appropriately to a 201 response code, and used the URI from the location response header to populate the address bar, this stuff would not be neccessary.]. The following forms are therefore acceptable:
http://www.DCatserver.com/dcat/appname/pagename/_nextpage_
http://www.DCatserver.com/dcat/appname/_start_
When DCat receives such a request, the first thing it does is to parse out the variable values supplied in the GET/POST request. DCat makes no particular distinction between these two types of request, and simply places the variable name/value pairs in a symbol table in a 'Request Object' for future reference.

What happens next is determined initially by the 'phases' attribute on the page of the supplied name, or the page designated as first. If this contains the 'r' flag for return processing, then the PIO for the page is loaded and cached, and its returnproc() method is called (as long as this isn't the first call to the first page). If the PIO doesn't have the appropriate entry point, DCat reports an error and sends an e'ror page back to Apache.

Once any return processing has been completed, DCat determines from the page definition, using any supplied conditions, what page is to be served next. (The return processing can if necessary force an arbitrary page, but this is rather like using goto. You can't then tell what will happen simply by knowing the values of variables and looking at the ASD.)

A sequence of operations is then possible, depending on the value of the 'phases' attribute on this next page:
- Preamble (p) - general processing before the next page can be generated,
- If the page specifies a template - a .dcat file, check the modification date of the template against any existing translated version, and if necessary, repeat the translation process, or translate the .dcat file for the first time.
- If the phases attibute specifies insertion point processing (i), then the corresponding method in the PIO is called. Otherwise a standard proceedure is used for substitution.
- Set cookies (c) - set up the values for any required cookies,
- Extra headers (h) - set up the strings for any HTTP headers other than the standard ones,
- Load the compiled .fragments file and select its generate method, and call that to output the page content, or if there is no template, generate the content using the appropriate method in the PIO.
- Send the headers and content back to Apache via the connector.
- Call the postamble of any PIO if specified (a).
The .dcat file utilizes syntax similar to that of a .jsp file with the exception of referenced components. The compilation process for the .dcat file results in a .fragments file - a list of literal sections and substitution points that can be very quickly instantiated at run time. When it is 'finalized' by substitution, sources for substitution variable are:
- Get/post request data symbol table,
- Cookies symbol table,
- State data,
- Application set object variables.

These constitute six distinct namespaces, since the ApplicationSet object is essentially a set of nested string[string] associative array references that represent the content of the ASD XML file for a particular page - appset/app/page. In the .dcat file these are referenced via prefixes like AS:varname, AP:varname, PG:varname, CK:varname, ST:varname, and varname. The undecorated varname refers to the GET/POST data. The namespace prefixes can be overidden in the ASD file.

The interface implemented by PIO objects is as follows. Only a subset of these methods will need to be implemented in most cases.
struct DCatContext
{
const(string[string]) requestdata;
const(string[string]) cookies;
const(TinyXML) state;
const(ApplicationSet) appset;
bool delegate(string objectName, Object object) holdObject;
Object delegate(string objectName) retrieveObject;
void delegate(string objectName) releaseObject;
}
interface PIO
{
string returnProc(string prevpage, string nextpage, DCatContext* context);
void preamble(DCatContext* context);
string interpretIP(string ipname, DCatContext* context);
string doInsertions(FragmentList() fl, DCatContext* context);
string[] generateHeaders(DCatContext* context);
string generateContent(DCatContext* context);
string[] setCookies(DCatContext* context);
void postamble(DCatContext* context);
}

When the response generation is complete, but before the end of processing is signaled to the Apache connector, a PIO postamble entry point may be called if specified for the page to give you an opportunity to clear up any data structures you may have created in the stages described above.

The page sent to the browser in this way will in turn submit a request embodying its qualified name (/appset/app/page), and the sequence will be repeated as required.

If a page that has no next-page specification is submitted, the exit page specified for the application, or failing that for the application set, will be displayed. In this case only, the framework will simply serve the contents of a file.

|