On 27/07/2015 6:10 p.m., Sebastiaan Koppe wrote:
On Monday, 27 July 2015 at 04:11:50 UTC, Rikki Cattermole wrote:
What I currently have is code templates as follows:
<?lua
echo("<p>" .. consumeNextText() .. "</p>")
?>
Hi there, this is some text!
Woopity doo.
<?lua
include_text("<?lua echo(\"boo\") ?>")
?>
So it would output something like:
<p>
Hi there, this is some text!
Woopity doo.
</p>boo
The languages supported would have to be known and configured at
compile time. But theoretically other languages such as Squirrel and
PHP should work.
D on the other hand, would be ugh hard.
I will be supporting the ability to pass in e.g. data models and even
query them. Thanks to reflection that I've added since Cmsed.
I don't think it makes sense doing any page rendering in D, there are
plenty of good tools that you don't want to compete with.
For instance, for rendering pages I would rather front the D backend
with some (stateless) node app that fetches the data from the D backend
and uses something like React to render server/client side. If the D
backend could implement the upcoming GraphQL that would be awesome.
It has the benefit that a) the frontend-end devs still get their
familiar language, tools and libraries; and b) that all the real stuff
happens in D.
But I thought this was about Web Services Applications? Which I assume
to be the outer container/process manager that allows services to be
registered, re-loaded, routed, etc.
Most people will want to write web applications not web services,
although they are _almost_ one in the same thing.
So, I've got to take that into account. Although nobody will force you
to use it.
