I'm proud to announce that DSP is finally in an early beta state. The download, dsp-0.1b.zip is the current source-set complete with buildable sources. - Eric Anderton (aka Pragma)
As this is beta software, the use of the source and test server are somewhat less than ideal. If you have any questions installing this software, please contact me at ericanderton@yahoo.com for assistance.
Download the dsp-0.1b.zip and unpackage in a fresh directory like "/dev/dsp". Run the dspruntime.bat file, to create the needed .obj files in the /runtime directory. Use build to build server.d, and the DSP conformance suite dspconf.d.
Once you complete these steps, you'll need to review the app.xml file and change the 'path' attribute to the absolute path for the /dspconf directory. One such path has already been provided.
After that, run server.exe. The default configuration (server.xml) will listen to "http://localhost:8080". The dspconf application is configured (app.xml) to the "/foo/bar/" path beneath that. Simply try loading "http://localhost:8080/foo/bar/dsp01.dsp" and you'll see the test case run.
DSP files are flat-text files that have the extension .dsp. The internal strucutre of the file, while not strictly XML, does need to be well-formed markup if any is present. Because of this, all HTML must appear as XHTML in order to pass muster as being XML compatible. Almost all browsers can handle XHTML output, and you'll find that using DSP in this fashion will lead to cleaner servlet scripts as a result.
The basic rule of thumb is: anything not a DSP tag will be passed through to the servlet output, while anything else must be valid D code.
Beta 1 presently supports the following tags anywhere in a dsp source file:
<?dsp code ?> <?dsp:in COW in code ?> <?dsp:out COW out code ?> <?dsp:body COW body code, same as plain 'dsp' ?> <?dsp:output plain text to output ?> <?dsp:xml passed to the client as an <?xml ... ?> ?>
In order to allow DSP to be fully XML-compliant when authoring, the following tags, while redundant with the earlier set, are provided:
<dsp:in> COW in code </dsp:in> <dsp:out> COW out code </dsp:out > <dsp:body> COW body code </dsp:body> <dsp:code> COW body code </dsp:code>
The only major gotchas with working in dsp is the use of comparison operators that contain the '<' and '>' symbols. In order to avoid problems with parsing, it's a good idea to use either a CDATA section or the standard subsitution entities (< and >).
<dsp:code><[CDATA[ int a; if(a<4){} ]]></dsp:code> <dsp:code> int a; if(a < 4){} </dsp:code>DSP also provides a way to generate output for attributes and text-content by way of the '#' operator. Any sequence of characters between a pair of '#' symbols will be treated as code 'x' that will satisfy the expression 'toString(x)'
<?dsp char[] myclass="header"; ?> <div class='#myclass#' />
The expression '#myclass#' will be converted to 'toString(myclass)', which should output <div class='header'/> in the client output. Any combination of plain text and escaped text can be used, and will be concatenated into the output. Also, the expression '##' will evaluate to a single '#'.
<div class='foo_#myclass#bar##'/> ... will yield ... <div class='foo_headerbar#' /> .... in the client output.
ColdFusion programmers will find this very familiar. The only major difference between this and CF is that the expression must stay completely within the attribute text. Also, one cannot use this syntax to generate tag names or attribute names dynamically (this limitation will be covered in later versions of DSP).
XML comments are consumed by the DSP runtime and not sent to the client by default. You can use the inline statment operator '#' to begin your comment, and thus force a comment to emit to the client.
<!-- this won't show --> <!--# this will -->
Since the servlet is a mango servlet, the following are at your disposal in any dsp servlet:
ServletResponse response; ServletRequest request;