There are a few strategies you can use for this. We had a similar problem to solve with our TreeViewController, which renders nodes and sublists based on nested data, and was built long before can.Component became available.
1. The old-style solution is to put code that attaches a new Resources control on each tab in the EJS view, using inline script. Using the can/control/plugin plugin and Mustache, we would do
- <li {{data 'options'}} {{ (el) -> el.ggrc_controllers_tree_view(el.data("options")) }}>
It's almost the same in your example, with EJS, and maybe without can/control/plugin:
- <div class="resources" <%= (el) -> new Resources(el, { /* some options */ }); %> > </div>
This is sort of a hack. It increases the coupling between Views and Controllers, and probably shouldn't be used now that there are better options available.
You might want to consider upgrading to CanJS 2.0.x and trying one of these options:
2. Create an EJS helper function that turns "inserted" events (which do not bubble) into an event that bubbles, and listen on ".resources <that event name>" instead of "{tabs} length" -- "inserted" events are a newer feature in CanJS that we couldn't take advantage of when we were using the hack from point 1. This would be the easiest and fastest way to get you to where you want to be. The idea here is that live-binding is taking care of making new resources divs as tabs are added, and you listen to when those new divs are added to the DOM. Here's a fiddle demonstrating this technique: http://jsfiddle.net/air_hadoken/CjeYL/3/
Yes, you probably could just do the control attachment directly in the callback, but I find this to be more reusable.
3. Make a can.Component for resources and use the custom tag that spawns the component in your template. You can in theory add Controls in to content you add with the template, as shown in http://jsfiddle.net/air_hadoken/CjeYL/4/ , but you could just drop the Control and make Resource a component instead.