Our code base became largely infested with lots of JSTemplates (Javascript templates from trimpath.com) . We are using them for almost all view rendering now. JSTemplates are great but there are certain areas where they keep you wanting more. I'll try to put those issues into prespective here:
  • No remote includes!
    It would be great if one could just include a url in a template. But how could this be done? and the latency? these are questions that arise when speaking about such a feature
  • InnerHTML based!
    since they always return a string representing the rendred template the only reasonable way to use it is to set it as the innerhtml of some html node in your document. While this is a normal practice it has some drawbacks!
    • once you set the inner html of an object the control is immediately returned before the content is actually parsed and added to the dom tree
    • so if you want to access an element just after the template was rendered you might find it not yet available as a dom node!
    • While every benchmark on that issue says that setting innerhtml is the fastest thing on earth I believe that dom manipulation is much faster (the benchmarks count only the time needed to create the string and assign it to the node, not the parsing and rendering time!)
So here we have them! only two issues :)

The first is really not that important. It is the second one that bugs me! I think one solution would be to parse the rendered template yourself and create the nodes as you go and after you finish you append them to the container. But this would be much slower than the browser's implementation! An alternative would be an event that fires when the browser finishes the rendering! would that be possible? I think it could be done one way or another (like every render function returns a unique id of an object it appends to the end of the template. This is looked for on a timeout or interval method which would fire some callback if it is found).

Just some thoughts. Aside from that JSTemplates are ultra cool!

Comments (8)

I tried and failed to reproduce the problem. In a simple demo that I made, the DOM tree seems to be updated instantly. It's tested in ΙΕ 5 & 6, Firefox and Opera. Am I doing something wrong?

I just saw your demo. As i can see, you're not doing anything wrong, but I have a case here where things go wrong! I have a complex template which contains a text box. I use the values entered in the text box to filter the view contents on the fly. This envolves re-rendering the template AND the text box. I try to access the textbox to reassign the last filter value and give it focus. But I cant find it!. The same thing happens with other templates when setting objects as draggable or something.

I suppose that setting the value could be done in the rendering phase, but giving the focus is another thing. You definitely want the element itself to do this! That's one more template I would like to play with. :-)

I need to be able to extract the templates from the current framework as they are parts of bigger pictures and I dont have standalone unit tests for them! (yes, bad me!) I will try to setup a template that reproduces this effect over the weekend (my weekend, which starts tomorrow!)

Just a note. The rendering delay and the template_r issue can only be found in IE, FireFox is running perfectly.

I was able to reproduce my problem using your code. And it got me more puzzled now. Instead os spans i created textboxes. Then immediately after the assignment to innerHTML i set the focus to the first text box. It works the first time, but after clicking again on the button the focus is lost forever (not the case with firefox). The textbox is available though. but focus() is no longer functioning.

My earlier assumption of an immediate return of the control before complete rendering seems untrue now (the page is stuck until rendering finishes as i can see) but this issue led me to think that way.

btw. Opera is doing the exact opposite of IE. No focus() for the first time. But then focusing every other time!

I am not really surprised from this browser misbehaviour, as I've stumbled across similar focus-blur bugs more than once before. Unfortunately life isn't so sweat and we must garnishe are pretty code with all kinds of ungly tricks and workarounds to make it work. :-) However this one seems to be relatively harmless. The job does a simple zero seconds timeout, at least for the quadruplet of browsers I can test (IE5, IE6, FF, Opera), don't ask me what happens on Safari, IE/Mac or Konqueror!

var element = document.getElementById('item-1')
setTimeout(function() {element.focus()}, 0)

It's funny how a simple thing like that focus problem caused me a lot of work to ensure browser compatiability.
Thanx for the aid. I blamed the browser for a lot more than its fault!.