References to dom nodes generated by a helper

[timoxley]

I'd like to be able to generate dom nodes in my helper functions, simply so I can refer to those nodes later (e.g. to update them).

With the current restriction of helpers returning strings, I have no way to keep track of the dom nodes that are generated (other than by finding them later via id/class).

Do you have any tricks up your sleeve to get around this?

[ticaboo]

Hi Tim,

Sounds like this would go counter the logic-less philosophy. Perhaps post a concrete example? That would make it easier to suggest a lateral solution.

Henry

[timoxley]

I'm trying to wrap a tool that generates dom nodes with event listeners attached (I'm generating Backbone Views to be exact).

I want to be able to do:

  {{view "My.View"}}

and have that an instance of the Backbone view instantiated and have it's dom element injected into the dom with all of the event listeners in the view attached.

My current workaround is to have the helper inject a string that is a placeholder div, and have the placeholder replaced with the actual dom node generated by Backbone inside a setTimeout. While clearly a terribly hacky approach, it seems to work well.

If handlebars can optionally return references to dom nodes, it could be used to generate dynamic components. IMO this isn't adding logic into the template, it's just adding a 'smart' object to the dom.

[ticaboo]

Sounds like a road I went down once, albeit with different technologies. It didn't end great.

Also sounds like event binding ala knockout js. Have you looked at the various libraries for event binding with backbone? See https://github.com/documentcloud/backbone/wiki/Extensions,-Plugins,-Resources

I could suggest less hacky work around, but I actually that wouldn't be doing you a favour. Consider how the heck you are going to test/debug/maintain complexity going through templating?

Step back, think about the partitioning of your layers. Keep your views logic-less, your controllers thin as rakes and your models fat (but orderly).

H

[timoxley]

Ooh. What's your less hacky workaround?

The idea is to decouple parent views from their child views. The only link they have to each other is via the template. This means the parent becomes reusable: I don't have to adjust any rendering logic to have the parent view work with a different configuration of child views.

I'm actually taking the concept of "instantiate child Views from inside the template", directly from Ember, so if there's a flaw/issue in my approach here, it's possible that flaw also exists within Ember. Also possible I've missed something.

Testing is actually much cleaner due to no hard dependencies on the child views.

[eastridge]

Check out http://walmartlabs.github.com/thorax/#templating/view-view-view-name-attributes

The basic strategy in use here is to have a helper generate a div with a unique id of some kind, then as soon as the output of the template is attached to the DOM, replace that div with the element. It may sound hacky but it's reliable and scales.

[timoxley]

@beastridge yeah that's pretty much exactly what I'm doing though, thorax looks a lot more sophisticated (read: I couldn't grok exactly what was going on with a quick glace at the code). I am keen to try it out on my next project though.

[wagenet]

I don't think this is something that is going to be built into Handlebars. Ember has it's own code to handle this scenario. You'd want to set up something similar for use with Backbone.

[timoxley]

That's a shame, though I would be interested in the rationale. Coupling handlebars to the dom does seem out of scope, but since handlebars' primary (only?) use case is generating html, perhaps (optional) tighter integration with the dom would make sense. Just curious.

[wagenet]

@timoxley Handlebars only renders strings. It doesn't care about anything beyond that.

[timoxley]

Right. KISS. Fair call.