Gumbo Group - Functional and Design Specification
Glossary
graphic element - A graphical item like a Rectangle, Path, or Bitmap. This element may not be a subclass of DisplayObject.
visual element - A visual item. This can be a component or a graphic element.
data element - A non-visual item like a String, Number, XMLNode, etc.
Summary and Background
Group is the simple container base class in Gumbo. It is designed to be both flexible and lightweight.
Groups can contain both visual and data elements. Layout is handled by a separate layout object.
Halo manages layout and containment differently in Container, ListBase, and individual components. In Gumbo, the Group class is used in all of these places, providing a single consistent mechanism for all layout in an application.
There are several key differences between the Group class and the Halo Container class:
- Swappable layouts. In Group, layout is handled by a separate object. In Container, layout is baked into the Container subclass.
- Looser requirements on children. Container required all content children to implement IUIComponent. Group allows any type of child, even raw data.
- Group does not have any chrome, rawChildren or contentPane. If you want a border around a Group, it must be composited together separately.
- Group does not automatically show scrollbars. Scrolling is handled in a separate subclass.
- Group uses the faceless mechanism for deferred instantiation, and does not use UIComponentDescriptors.
The flex.core.Group class merges and supersedes the flex.core.ContentHolder and mx.graphics.Group classes.
Usage Scenario
Example 1: Button Skin
Example 2: Panel Skin
Example 3: Simple List Skin
Detailed Description
Content
The default property of Group is content. The type is Object, which means any value can be assigned to it. The Group class supports single objects, Array, Vector, and classes that implement IList.
Content items can be any type of object. Group creates a visual representation, if needed, for each content item.
Here are the presentation rules:
- IDeferredInstance - Instance is instantiated. The instantiated object falls through to the next rule(s).
- DisplayObject - used directly. This includes any DisplayObject, not just classes that implement IUIComponent.
- IGraphicElement - used directly. Group calls the draw() method on the element when needed.
- If itemRendererFunction is defined, call it to get the renderer for the item
- If itemRenderer is defined, instantiate one
- Finally, if no visual item is found, use Label (or equivalent Gumbo component) and call toString() on the item
When the value of the content property is an Array or Vector, the content APIs must be used to manipulate the content items, and the content property should only be used to initialize or reset all content items. The APIs mimic the child management APIs in DisplayObjectContainer.
When the value of the content property is an IList, content items can be manipulated using either the content APIs on Group, or the item APIs on IList.
You can use the DisplayObjectContainer numChildren and getChildAt() APIs to iterate the visual children. The APIs that add, remove or shuffle children should not be called, and will throw an RTE if they are called.
Item Renderers
An item renderer is created for each data element in a Group. This renderer is the visual representation of the data element.
The itemRenderer property specifies an IFactory that is used to instantiate an instance of a renderer. The renderer must implement the IDataRenderer interface. The item is assigned to the data property of the renderer.
The itemRendererFunction property is used to specify a callback function that returns an item renderer for a specific piece of data. The function is passed an item and returns an IFactory that is used to create the renderer.
Example: itemRendererFunction
The alwaysUseItemRenderer property is used to force an item renderer to be created for each item, even if the item is already a visual element. The default value for alwaysUseItemRenderer is false.
Graphic Elements
The Group class supports graphic elements as content. Group is responsible for allocating backing display objects when needed, and calling the draw() method on the graphic elements. The Group class supports all of the attributes of the FXG Group tag described in the FXG 1.0 specification.
Layout
Layout and measurement are handled by a separate object, which can be changed dynamically at runtime. Details about layout management will be handled in a separate spec. For now, the important parts to know are:
- Measurement and layout are done by the layout object, not the Group
- Custom layouts can be written
- Basic layouts are very simple. Most likely, there will be a single instance that is shared among all Groups.
- There will be a mechanism for setting layout-specific properties for a component (eg horizontalGap).
Clipping and Scrolling
Basic rectangular clipping and pixel-based scrolling is supported by the DisplayObject scrollRect property. Masking is supported by the DisplayObject mask property.
Display and management of scrollbars must be done by a subclass or external controller class.
API Description
B Features
None at this time.
Compiler Work
None required.
Web Tier Compiler Impact
Not Applicable.
Flex Feature Dependencies
States - The new enhanced states syntax supports adding and removing items from a Group. This work is encapsulated in the AddItems/RemoveItems override tags, and has already been completed.
Layout - There is obviously a tight relationship between layout objects and Group. Refer to the Layout specification for more information.
Focus - Group is not focusable, but items within the group must be able to receive focus.
Styles - Group does not have styles, but can be a style parent (either direct or proxy) for the items within the group.
Virtualization - This will most likely be done as a subclass of Group.
Backwards Compatibility
Syntax changes
None. This is a new class.
Behavior
None, for existing content. For new content, there are some fundamental differences between Group and the old mx:Container class that need to be understood.
Warnings/Deprecation
None.
Accessibility
None, directly. The Group class itself does not have any accessibility features, but it does need to support accessibility of its children.
Performance
Size and speed are both critical elements of the Group class. A typical application may end up with thousands of Group objects at runtime, so performance testing must be done early and often.
Globalization
None. Right to left or vertical orientation is handled by the various layout classes, and does not require any specific functionality from Group.
Localization
Compiler Features
Not applicable.
Framework Features
List the RTE message strings that will require localization. (They must all come from .properties files.)
RTE messages are displayed when calling the Flash DisplayObjectContainer children APIs directly - addChild()/removeChild()/etc.
List all UI text that will require localization, such as the month and day names in a DateChooser. (All such text must all come from .properties files.)
None.
List all UI images, skins, sounds, etc. that will require localization.
None.
Discuss any locale-specific formatting requirements for numbers, dates, currency, etc.
None.
Discuss any locale-specific sorting requirements.
None.
Issues and Recommendations
Supporting scale grid properties on Group. The FXG Group tag supports the properties scaleGridLeft, scaleGridTop, scaleGridRight, and scaleGridBottom. We need to support these properties too. One solution is having these properties automatically assign the "ScalingLayout" to the Group.
Make group a non-DisplayObject. Since there are so many Group objects in any given application, it would be great if they weren't all required to be DisplayObjects. Early prototyping proved a noticeable increase in startup time and decrease in overall memory usage, but many details would need to be worked out.
Extensible data support. Group has basic support for IList, but does not directly support paging data sets. Ideally, this could be layered on with either a subclass or an intermediate proxy object that implements IList.
QA
Yes
|
Just want to comment and add how important scaling support is. I recently came across an interesting bug in Flex that does not exist in Flash. In Flex it is impossible to scale a flash.text.TextField in way that is not proportional, if you change the scale of y either from scaleY or the matrix, it updates the scale of x and vice versa. This works fine in Flash, but not Flex. Very odd. I even tried going as far as creating a MovieClip in Flash with a TextField in it and embedding it in Flex to use.