@dkf said in Legacy C++ in web, server-side: keeping it simple:
Do you want any validation prior to submission? If not, you can use a plain form (plus some CSS) and things will be fairly easy.
I forgot to tell that a zoomable and pannable plot (when possible) is also a requirement, so JavaScript is unavoidable. This part is even already complete, but now I have to think about the backend (which, for now, just prints a constant JSON string if you run it). I even used <input pattern="...">
and some really ugly regexps to do validation without scripting.
But do give errors if there's an unexpected parameter, and do say what the unexpected parameter is in the error message (while listing what parameters are expected).
And it's much easier to implement than total DRY. Thanks for the idea.
@dkf said in Legacy C++ in web, server-side: keeping it simple:
Also, why the fuck do you need to do this in C++?
"So that everyone involved understands the code." I may be able to make this requirement go away.
@Unperverted-Vixen said in Legacy C++ in web, server-side: keeping it simple:
I don't suppose your model is exposed via COM?
Unfortunately, no, it's just a DLL with a C++ header file that is almost syntactically correct C (it uses class
in forward declarations for opaque pointers).
COM + reflection could be a cool idea to consider, though.
@dkf said in Legacy C++ in web, server-side: keeping it simple:
You could put a lot of work into trying to unify the variable definitions into one place, but for a one-off job of this size then just cut-n-pasting them from somewhere will do well enough.
@Gąska said in Legacy C++ in web, server-side: keeping it simple:
Are you going to maintain it for more than two months? If not, doing things the right way might not be worth it.
Thanks. It is possible that everyone is going to forget about the project after we get it running once.
If you can run external programs that aren't in C++, then the CGI part might be done as a thin wrapper only and you can do actual work in whatever you want, passing data between programs as JSON to stdin or whatever else you want.
@dkf had a similar suggestion back when I brought this up in WTF Bites. This also has the advantage of the address space belonging to potentially buggy model being short-lived. Alas, DRY goes out of the window - the form, the wrapper and the back-end would all have to agree about parameter/JSON field names - but, as you said, doint it right might not be as important as I think it is.
Now I am leaning towards writing most of the code in a higher-level language with a template engine and form validation already written by someone else and running the model as a subprocess, with JSON over stdin
/stdout
as IPC mechanism.
Filed under: Visit TDWTF to procrastinate every day. Ask a serious question once and find oneself procrastinating instead of visiting TDWTF to read the answers...