pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Fri Dec 08, 2006 3:11 pm Post subject: 0.2B - DSP Reloaded |
|
|
Notes and Comments
I've had some time to think about DSP and how to best get it back on track, now that the tools needed to develop it have finally arrived.
As I've written about before, DSP is going to be largely a web-server infrastructure project, relying on Mango for all the heavy lifting. The remaining parts are as follows:
- Code generation
- Runtime binding (DDL)
- Library, request and settings caching
- Filesystem event management (handling file changes, etc)
These have already been prototyped under DSP 0.1B so with 0.2B. So most of the hard investigative work has already been done. Now, it's down to a finalized design and a solid implementation.
DSP Grammar
I took a tour of web languages today and found the following useful:
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
The paper outlines what is wrong with most templating solutions, and how they're rife for abuse, bad encapsulation and a host of other problems. In short, it stresses the need for proper View/Model separation in order for a true templating system to present itself. I tend to agree.
I've also gleaned some keen insights into a different mode of web programming thanks to my recent Trac hacking. More on that in a minute.
So due to all this new information, I've decided to put DSP under another revision. I shall try to make it more like a true templating language (View), while relying on the underlying code (Controller) to provide an abstract map of data (Model) to populate it.
DSP Grammar Changes
A good portion of the changes are inspired by the StringTemplate project. I could, in theory, port the entire project over to D (thanks to Enki), but I think DSP can serve up most of ST's capability w/o having to go in so many directions syntactically, and allow the use of WYSIWYG editors.
First off the DSP grammar is reduced to the following tags:
- Tag - used for creating re-usable "mini-templates"
- Include - aggregation of whole template files
- Apply - iteration and single-entity output, depending on use
- Var - ad-hoc var generation and assignment
Processing centers around a single map, which is passed as the 'context'. The context can have other maps, objects, constants and functions as valid values - the template runtime sorts out what to do with each.
Dollar-sign expressions ($xyz$) will be used in cases where an alias to apply is desired, without the syntactic noise. The contents of the expression can be a single path (x.y.z) into the context, arrays, strings, numeric constants, or a set of expressions denoted by [...].
Sets are unique in that they yield a new value each time they are accessed, and loop once they reach the end. So this makes them somewhat like Python generators. The only exception is when an index is used, in which case they behave like arrays.
The context can be set and manipulated by the <apply> and <tag> tags.
Example: Code: | <dsp:include template="x.dsp"/>
<dsp:tag name="xyz">
<div class="$zebra$">$context$</div>
</dsp:tag>
<dsp:var name="zebra" value="$['highlight','']$"/>
<div>
<dsp:apply each="foobar" indent="true" wrap="40" separator="\n">
<xyz class="$zebra$"/>
</dsp:apply>
</div>
|
The various attributes for the tags haven't been settled yet, but they are intended to have ST-style implications for iteration and output generation.
The input set is expected to be UTF-8, and not necessarily XML. By using tags as the DSP grammar, it folds in nicely with XML and HTML while allowing plain-text and JSON output to be accomplished just as easily.
The underpinnings of the template system rely on a runtime template infrastructure. The page handler simply gets the DSP engine, gets the template name and assets, loads the template, and passes the assets onto the template for rendering. The result is an output stream that flows directly into the response.
Code: |
//somewhere in a servlet
void handleRequest(IRequest req,IResponse response){
Map templateArgs;
String templateName;
DSPEngineContext dspEngine = cast(DSPEngineContext) this.applicationContext["DSPEngine"];
this.getTemplateAssets(templateArgs,templateName); // inout args for processing
auto template = dspEngine.loadTemplate(templateName); // template may be cached as pre-compiled
response.writeResponse(template.apply(templateArgs));
}
|
Header management, argument mangement, URL parsing and other server-request level tasks are all handled by the controller. The idea is to keep that stuff out of the template, as that's not what it's for.
All the model stuff in this design is intended to be left up to the developer - it's not the platform's job to impose what way to do this is best: RDBMS, flat-files, XML, Web services, system services, carrier pigeons, whatever... Web platforms have a history of doing this poorly, so it's not even in there.
However, I will build my DSP apps with DDBI, but that's another story. Perhaps there's a middle-of-the-road that can be reached for application-level and session-level config widgets, but I digress.
Implications
The implications of this mode for DSP are very profound. A typical DSP workspace will involve a series of .d as well as .dsp files that work together to compose an application.
DSP as a server technology will be de-coupled from the DSP templating language. I want this as a core feature because someone is going to want to port ST, Genshi, or any of the other top-notch templating systems out there. Someone else will want the no-nonsense anarchy of PHP. Others will want to code their servlets in raw D. Under this design, they all get to play. _________________ -- !Eric.t.Anderton at gmail |
|