How To Dynamic Web Rendering?

Tue May 17 13:12:16 PDT 2011

Nick Sabalausky wrote:
> There should be an overload of getElementById that's defined like
> this:

Aye, I've been thinking about that for a while, but could never think
of a name I like (yeah, petty reason).

I've just trained myself to use assert to avoid the null pointers.

> Or maybe call it requireElementById.

That's a pretty good idea.

> Or, of course, if it's in a class and can't have templated members

It is a class, but the requireElementById (and it's counterpart,
requireSelector*) could always be final. I can't think of a reason
to override them anyway, especially since the underlying
implementation in getElementById is still overridable anyway.

(same reason why I'm ok with opDispatch - it just forwards to
set/getAttribute)

This is definitely good though, it has the best cost/benefit ratio
of things on the todo list. I take your name!

side note::

* After looking at haml yesterday, I'm tempted to do a nothrow
requireSelector. Again, can't think of a name.

But what it'd do is try to get the first element that matches the
css syntax. If it's not there, it starts from the best path that
does exist and creates the rest.

So if you have a blank element <html></html> and you do:

makeSelector("html"); // that root node is returned since it exists

makeSelector("div > span.date");

That doesn't exist, so it does a

return document.root.addChild("div").addChild("span").className("date");

Though, I don't think I have a use for it; it'd be harder to use
than just writing the html yourself in the template file.

:: end side note

> What happens if you want to (or try to) put the same data in more
> than one place?

Use a class or a custom attribute instead of id, then loop through
the collection:

foreach(e; document.getElementsBySelector("div.announcements"))
    addAnnouncements(e);

Sometimes I do that even when there's just one because the return
value there is guaranteed to never include null.

> Which opens the possibility, if you're not doing this already, for
> the HTML importing (and maybe the DOM, too, or at least
> serializing the DOM at the end) to detect and error on multiple
> instances of the same "id=".

No, it doesn't check that right now. It treats id as just another
attribute for the most part. (getElementById returns the first one
it sees in the tree.)

It always could, but I haven't felt it's worth the time yet.