Ember.Component (block form): more than one outlet {{yield}}

I see that ember has a very nice mechanism for wrapping content in a component using the {{yield}} mechanism documented here.

So, to use the example in the documentation, I can have a blog-post component template defined like so:

<script type="text/x-handlebars" id="components/blog-post">
  <h1>{{title}}</h1>
  <div class="body">{{yield}}</div>
</script>

I can then embed blog-post into any other template using the form:

{{#blog-post title=title}}
  <p class="author">by {{author}}</p>
  {{body}}
{{/blog-post}}

My question is, can I specify two different {{yield}} outlets in the components template?

Something like this is possible via Named Outlets in Ember.Route#renderTemplate like so:

Handlebars:

<div class="toolbar">{{outlet toolbar}}</div>
<div class="sidebar">{{outlet sidebar}}</div>

JavaScript:

App.PostsRoute = Ember.Route.extend({
  renderTemplate: function() {
    this.render({ outlet: 'sidebar' });
  }
});

I'm not sure I can take this path for a component which will not know what route's template would be rendering it.

EDIT 1:

For the sake of clarity, I'm trying to implement the Android Swipe for Action Pattern as an Ember component.

So, I'd like users of this component to be able to specify two different templates:

A template for the normal list item, and
A template for the actions that are revealed when a swipe on (1) is detected.

I want to make this into a component, because quite a lot of javascript goes into handling the touch(start/move/end) events, while still managing smooth touch based scrolling of the list. Users would supply the two templates and this component would manage handling of touch events and necessary animations.

I've managed to get the component working in the block form, where the block's contents are treated like (1). The second template (2) is specified through a parameter (actionPartial below) which is the name of a partial template for the actions:

Component Handlebars Template: sfa-item.handlebars

<div {{bind-attr class=":sfa-item-actions shouldRevealActions:show" }}>
    {{partial actionPartial}}
</div>

<div {{bind-attr class=":sfa-item-details isDragging:dragging shouldRevealActions:moveout"}}>
    {{yield}}
</div>

Calling Handlebars Template:

{{#each response in controller}}
    <div class="list-group-item sf-mr-item">
        {{#sfa-item actionPartial="mr-item-action"}}
            <h5>{{response.name}}</h5>
        {{/sfa-item}}
    </div>
{{/each}}

Where the mr-item-action handlebars is defined like so:

mr-item-action.handlebars:

<div class="sf-mr-item-action">
    <button class="btn btn-lg btn-primary" {{action 'sfaClickedAction'}}>Edit</button>
    <button class="btn btn-lg btn-primary">Delete</button>
</div>

Problem is, actions from the user supplied partial, sfaClickedAction above, are not bubbled up from the component. A fact which is mentioned in the docs in para 4.

So, now I do not know how a user could capture actions that he defined in the supplied actions template. A component cannot catch those actions because it doesn't know about them either.

EDIT 2

I sprung a follow up question here

Solution

Since it is not possible to have two {{yield}} helpers within one component (how would the component know where one {{yield}}'s markup stops and the next one begins?) you may be able to approach this problem from a different direction.

Consider the pattern of nested components. Browsers do this already with great success. Take, for example, the <ul> and <li> components. A <ul> wants to take many bits of markup and render each one like a member of a list. In order to accomplish this, it forces you to separate your itemized markup into <li> tags. There are many other examples of this. <table>, <tbody>, <tr>, <td> is another good case.

I think you may have stumbled upon a case where you can implement this pattern. For example:

{{#sfa-item}}
  {{#first-thing}}
     ... some markup
  {{/first-thing}}

  {{#second-thing}}
    ... some other markup
  {{/second-thing}}
{{/sfa-item}}

Obviously first-thing and second-thing are terrible names for your specialized components that represent the things you'd want to wrap with your first and second templates. You get the idea.

Do be careful since the nested components won't have access to properties within the outer component. You'll have to bind values with both outer and inner components if they are needed in both.