On Fri, Jul 26, 2013 at 9:34 PM, Alex Harui <aha...@adobe.com> wrote:
> > > On 7/26/13 7:06 PM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote: > > >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. > Another option was to use flags like Windows does (WS_CHILD) etc. Then > you can alter the marking at runtime, but you don't need duplicate APIs. > What are your thoughts on that? > > > > > >> > >> 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? > I'm not sure what we'll end up doing for interfaces on JS. It looks like > some compiler code expects to list interfaces in an $implements property > object. > Can someone shine some light on this? Erik, Michael? > > But one other reason we started with a single addXXX API set and markers > (maybe we should have used flags) was because I didn't want to duplicate > the different stacks of addXXX APIs at the top-level root on the AS side. > Today SystemManager makes a set for cursorChildren, toolTipChildren, > popUpChildren and everything else. First of all, that's wasteful for apps > that don't use those features (like mobile), second, there's no way to add > another set, at least not easily, and third, there isn't guaranteed to be > a wrapper around Application in FlexJS since it is so small it doesn't > have to have a preloader. So I'm leaning towards markers or flags so that > we don't have to bake in that contract up front. A PopUpManager, > CursorManager, or ToolTipManager would watch for things being added and > figure out if they are responsible for it and then manage the z-order > appropriately. > > At this point, I'm liking flags better, but I'm still not decided. > > Sounds like a good compromise. Although I am not sure if it solves the issue of index management. I guess it would look like this: addElementAt(o:Object, index:int, flags:uint) Ex. container.addElementAt(obj, 3, CONTAINER_ELEMENT_TYPES.CHROME_ELEMENT); container.addElementAt(obj, 6, CONTAINER_ELEMENT_TYPES.CHILD_ELEMENT); The user still needs to keep track of the index length chrome elements and regular elements. I like how the spark Panel has a controlBarContent property to which we can assign an array display objects directly. Similarly, we could have a Container.chromeElements object to which chrome elements could be added directly? > -Alex > >
