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.