How D may replace PHP & ASPX on the Web!!!

[Adam D. Ruppe]

Just being brief here, but something web.d can actually do right
now that might be cool is plugging in modules to build your site.

====
import arsd.web;

import some_blog_module;
import some_forum_module;

class MySite : ApiProvider {
     alias SomeBlogModule blog;
     alias SomeForumModule forum;
     alias _sitemap sitemap;
     Document _defaultPage() { redirect("sitemap"); return new Document; }
}
mixin FancyMain!MySite;
====

If some_x_module existed, that would compile and run a site with:

/ -> redirect to /sitemap -> which is an automatically generate
tree of links of all site functions.

/forum -> the Forum object
/blog -> the Blog object


Those sub-objects can be completely independent, and still
integrate into your site with ease!


I actually fairly hate web services. The whole idea strikes me
as rather blarghy; my data is mine, and I really don't want you
to have it.

But, the main alternative is downloading some app then spending
hours trying to integrate it into the rest of your site.

Ever tried to build a coherent site out of WordPress, PHPBB,
some other thing and custom code on top of it? I have. Pain in my
ass, even if I'm willing to take some shortcuts.

Each one has their own login function. Each has their own styles
and template systems. Each has their own user database. And, of
course, each has their own code that can't be brought together.
Try including a Wordpress file in phpbb. You'll wanna slit your
wrists.



The beauty of the web.d approach here is that those modules
are now brought into your class, with the magic of alias.

That means they share a number of fundamental functions!


Providing a _getGenericContainer on the outer level can apply
to those inner classes. Your _postProcess is run even on the
inner class methods.

What that means is styling them is fairly trivial - it automatically
puts the content inside the skeleton you provide, and your
modifications after-the-fact are still done.

(_postProcess() can be thought of a way of a server side
alternative unobstructive javascript - it presents you with the
final DOM tree and you can modify it as you see fit before the
output is written.

_getGenericContainer is the starting point - when building a
final document, it calls that to get a reference to a specific
place in your HTML template as to where to put the main content.)



If that isn't enough, you can still use inheritance to override
methods in the provided classes, or to add more. Or, you can
call their methods directly. No need to mess with some php plugin
to auto post to the forum, just call forum.makePost() directly.



One question comes to mind: what if you need to add configuration
to those modules? Can't do that with alias.... or can you? If
the modules were templates...

alias SomeBlogModule!(config, info) blog;

that should work right now. One point of power might be to pass
typeof(this) as a template arg, so it can access your top level
class' special methods. Using template constraints, it can let
you know what you need to implement for best results. Some good
interfaces might be getLoggedInUser() and getDatabaseHandle() to
make integration that much easier.


Some questions remain: what about stylesheets? If you write
websites like I do, the .css file is a necessity. Adding it in
the postProcess section could work. Or, something I've really
liked doing recently is this:

======
void _catchAll(string path) {
     if(path == "/style.css") {
           cgi.setResponseContentType("text/css");
           cgi.setCache(true); // unlimited client side caching
           cgi.write(import("style.css"));
           return;
     }
     super._catchAll(path);
}
====


That is - serve up the css file from inside the application. It
makes deployment slightly easier, and I can concatenate data
on the server if need be:

string style = import("style.css");
version(special)
    style ~= import("other-style.css");
cgi.write(style);


This concatenation is what you can do with child objects.
If ApiProvider had a style() method, you could call it for each
child.

Then, of course, overriding it or providing another stylesheet
later on or with greater specificity gives you full control,
along with sensible defaults.

I think I'll add this as a standard thing soon. (like how
"functions.js" is built in to web.d to provide the JS api. Just
link to that name from your template html and you can use all
your D functions via AJAX type calls.)


All we've gotta do is write up some of these modules and see if
the idea works as well in practice as I hope!