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. 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. -Alex
