WOPI provides a coherent interface across different data providers, including CGI and CGI-based front ends (as, for example, FastCGI and the CGI module). However, what WOPI can do is to expose the same interface to access web information and functionalities to communicate with the remote client. It cannot change the model through which the dynamic page is served by the web server.
The CGI model has been designed to provide single entry point, relatively complex applications generating dynamically the whole content of the replied page. They are meant to be monolithic web applications taking care of a whole aspect of the dynamic site by themselves. Opposely, active server-side pages model has been designed with the idea of providing multiple simple entry points in the web-based applications, each being mainly a "view" entity being backed up, at best, by a central engine made of "common functions".
WOPI cannot completely overcome the differences between this two philosophical approaches to web based application programming; it limits to offer a consistent interface no matter what model you prefer to chose.
However, shaping down the web-based application so that it ignores this differences, it is possible to ensure that it runs seamlessly under both CGI oriented front-ends and server-side active pages oriented front-ends. And the result is also relatively elegant, so it's worth having a look.
The secret of this is offering a single entry point to the application, where all the decision about what elements to be loaded will be taken.
The structure of a site thought with this idea may be the following:
html_docs/
...
cgi-bin/
index.exe
index.fal
pages/
default.ftd
first.ftd
second.ftd
third.ftd
,...
The index.exe program would be the CGI front-end (it may be omitted in case we're using the cgi_fm module from within the index.fal script).
Our index.fal may look like this:
#!/usr/bin/falcon -pcgi
//^^ this is optional, and if available, it allows to work without the binary front-end.
// shows the real page
if "p" notin Requests.gets
errorDocument( "Sorry, page ID not provided" )
end
// try to load it at this point.
p = Requests.gets["p"]
try
include( "pages/" + p + ".ftd" )
catch in error
errorDocument( @"Sorry, cannot load required page \"$p\"", error )
end
// End of main program.
// expose an utility function to help creating links to ourself:
function makeLink( page )
return Request.uri + "?p=" + page
end
// A simple utility
function errorDocument( text, error )
>'
<html><head><title>Error!</title></head>
<body>
<h1>Error!</h1>
<p>'
> text, '</p>'
if error
> "<p><b>Error:</b><pre>", error,toString(), "</pre></p>"
end
> "</body><html>"
end
// export the utility functions so pages can use them
export makeLink, errorDocument
In this way, it doesn't matter if the application is served through a CGI interface or through a web-based interface. As long as every part of the web application respects the directive of indicating other pages to be loaded by adding a p field to the query of the link, instead of trying to link it directly, the page will be served through the main script, which will be loaded just the same under a CGI front-end or under an active server page based front-end.
Actually, many well-designed active server page based web applications adopt this approach just to simplify the organization of their site and to centralize all the setup operations, performing them before the element that takes care of a certain step (that is, a specific "page") is even loaded. It's a "configuration push" model, rather a configuration "pull", where each page must take care of loading the configuration and setting up the environment (for example, checking for a valid user to have logged in and filling the variables accordingly). This "push" design has been found superior by many web designer, so the need to use it to make CGI based and server-active-page based WOPI application seamlessly isomorphic should not be considered a limitation; rather, the ability to pick a simpler, direct model to treat the two kind of web applications differently is to be considered an extended feature of WOPI, which may be useful or not.