change suggestion for new Multi-slot transclusion feature

[epeleg]

Hi,
I want to suggest that the structure of the transclude object value shown in the example for https://docs.angularjs.org/api/ng/directive/ngTransclude (v1.5.0-build.4414 (snapshot)) would be the other way around.
i.e. instead of

 transclude: {
        'paneTitle': '?title',
        'paneBody': 'body'
      },

it should be (IMHO)

 transclude: {
         'title': '?paneTitle'
         'body': 'paneBody'
      },

This would be more consistant with similar maps such as those used in isolated scope and bindToController in the sense that the property name should be the internal element to which the binding happens (the value of the ng-transclude attribute in the template in our case) and the value should say how to resolve it from the "outside".

see also http://stackoverflow.com/questions/22079587/angularjs-transcluding-multiple-sub-elements-in-a-single-angular-directive/34063645#34063645 where I actually suggested that such a feature would be helpful.

[Narretz]

@petebacondarwin What do you think about this?

[petebacondarwin]

Reasonable. Let's consider this

[epeleg]

Thanks

[epeleg]

I looked at the updated documentation where is says:
'footer': '?pane-footer'
and it still looks somewhat wrong...

In a scope object if the attribute name was some-attribute the scope object would say 'localname':'@someAttrbute"

I would expect the transclusion object to follow the same syntax.

i.e.
IMHO the example should read:
'footer': '?paneFooter'
for the corresponding pane-footer element.
and not use '?pane-footer' as the dash format is used in the HTML side and not the JS side.

[petebacondarwin]

We need to clarify this in the docs but we decided that in the case of the transclusion map, the values are actually element selectors, to allow us to consider supporting more complex selectors in the future. Therefore you must provide the exact name of the element rather than a "canonical" form.

[epeleg]

Although this does make sense in a way, the same logic would also apply from the scope object. i.e. why use scope:{'localName':'@myAttribute'} not use scope:{'localName':'@my-attribute'} ?

IMHO It would be a better choice for now to be consistent and use the "canonical" form as in scope and only at a later stage relax this requirement and allow using a more complex syntax on all such maps (transclusion, scope & bindToController).

b.t.w - even now - allowing a ? at the beginning of the value makes it not to be "an actual element selector".

one last point/question - I what scenario would you expect a more powerful selector to be used in the transclusion map? Do you think that something stronger then a sub element name would ever be used?

Thanks for a great job and for listening.

[petebacondarwin]

In the original prototypes of this feature, people were able to match on all kinds of CSS selector, such as .some-class or my-element > *. I could foresee that this might be a requirement in the future and it seems a shame to have to make a breaking change later to allow this.

That being said I guess that we could probably work around that by, say, checking for uppercase characters in the matcher, which would indicate a canonical form.

So I guess we can indeed revert that aspect of this PR and allow canonical form.