I could go either way on this as well. There is one advantage I can think of that addChromeElement et al has over the IChrome interface.
Suppose you want to put a non-standard chrome component into a Container's chrome space? For example, you want a horizontal container of buttons. Using IChrome, you need to create a new component that implements IChrome so that the outer container's addElement will identify it as a piece of chrome. With addChromeElement, you can just use the container as-is and it would be placed into the outer container's chrome space. I'm sure it would not be as easy as that, but that's all I could think of being an advantage of one over the other. Personally, if I'm going to create a horizontal container of buttons, I'm 99% sure I'm going to make that a custom component so tacking on "implements IChrome" is no big deal. Peter Ent Adobe Systems On 7/25/13 7:24 PM, "Alex Harui" <aha...@adobe.com> wrote: > > >On 7/25/13 3:32 PM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote: >>> >>This would be a confusing API to the user, isn't it? >Funny, we debated a couple of ideas and I thought it would be less >confusing to not have both addElementAt and addChromeElementAt in the API >documentation and instead mark what is being added and handle it >internally in a single addElementAt call. My thinking was that the >component developer can learn to mark things, but the app developer won't >have to worry about that. > >>Can we split it up >>into two methods: addElementAt(o:Object,i:int) and >>addChromeElementAt(o:IChrome,i:int) ? >Sure, let's see if others have opinions and go with the majority. I >really could go either way. >> >>Thanks, >>Om >
