原文地址:
http://www.billdwhite.com/wordpress/?p=296
当我了解到Flex4那些对我诸多裨益的新特性后, 我便决定转而使用它。刚开始的时候,我试图利用在Flex前作中的认识和既有经验来快速进入状态。但很快我便发现有时即使面对一些显而易见的问题我也不得不求助于API文档或者运行一些示例程序来弄清这种问题的来龙去脉。根据以往经验,Flex3 的Halo在处理显示列表的时候隐藏了大量的实现细节和不良设计。然而一旦你开始使用新的Spark架构后,你就得以近距离的面对这些实现细节—Halo究竟在私底下干了什么,而且你会体会到为什么说Spark对于显示列表的处理更为“直白”。
“elements”是一个关键性的问题。elements是何物?它同child是否是一回事?刚开始的时候我曾武断的认为elements不过是children的另一种说法。通过反复梳理组件中所有的elements和children,我发觉在新的容器类(也包括一些经过改良的传统容器)某些似乎是理所当然应该具备的方法消失了。如果没有getElements(),我该如何获取elements的数目呢?我能否把getChildren() 的返回结果作为IVisualElement来对待。这令我十分纠结。
困扰的我于是开始认真阅读学习API文档,Flex的源码以及相关的博客文章。我也曾尝试解读一些博主发布的关于Flex4新特性的幻灯片。然而事实证明脱离讲解而孤立的看幻灯片作用相当有限。
最后,我拼凑了一些言简意赅的示例。这些示例将带领我了解有关elements的全新知识,告诉我那些在新的Spark容器背后发生的故事。
言归正传,首先从问题开始。问题一,“应该如何获得Spark 容器的全部elements?”我曾想当然的认为是通过一个类似Flex3中的getChildren() 的方法。然而实际上我们需要通过两个Property来达到这个目的:numElements & numChildren 。可以通过对numElements计数的循环语句配合getElementAt() 来实现遍历容器elements或特定访问。这种方式还比较直观。问题二,“element和child的区别何在?”,让我们来看看两者的差异。
语义上,element简单的说就是实现了IVisualElement接口的任意型别。child是指扩展了DisplayObject类的任意型别。判断某个组件是element还是child亦或两者都是的关键在于以下几点。UIComponent(所有Flex组件的基类:译者注)是由DisplayObject扩展而来,故所有UIComponent都是DisplayObject,也就是说UIComponent都是children。UIComponent同时也实现了IVisualElement接口,因而所有的UIComponent也可以被作为elements看待。但这并不是说所有的DisplayObjects(文中所言的DisplayObject一般指扩展于DisplayObject的子类,译者注)都是elements。容器中的DisplayObject对象是该无疑是容器的child。而只有当此DisplayObject对象同时也实现了IVisualElement接口时它才是容器的element。那么对容器而言,DisplayObject什么情况下是child,什么情况下又是element?通过示例来认识这个问题。
在首个示例中,我们使用了传统的Halo容器(这里我们使用的Panel)。Panel扩展与DisplayObject类,所以它可以使用addChild() 方法。进一步而言,Panel也是Container类的子类(mx.core.Container实现了IVisualElementContainer接口),它具有addElement() 方法。Container类的IVisualElementContainer接口实现只是基于显示列表API的门面,所以理论上它和同样实现了IVisualElementContainer接口的新式Spark容器具有相同的方法集合。
于是看起来我们可以任意添加children或element到容器中了。事实却不是这样。并非任意型别的element都能被添加(此处element泛指实现了IVisualElement接口的类)容器中。视觉元素(VisualElements)和图形元素(GraphicElements)有一些区别视觉元素(VisualElements)实现了IVisualElement接口,而图形元素(GraphicElements)实现的是IVisualElement接口的子接口IGraphicElement。IGraphicElement接口扩展的新特性为容器获取信息提供了额外渠道。某些elements(图形元素是其中之一)无法直接添加至Halo的Panel编译器会告知“这样的对象需事先包装进一个Group容器中”(实际上错误提示应该是在运行时出现,不关编译器什么事:译者注)。原因马上揭晓。
接下来的示例中,Panel中有若干个UIComponent,其中包括另一个Halo Panel,一个Spark Panel,几个Halo Button和几个Spark Button,以及一个包含有子组件的SkinnableContainer(注意: 包含于SkinnableContainer的组件是只属于SkinnableContainer的children,不是上级容器Panel的children)。所有组件都继承于DisplayObject,所以它们都是“children”。点击“show children”后可以清楚的了解这一点。进一步而言,所有的组件也都是“element”,因为UIComponent实现了IVisualElement接口。
看下一个示例。这次我们探讨的容器上Spark Group。与前Halo Panel类似,Group继承于DisplayObjectContainer,它具有addChild() 方法,它同时也实现了IVisualElement接口,所以我们可以用addElement() 方法来IVisualElement对象(elements)。而且Group也接受图形元素(GraphicElements),比如spark.primitives.Rect。要知道Rect是无法直接添加到Halo Panel中的。Group是怎么做到这一点的?原因就在于Group知道如何使用一种优化的方式来呈现图形元素(GraphicElements)。什么意思?往下读。
相对于典型的视觉元素(VisualElements),图形元素(GraphicElements)与容器的关系更为紧密。其关键在于IGraphicElement接口。上面曾经提到,这个扩展于IVisualElement的接口(此即图形元素(GraphicElements)可以通过Group的addElement() 方法来添加至其上的原因所在)。然而由于图形元素(GraphicElements)不是DisplayObject,所以他们在被“投映”到某个作为他父对象的DisplayObject前是无法被显示出来的。基于这个原因,当添加一个“Rectangle”到Group时,需要有DisplayObject来绘制这个Rectangle。更有效率一点的做法是Group尽可能的复用同一个DisplayObject来绘制多个图形元素(GraphicElements)。容器可以使用任何实现了ISharedDisplayObject接口的DisplayObject来绘制图形元素(GraphicElements)。第一个示例中的Halo Panel无法使用这种方式来绘制图形元素(GraphicElements),编译器会报错:“必须将其包装至一个合适的容器中”。而Group支持这种优化方式,所以能添加图形元素(GraphicElements)。
另外需要注意的一点是,有些图形元素(GraphicElements)的绘制由Group提供DisplayObject来完成,也有的是自行创建专属的DisplayObject来完成绘制。IGraphicElement接口甚至允许把对象自己创建的DisplayObject交由容器管理(换而言之就是以child形态添加的DisplayObject会以IGraphicElement的面貌来绘制自己)。
这意味着什么?这意味着在接下来的示例中,children的数目和elements的数目是不一样的。这个示例使用了与第一个示例相同的组件集合外,还增加了4个矩形图形元素(GraphicElements)。所有子对象皆为IVisualElement,但不是都可以称为children。几个矩形是图形元素(GraphicElements),它们并不继承于DisplayObject。Group不在乎这点,它知道添加DisplayObject来绘制这些图形元素(GraphicElements)。由于几个矩形的尺寸和角度有所不同,所以Group会创建2个新的DisplayObject来绘制这4个矩形。很酷吧!
现在来看示例三。我们用一个SkinnableContainer替换先前的Group。SkinnableContainer有和先前相同的子组件集,它还能利用Skin来增强视觉效果。Skin是SkinnableContainer唯一的child。SkinnableContainer的默认Skin类由一个矩形和一个被称为ContentGroup的Group组成。该Group的作用在于规划出容器内组件的添加位置。
这个示例证明了这样的事实,即使SkinnableContainer拥有10个elements,但它只有唯一的child:它自己的Skin。而且这个Skin也只有唯一的child:名为ContentGroup的Group组件。你也许会感到奇怪:为什么Skin的children不是2个:其一是ContentGroup,另一个是用于绘制作为边框的Rectangle的DisplayObject?这是因为Skin类继承自Group类,而Group只在它确实需要绘制其包容的图形元素(GraphicElements)时才会添加DisplayObject,目前的情况下不需要。Skin类具备直接在其上绘制Rect图形元素(GraphicElements)的能力,这归功于Skin类的上级类Group实现了ISharedDisplayObject接口。这意味着它在需要时能作为共享的DisplayObject来绘制图形元素(GraphicElements)。Skin负责管理用于呈现图形元素(GraphicElements)的DisplayObject,在当前示例中,Skin自己就是用于绘制的DisplayObject!如果你的自定义Skin中有其它的Rectangle,并将该Skin赋予SkinnableContainer,这种情况下Skin会判断是否需要更多的DisplayObject来绘制额外的Rectangle。这时你可能会发现在Skin的children列表中有更多的child。
值得注意的是,示例中SkinnableContainer,它的Skin以及Skin的ContentGroup这三者的element列表的数目是相同的。通过SkinnableContainer的源码可以知道,numElement的值实际上来源于与之对应的CurrentContentGroup的numElement。所以基本上对SkinnableContainer的elements的检索是被重定向到它的ContentGroup上的。SkinnableContainer的Skin也有类似行为。它继承于Group,Group的numElement的值取自其内部的mxmlContent属性。该属性是一个保存了Group可视内容children的数组。这两个属性与Panel的RawChildren属性十分相似,它用于返回Panel上的所有children而不是getChildren()方法返回的仅仅你添加到Panel上的那些。
通过以上阅读,也许起不到拨云见日的效果。但可以让你明白厘清以下七个类/接口的继承结构和相互关系是十分有必要的:
1. DisplayObject
2. UIComponent
3. Container
4. IVisualElement
5. IGraphicElement
6. IVisualElementContainer
7. ISharedDisplayObject
一旦你掌握它们之间的关系,你就能明白elements 和children的不同。可以肯定的是我在某些问题的认识和阐述上存在很多谬误之处。如果你发现了这样的问题望不吝赐教,在评论处写下您的正确观点吧。
更新:访问下面的链接可以获得关于本文探讨及其相关的主题的更多内容。
Gumbo DOM Tree API(关于本话题的详实细节)
关于了解组件的owner和parent之间差异的
极好的示例
分享到:
相关推荐
总结,Flex4的TabBar组件为开发者提供了强大的选项卡式界面设计工具,结合“Sample-Flex4-TabBar”示例,我们可以深入了解其工作原理和使用技巧,进一步提升Flex应用的用户体验。在实际开发中,应根据项目需求,充分...
flex-messaging-core-4.7.3.jar 最新版,下载了好长时间才下载下来,亲测可用!
本文将围绕“Forex-Flex-EA-V4.91”这一特定的EA,以及它如何结合经典“海龟交易策略”在MetaTrader 4(MT4)平台上运行,进行深入探讨。 Forex-Flex-EA-V4.91是一款专为MT4设计的智能交易系统,其核心在于灵活适应...
Flex4是Adobe公司开发的一款功能强大的RIA(富互联网应用)开发框架。它是Flex3的继任者,带来了巨大的...通过这份文档,开发者们可以在一天之内对Flex4有一个全面的了解,并知道如何在遇到问题时去寻找更深入的资源。
在flex-messaging-core.jar中,包含了一些关键组件和接口,例如: 1. **MessageBroker**: 这是Flex消息传递系统的中心,它管理消息的路由,调度和处理。MessageBroker实例化并配置了各种服务,如HTTP、HTTPS、RTMP...
Flex SVN--1.5.5版本Flex SVN--1.5.5版本Flex SVN--1.5.5版本Flex SVN--1.5.5版本Flex SVN--1.5.5版本Flex SVN--1.5.5版本Flex SVN--1.5.5版本
3. **flex-messaging-common.jar**:包含了Flex Messaging框架的一些通用类和接口,如消息代理、消息头和消息体的定义,以及错误处理和安全相关类。这些组件构成了Flex与服务器间消息交换的基础结构。 4. **flex-...
为了正确使用这个接口,用户可能需要了解如何加载和使用这些文件,以及它们如何与MATLAB环境配合工作。 总结来说,"matlab开发-Flex0201DCorrelatorInterface"是一个基于MATLAB的GUI应用,用于控制和分析Flex02-01D...
让我们深入探讨Flex Messaging的核心概念、功能以及4.7.3版本可能带来的改进。 Flex Messaging主要由以下组件构成: 1. ** BlazeDS**:BlazeDS是Adobe官方提供的开源服务器端组件,它为Flex应用提供了与Java后端...
1. **源代码**:压缩包内的"flex-2.6.4"目录应该包含了Flex的所有源代码文件,包括主程序、库、测试用例、示例和文档等。 2. **主程序**:主程序文件,如`flex.c`和`flex.h`,这些文件用于构建Flex词法分析器生成...
- `flex`:是`flex-grow`, `flex-shrink`和`flex-basis`的简写形式。 - `align-self`:允许单个Flex项独立设置其在交叉轴上的对齐方式,覆盖容器的`align-items`属性。 5. **Flex容器属性**:用于控制整个Flex...
Flex blazeds-spring Flex blazeds-spring Flex blazeds-spring Flex blazeds-spring Flex blazeds-spring Flex blazeds-spring
在Spring Flex 1.5.0.M2中,核心组件`spring-flex-1.5.0.M2.jar`扮演了关键角色,它是Spring和Flex集成的核心库,提供了诸如消息代理、配置支持和Spring服务代理等功能。这个库使得Flex客户端可以轻松地调用Spring...
在使用flex-iframe-1.4.6时,开发者需要了解如何将库导入到他们的Flex项目中,这通常涉及到添加库的SWC文件到构建路径或者通过MXML或ActionScript代码引用库中的类。同时,理解如何使用提供的API来创建、配置和控制...
在这个“flex------组件-----数据可视化”主题中,我们将探讨Flex如何帮助开发者创建交互式的数据图表和可视化效果。 Flex框架提供了一套强大的组件库,其中包括用于数据可视化的类和库。这些组件使得开发人员能够...
flex-messaging-core jar包
- `justify-content`:定义主轴上的对齐方式,如`flex-start`(靠左)、`flex-end`(靠右)、`center`(居中)、`space-between`(两端对齐,项目之间等距)和`space-around`(每个项目两侧的间隔相等)。...
《S2Flex2-1.1.0:Seasar2框架与Flex交互的深度解析》 在现代Web应用开发中,交互性和用户体验是至关...通过深入理解和熟练掌握S2Flex2,开发者可以构建出功能强大且用户体验优秀的Web应用程序,提升项目的整体价值。
flex-messaging-common