flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OmPrakash Muppirala <bigosma...@gmail.com>
Subject Re: git commit: [flex-asjs] [refs/heads/develop] - Created IChrome interface which helps Container (and others in the future) identify children that should be treated as part of its chrome and kept distinct from content children. TitleBar and ControlBa...
Date Sat, 27 Jul 2013 02:06:57 GMT
On Fri, Jul 26, 2013 at 6:07 AM, Peter Ent <pent@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?


> Peter Ent
> Adobe Systems
> On 7/25/13 7:24 PM, "Alex Harui" <aharui@adobe.com> wrote:
> >
> >
> >On 7/25/13 3:32 PM, "OmPrakash Muppirala" <bigosmallm@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
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message