On Fri, Jul 26, 2013 at 6:07 AM, Peter Ent <p...@adobe.com> wrote: > 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. >
Yes, this is the kind of use case I was thinking of as well. And the flipside would also be true - you wont be able to add a chrome element as a regular child as well. > > 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. > It would be cumbersome to create custom components just for the sake of adding it as a chrome element. Compare that with just adding an object as a chrome element by just calling the addChromeElement, addChromeElementAt, etc. This would be so much cleaner. Also IChrome (looks like a Marker Interface) could lead to a subtle problem on the JS side. I have not been following the conversation on how to deal with Interfaces on the JS side. If we are planning on using 'duck typing', then we could run into issues with empty interfaces. Or am I missing something here? Thanks, Om > > 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 > > > >
