You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@flex.apache.org by pe...@apache.org on 2013/07/24 21:25:34 UTC
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
Updated Branches:
refs/heads/develop c3f2a66b8 -> 016eabf7a
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 implement IChrome. Modified the IPanelModel to implement ITitleBarModel so that a TitleBar can share the Panel's model should it be included in a Panel; property changes to the Panel automatically forward to the TitleBar.
Project: http://git-wip-us.apache.org/repos/asf/flex-asjs/repo
Commit: http://git-wip-us.apache.org/repos/asf/flex-asjs/commit/016eabf7
Tree: http://git-wip-us.apache.org/repos/asf/flex-asjs/tree/016eabf7
Diff: http://git-wip-us.apache.org/repos/asf/flex-asjs/diff/016eabf7
Branch: refs/heads/develop
Commit: 016eabf7a664de0f6c7cd5cfa3237ceb771d6cde
Parents: c3f2a66
Author: Peter Ent <pe...@apache.org>
Authored: Wed Jul 24 15:24:56 2013 -0400
Committer: Peter Ent <pe...@apache.org>
Committed: Wed Jul 24 15:24:56 2013 -0400
----------------------------------------------------------------------
.../as/src/org/apache/flex/core/IPanelModel.as | 11 +-----
.../flex/html/staticControls/Container.as | 40 ++++++++++++++++----
.../flex/html/staticControls/ControlBar.as | 3 +-
.../apache/flex/html/staticControls/TitleBar.as | 3 +-
.../flex/html/staticControls/beads/PanelView.as | 8 +++-
.../html/staticControls/beads/SliderView.as | 9 -----
6 files changed, 44 insertions(+), 30 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/016eabf7/frameworks/as/src/org/apache/flex/core/IPanelModel.as
----------------------------------------------------------------------
diff --git a/frameworks/as/src/org/apache/flex/core/IPanelModel.as b/frameworks/as/src/org/apache/flex/core/IPanelModel.as
index 5abbe6d..24fac27 100644
--- a/frameworks/as/src/org/apache/flex/core/IPanelModel.as
+++ b/frameworks/as/src/org/apache/flex/core/IPanelModel.as
@@ -18,15 +18,8 @@
////////////////////////////////////////////////////////////////////////////////
package org.apache.flex.core
{
- public interface IPanelModel extends IBeadModel
+ public interface IPanelModel extends IBeadModel, ITitleBarModel
{
- function get title():String;
- function set title(value:String):void;
-
- function get htmlTitle():String;
- function set htmlTitle(value:String):void;
-
- function get showCloseButton():Boolean;
- function set showCloseButton(value:Boolean):void;
+
}
}
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/016eabf7/frameworks/as/src/org/apache/flex/html/staticControls/Container.as
----------------------------------------------------------------------
diff --git a/frameworks/as/src/org/apache/flex/html/staticControls/Container.as b/frameworks/as/src/org/apache/flex/html/staticControls/Container.as
index 8d7b2b7..05a59b1 100644
--- a/frameworks/as/src/org/apache/flex/html/staticControls/Container.as
+++ b/frameworks/as/src/org/apache/flex/html/staticControls/Container.as
@@ -21,6 +21,7 @@ package org.apache.flex.html.staticControls
import flash.display.DisplayObject;
import flash.display.DisplayObjectContainer;
+ import org.apache.flex.core.IChrome;
import org.apache.flex.core.IContainer;
import org.apache.flex.core.IUIBase;
import org.apache.flex.core.UIBase;
@@ -58,22 +59,45 @@ package org.apache.flex.html.staticControls
{
if (c is IUIBase)
{
- actualParent.addChild(IUIBase(c).element as DisplayObject);
- IUIBase(c).addedToParent();
+ if (c is IChrome ) {
+ addChild(IUIBase(c).element as DisplayObject);
+ IUIBase(c).addedToParent();
+ }
+ else {
+ actualParent.addChild(IUIBase(c).element as DisplayObject);
+ IUIBase(c).addedToParent();
+ }
}
- else
- actualParent.addChild(c as DisplayObject);
+ else {
+ if (c is IChrome) {
+ addChild(c as DisplayObject);
+ }
+ else {
+ actualParent.addChild(c as DisplayObject);
+ }
+ }
}
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);
+ }
+ }
}
override public function removeElement(c:Object):void
http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/016eabf7/frameworks/as/src/org/apache/flex/html/staticControls/ControlBar.as
----------------------------------------------------------------------
diff --git a/frameworks/as/src/org/apache/flex/html/staticControls/ControlBar.as b/frameworks/as/src/org/apache/flex/html/staticControls/ControlBar.as
index e805ff1..8f0a46b 100644
--- a/frameworks/as/src/org/apache/flex/html/staticControls/ControlBar.as
+++ b/frameworks/as/src/org/apache/flex/html/staticControls/ControlBar.as
@@ -20,10 +20,11 @@ package org.apache.flex.html.staticControls
{
import org.apache.flex.core.IBeadLayout;
+ import org.apache.flex.core.IChrome;
import org.apache.flex.core.IContainer;
import org.apache.flex.core.ValuesManager;
- public class ControlBar extends Container implements IContainer
+ public class ControlBar extends Container implements IContainer, IChrome
{
public function ControlBar()
{
http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/016eabf7/frameworks/as/src/org/apache/flex/html/staticControls/TitleBar.as
----------------------------------------------------------------------
diff --git a/frameworks/as/src/org/apache/flex/html/staticControls/TitleBar.as b/frameworks/as/src/org/apache/flex/html/staticControls/TitleBar.as
index c7419ef..cf1e584 100644
--- a/frameworks/as/src/org/apache/flex/html/staticControls/TitleBar.as
+++ b/frameworks/as/src/org/apache/flex/html/staticControls/TitleBar.as
@@ -22,12 +22,13 @@ package org.apache.flex.html.staticControls
import org.apache.flex.core.IBead;
import org.apache.flex.core.IBeadLayout;
+ import org.apache.flex.core.IChrome;
import org.apache.flex.core.ITitleBarModel;
import org.apache.flex.core.ValuesManager;
import org.apache.flex.events.Event;
import org.apache.flex.html.staticControls.Label;
- public class TitleBar extends Container
+ public class TitleBar extends Container implements IChrome
{
public function TitleBar()
{
http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/016eabf7/frameworks/as/src/org/apache/flex/html/staticControls/beads/PanelView.as
----------------------------------------------------------------------
diff --git a/frameworks/as/src/org/apache/flex/html/staticControls/beads/PanelView.as b/frameworks/as/src/org/apache/flex/html/staticControls/beads/PanelView.as
index 53c314c..4584b63 100644
--- a/frameworks/as/src/org/apache/flex/html/staticControls/beads/PanelView.as
+++ b/frameworks/as/src/org/apache/flex/html/staticControls/beads/PanelView.as
@@ -57,7 +57,11 @@ package org.apache.flex.html.staticControls.beads
super.strand = value;
_strand = value;
- Container(_strand).addChild(titleBar);
+ // replace the TitleBar's model with the Panel's model (it implements ITitleBarModel) so that
+ // any changes to values in the Panel's model that correspond values in the TitleBar will
+ // be picked up automatically by the TitleBar.
+ titleBar.model = Panel(_strand).model;
+ Container(_strand).addElement(titleBar);
var controlBarItems:Array = Panel(_strand).controlBar;
if( controlBarItems && controlBarItems.length > 0 ) {
@@ -67,7 +71,7 @@ package org.apache.flex.html.staticControls.beads
_controlBar.addElement(comp);
}
- Container(_strand).addChild(controlBar);
+ Container(_strand).addElement(controlBar);
}
IEventDispatcher(_strand).addEventListener("childrenAdded", changeHandler);
http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/016eabf7/frameworks/as/src/org/apache/flex/html/staticControls/beads/SliderView.as
----------------------------------------------------------------------
diff --git a/frameworks/as/src/org/apache/flex/html/staticControls/beads/SliderView.as b/frameworks/as/src/org/apache/flex/html/staticControls/beads/SliderView.as
index fd44591..a969c25 100644
--- a/frameworks/as/src/org/apache/flex/html/staticControls/beads/SliderView.as
+++ b/frameworks/as/src/org/apache/flex/html/staticControls/beads/SliderView.as
@@ -45,9 +45,6 @@ package org.apache.flex.html.staticControls.beads
{
_strand = value;
- bkg = new Sprite();
- UIBase(_strand).addChild(bkg);
-
_track = new Button();
Button(_track).addBead(new (ValuesManager.valuesImpl.getValue(_strand, "iTrackView")) as IBead);
@@ -83,7 +80,6 @@ package org.apache.flex.html.staticControls.beads
if( needsSizing ) sizeChangeHandler(null);
}
- private var bkg:Sprite;
private var _track:DisplayObject;
private var _thumb:DisplayObject;
@@ -102,11 +98,6 @@ package org.apache.flex.html.staticControls.beads
var w:Number = UIBase(_strand).width;
var h:Number = UIBase(_strand).height;
- bkg.graphics.clear();
- bkg.graphics.beginFill(0xFF8800);
- bkg.graphics.drawRect(0,0,w,h);
- bkg.graphics.endFill();
-
_thumb.width = 20;
_thumb.height = UIBase(_strand).height;
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
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
Posted by OmPrakash Muppirala <bi...@gmail.com>.
> 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