How To Dynamic Web Rendering?

[Adam D. Ruppe]

Jacob Carlborg wrote:
> But that way you would need to declare different types of Options
> structs all over the place?

Sometimes, but most functions are fine with regular argument lists,
to me, using enums for options where appropriate.

> I think there are other languages available that is far better than
> PHP that you could compare with instead. Ruby on Rails:

Come to think to fit, PHP's $_REQUEST() would have worked here too
and shaved off a couple lines.


Anyway, I've used Ruby before, but never Rails. The to_i and to_s
things are familiar.. me forgetting to write them caused many
problems in that project. I hate dynamic languages so much. That
Ruby project is what put the nail in the coffin.

I want to get an idea of how Rails works though, so see how well
my approaches stack up. But, aside from discussions like this one,
I haven't had a chance to get into it.

> This will try to find a Post with the given id and automatically
> converted the given value to an integer.

This is similar to how my database libs work. It actually lets
the database do the conversion though.


> I've been thinking for a while to try and create something
> similar as Rails' ActiveRecrod for D but every time I tried to do
> it turns out to work quite badly with a static type system.

Have you seen Piotr Szturmaj's Postgres code?

http://www.digitalmars.com/d/archives/digitalmars/D/learn/D2_postgresql_interface_-_Phobos2_23693.html#N23695

(there's more posts than that on it too if you search)

It might give you some ideas.


I went the other way; I don't mind writing SQL. (I always find
automatic mappings the other way to be inefficient and lacking
anyway.)


> As I said above, I don't see the big advantage if I have to use
> Variants all over the place .

The thing is it's not *all* over the place. There's a small area
where you use them, and you get the static type benefits everywhere
else.

Even with the variant areas, the static type system helps a little
bit. At least misspelled variable names are caught ahead of time by
the compiler.

> HAML, generates HTML - http://haml-lang.com/

Syntax and indenting aside, concepturally, that's similar to
how my DOM based code works.

auto profile = holder.addChild("div").className("profile");
auto left = profile.addChild("div").className("left column");

left.addChild("div", print_date).id("date");
left.addChild("div", current_user.address).id("address");


One big difference, semantically, is my code always escapes HTML
by default. Looks like haml uses &= for escaping, while = does
not.... so their homepage example is both incorrect and
open to XSS attacks!


(I offer two ways to write HTML: some functions take arguments
of type Html, like Table.appendRow:

table.appendRow(" ", Html(" "));

First column appears as literally  . Second column shows up
as a non breaking space.


But, mostly, if you want to mess with html, you use the innerHTML
property. It's a pain to use because outputting HTML is, 9 times
out of 10, wrong. Any template system that doesn't do this gets
a big point against it in my book, similarly to any database
library that makes mixing unescaped text in the easiest way...)



Anyway, their syntax is certainly brief. I can see the appeal in
that.


Curious though, how does haml handle forms? Looking through the
documentation, it doesn't seem to at all.

This is one of the nicest things about my DOM approach. You can
write the form in standard HTML, with default values written there
if you want, and the code will fill it in later.


> * SASS, generates CSS - http://sass-lang.com/ (I'm using the sass
> syntax and not the scss syntax)

Heh, I looked at that not long ago. I'm annoyed by CSS's lack of
nesting.

Not annoyed enough to introduce Ruby to the project, although I
rather like what they did here. I'll probably spin my own version
eventually.


> * CoffeeScript, generates JavaScript -

Eh, I thought about something along these lines, write some
of it, but I decided against going far with it.

There's two reasons:

a) If you're writing enough Javascript to make using a replacement
worth it, you're writing too much Javascript.

b) Javascript's biggest problem is that it's loosely and dynamically
typed, not that it's whitespace is ignored.


The auto-generated javascript to access my D code make using it
almost easy anyway

http://arsdnet.net/cgi-bin/apidemo/javascript

<button onclick="
  CoolApi.getABox('green').appendTo('playground');
" type="button">Get a green box</button>


Those are all basic examples. The idea is the server does most the
work, and Javascript simply plugs it in somewhere in the document -
the same way the page is built on the server side. appendTo's
argument can be a string for a trivial ID or an element as returned
by any of the built in browser functions (such as querySelector -
no need to load up a big piece of shit like jQuery to have that.)

The generic get() function does partial application so it's reusable
with other functions:

function fadeIn(parent, speed, html) { ... }

  CoolApi.getABox('green').get(fadeIn, this.parentNode, 10);


Since the server might return data, such might not always work.
That's where the format modifier comes in:

  CoolApi.getPeople(0).format('table').get(fadeIn, this.parentNode, 10);



Thus, javascript functions become fairly trivial and/or reusable,
so you don't have to deal with the language very much at all.



I also toyed with generating Javascript from D:

auto js = new ClientSideScript();

js.alert("Hello, world!");

js.var("wat") = 10;

js.alert(js.wat);


That kind of thing. Each method call to the js object builds a
code string inside it. D variables passed as arguments are
converted to Javascript literals and added to the code.

It actually kinda works, and I use it from time to time, but
only for little things. For the big, I don't think it's worth it.