I need to produce a web interface for a physical model with lots of parameters. No bells and whistles needed, just gather the user's input from a giant form (all 26 parameters are important; most can retain their default values), draw a plot and allow TSV export.
Unfortunately, there's an external requirement to write it in C++, specifically, the kind of C++ understood by MSVC 10 (so no auto
, unique_ptr
or lambdas... perhaps that's a blessing). Also, CGI. There is no clear idea what kind of machine it is going to run on; probably the old lab server with Windows Server 2008 and Apache installed on it. I may get the C++ requirement dropped if noone except me would ever have to look at or touch the non-C++ part and the runtime would be easy to install and manage on Windows Server 2008. (There's a copy of PHP5 for Dummies lying around in the lab. I don't want to disturb it.)
This is doable in a simple way: have the binary parse and validate the parameters (cgic provides very convenient functions for that and is still maintained), calculate the model data and output JSON; perform the plotting and TSV export on the client side via JavaScript (using excellent dygraphs and URL.createObjectURL(new Blob(data_as_text))
, respectively).
Unfortunately, I would personally like it to also work without JavaScript (and since I'm just a PhD student, I can get away with adding to the requirements as long as the job eventually gets done) and on a POSIX system. Plotting is a solved problem (I have a 200-line class that outputs enough of an SVG plot for my needs), but now I need to generate HTML. This probably means a templating library, lest I go crazy.
Existing template libraries require C++ >= 11 or Qt, are complicated to build on Windows or dead. So it goes.
But wait, even if I don't want to render stuff server-side, DRY principle requires me to store things like form parameter names in one place only to guarantee one-to-one matching between POST parameters and model variables. (It is too easy to make a typo in one of the 26 parameter names, and we might add more. I want to catch them at compile time or, better, make them impossible to happen.) I can imagine the generation being done statically (same code generates form.html
and parse_form.cpp
from a single description), but dynamic generation seems less crazy. Something like CGI::FormBuilder but not for Perl?
Now I feel the onset of not-invented-here syndrome; it tells me I might as well avoid having dependencies and just write myself a simple string substitution function and another simple function that would parse form parameters, store them by given references and maybe output HTML (with the help from substitution function above) if it is needed. But that never goes well, does it? I am surely not Sean T. Barrett, Roberto Ierusalimschy or D. Richard Hipp to pull off implementing such a thick layer in the stack of dependencies myself. Either way, the result with its layers of processing and lots of code written by fallible humans would compare very unfavourably to the original idea of thin JSON-spewing executable in terms of keeping it simple.
Or perhaps I should embed Lua and do as much logic and string-wrestling as possible in it, leaving C++ only for the model, but that brings the DRY problem back, since then I'd have to match table elements on Lua side to struct elements on C++ side, and there would be no way to prevent typos at compile time, as it usually happens in dynamic languages. Also, this would still feel like over-engineering. Perhaps static HTML/code generation is the way to go: I could do it once in the language of my choice and check in the results. No, someone would want to change them and easy re-generation would be impossible.
I'm probably overthinking everything. Opinions?