You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by OmPrakash Muppirala <bi...@gmail.com> on 2013/07/26 00:32:26 UTC
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 ControlBar impl
> override public function addElementAt(c:Object, index:int):void
> {
> if (c is IUIBase)
> {
> - actualParent.addChildAt(IUIBase(c).element as
> DisplayObject, index);
> - IUIBase(c).addedToParent();
> + if (c is IChrome) {
> + addChildAt(IUIBase(c).element as
> DisplayObject, index);
> + IUIBase(c).addedToParent();
> + }
> + else {
> + actualParent.addChildAt(IUIBase(c).element as
> DisplayObject, index);
> + IUIBase(c).addedToParent();
> + }
> }
> - else
> - actualParent.addChildAt(c as DisplayObject, index);
> + else {
> + if (c is IChrome) {
> + addChildAt(c as DisplayObject,
> index);
> + } else {
> + actualParent.addChildAt(c as DisplayObject, index);
> + }
> + }
> }
>
>
This would be a confusing API to the user, isn't it? Can we split it up
into two methods: addElementAt(o:Object,i:int) and
addChromeElementAt(o:IChrome,i:int) ?
Thanks,
Om
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...
Posted by Alex Harui <ah...@adobe.com>.
On 7/26/13 7:06 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>On Fri, Jul 26, 2013 at 6:07 AM, Peter Ent <pe...@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
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...
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Fri, Jul 26, 2013 at 6:07 AM, Peter Ent <pe...@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" <ah...@adobe.com> wrote:
>
> >
> >
> >On 7/25/13 3:32 PM, "OmPrakash Muppirala" <bi...@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
> >
>
>
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...
Posted by Peter Ent <pe...@adobe.com>.
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" <ah...@adobe.com> wrote:
>
>
>On 7/25/13 3:32 PM, "OmPrakash Muppirala" <bi...@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
>
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...
Posted by Alex Harui <ah...@adobe.com>.
On 7/25/13 3:32 PM, "OmPrakash Muppirala" <bi...@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