D in accounting program

[Adam Ruppe]

Graham Fawcett asked:
> Can I ask how you handled HTML templating?

Rolled my own. I started with a DOM implementation and added
templating stuff on top of it (my original
idea was to be able to copy/paste some of the D code into Javascript
with minimal changes - change auto to var, and see it work. I
didn't end up using that in practice though.)

The HTML part has minimal template stuff. You can put in a variable,
a couple special tags, and then it recognizes some attributes. That's
all - everything else is done on the code side or in CSS.

Basic example -

Welcome: <span>{$username}</span>

Then in D:

document.vars["username"] = user.name;


The TemplatedDocument class overrides the basic DOM Document's toString to do a
replacement of all those vars. Like this:

foreach(k, v; vars)
   str = str.replace(k, htmlEntitiesEncode(v));


(Putting HTML in a var is impossible. I don't see why you'd want
that in a template system anyway, it just seems to spell trouble.)


What about loops? I don't think they really belong in a template
either, in most situations. Instead I use a special tag or an
ID.


Choose a mailing list: <select><optionlist from="mailing_lists" /></select>


Or extending an existing tag:

<table id="user-listing"> [snip] </table>

And that's just filled in by code that looks like this:

auto ul = cast(Table) document.getElementById("user-listing");
assert(ul !is null);

foreach(user; getUsers(mysql)) {
    ul.appendRow(
       new Link("users?id=" ~ to!string(user.id), to!string(user.id)),
       user.name, user.linksClicked, etc, etc);
}

(Table.appendRow is a variadic template. I quickly found the typical DOM from
javascript to  be a pain in the ass and extended it in various ways)


You might argue this kind of thing violates the strict view separation, since some
of the output is obviously in the code but
I've grown to like it this way and haven't had any problems in
practice.

(Besides, it kicks the crap out of the Smarty template thing used
in its PHP predecessor. It had {php} actual page logic here! {/php}
in its crappy worthless templates!)


Other things like table striping are just done with css classes.

<table class="striped"></table>

Is processed in the D side like so:

bool odd = true;
foreach(e; document.getElementBySelector("table.striped > tbody > tr")) {
    if(odd)
        e.addClass("odd");
    odd = !odd;
}


Now the CSS just does:

table.striped > tbody > tr.odd { background-color: whatever; }


The visual stuff is completely in the control of the html/css and
the D just helps translate non-standard (or standard, but poorly
supported) decorations into standard decorations the browsers can
reliably handle.

Smarty templates would have done that by pushing the loop on to
the template, but IMO that's the wrong level. I just let them decorate
it and let the code fix it up well enough that standard css can
finish the job.


> Do you have any issues with long-running processes (memory
> exhaustion, etc.)? Or are you using short-lived processes?

This app is all short lived processes - classic CGI. Another
program of mine though, the BugPanel

http://arsdnet.net.arsdnet.net:8080/

(feel free to mess around with that - the semi-transparent bar
at the top and the links within are the bugpanel UI, added on
top of my homepage)

Is a long lived D process - it is a custom written HTTP proxy
that modifies requests and responses that pass through it, and
stores logs internally for easy reference later all in memory
(note the app is incomplete, but good enough to be of some use
already).

I use it to show in-development versions of sites to clients
and leave it running all the time. It's gone months without
any memory or stability issues, except those caused by my own
programming bugs.