status update

[Tyler Wright]

Hello folks of the Reflex steering committee.

I'm just checking in to report on my progress and start some serious architectural discussions, the two things we like the most.

Layout
I've completed a standalone Layout system for Reflex. It supports all of the width/height features of Flex, run-time swappable Layout algorithms, is built on interfaces and utilities, is completely customizable and replaceable, and has some really nice performance already (without much optimization yet).

The Layout system is broken up into 3 pieces:

• RenderEvent: this utility offers the ability to invalidate and then validate through the event bus, reserving complex processing to happen just once per frame. Just like stage.invalidate() causes a dispatch of the "render" event before the next screen redraw, RenderEvent.invalidate(displayObject, "type") dispatches a "type" event from the displayObject just before the next screen redraw. Types must first be registered with a render phase, a separate phase in the render cycle. For example, in the current implementation there are two phases registered:
          RenderEvent.registerPhase(MEASURE, 0x80, false);
          RenderEvent.registerPhase(LAYOUT, 0x40, true);
  where the parameters are 1) phase type or event type, 2) priority, determining the order in which each phase will occur and 3) ascending in depth, determining the order to dispatch events. The benefits of RenderEvent over stage.invalidate() are that phases are complete resolved before the next phase, that only the display objects that are invalidated receive the event (no adding/removing listeners all the time) and the ordering by depth, which allows a huge performance advantage in a Layout system. Other benefits are that rendering still happens during stage resizing, items that are invalidated during a render cycle are still resolved in that cycle (if they haven't yet been passed up), and the utility offers complete flexibility for extended use.
  
• ILayout: this layout object targets any DisplayObject, essentially extending its functionality without imposing a required baseclass or interface. The Layout object exposes all of the expected layout properties such as width/height padding and margin, and ties into the "layout" and "measure" render phases. Logic in the Layout is confined to laying out the display object it targets, such as restricting its width/height to fall within the min/max bounds. The Layout object also has an "algorithm" property which may optionally tie in a ILayoutAlgorithm.
  
• ILayoutAlgorithm: a measure and layout algorithm class that target a DisplayObjectContainer, positioning and aligning its children uniformly.
  

The default Layout in Reflex is Block, a layout which focuses on organizing display objects into rectangular areas on the screen. Block has all of the width/height constraints, margin and padding, and other features that accompany this type of layout. There will be various layout algorithms that go with this Layout, such as VerticalStack, HorizontalStack, Tile, etc. The current default layout algorithm is Dock, which provides a mix of stacking and tiling within one container.

I have some examples in the GITHUB repo under the development/ directory which will be moving to another repo that Ben created.

Components and Behaviors
I've refactored and built the Button and ScrollBar behaviors, the logic that make these components behave appropriately. Some of the wiring is hardcoded in the implementation until the proper solution is determined. The coolest thing about these behavior implementations is that they simply target InteractiveObjects. This means, if you ever wanted to, you can build a ScrollBar out of Textfields or out of a pile of Flex Canvas's. The Behavior system doesn't know or care about "UIComponent" and doesn't need to. This concept hinges on another discussion I'll bring up in a separate thread.

Models
There are a handful of common models that make up most/all components. The ScrollBar, Slider, ProgressBar, NumericStepper, MP3 Player and other similar components all represent some type of position. By providing a common IPosition model I've reduced repetitive code and centralized logic and testing. Best of all is that similar components share common API's and are fully compatible with each other, making binding and cross-implementations easy.

Skin
So far all of my skinning has come from Flash Professional which has made it really easy and light. It's great that it has been so easy and that I can test so thoroughly without depending on a base component class.

That's it for now. I'm planning on putting a lot more out here on the list then I have been so be prepared. I'm happy with the progress and hope to see it continue.

Tyler Wright

[Jacob Wright]

• ILayout: this layout object targets any DisplayObject, essentially extending its functionality without imposing a required baseclass or interface. The Layout object exposes all of the expected layout properties such as width/height padding and margin, and ties into the "layout" and "measure" render phases. Logic in the Layout is confined to laying out the display object it targets, such as restricting its width/height to fall within the min/max bounds. The Layout object also has an "algorithm" property which may optionally tie in a ILayoutAlgorithm.
  
• ILayoutAlgorithm: a measure and layout algorithm class that target a DisplayObjectContainer, positioning and aligning its children uniformly.
  

The default Layout in Reflex is Block, a layout which focuses on organizing display objects into rectangular areas on the screen. Block has all of the width/height constraints, margin and padding, and other features that accompany this type of layout. There will be various layout algorithms that go with this Layout, such as VerticalStack, HorizontalStack, Tile, etc. The current default layout algorithm is Dock, which provides a mix of stacking and tiling within one container.

Dock is really cool. You'll all have to check it out.

[Ben Stucki]

Hey guys,

I'm just starting to look over some of the latest code and decided I should send feedback one at a time. :) The first item I've come across is package naming. It looks like we're mixing singular and plural package/folder names. The de-facto standard is usually to use plural package names if the package describes a group of items (controls, events, styles, validators, etc). I'm happy to break the rules of course, but it'd be good to have a reason why. Why should we use singular packages? - or alternatively, should we standardize on plural ones?

reflex/behaviors
reflex/layouts
reflex/skins

- Ben

[Tyler Wright]

Why should we use singular packages? - or alternatively, should we standardize on plural ones?

reflex/behaviors
reflex/layouts
reflex/skins

For package naming plural vs singular, the distinction might be difficult to make sometimes, but the rule of thumb I go by is:

• plural if the package contains a list of same-type classes (eg commands package holds all of the application's ICommand implementations)
• singular if the package contains a group of different classes relating to one problem domain (eg command package holds ICommand, CommandHistory, CommandUtils, etc)

It's so easy in GIT to change folder names (subversion is a pain) that I've broken out of my usual pattern and decided not to worry about where I'm putting stuff. My personal preference is still to have a separate package (or subpackage) for the component set implementation than the component framework. For example:

reflex.behavior has the behavior interface, baseclass and behavior-related utils and helpers.

flame.behaviors or reflex.components.behaviors has the default behavior implementations we're shipping with.

My preference is also to avoid having a core package (because it isn't descriptive enough for me) and to separate the solutions out into their respective packages (eg behavior, component, skin, utils, etc)

Other package-naming preferences include:

• no classes in the root package, just sub-packages that are descriptive of what they contain
• avoidance of sub-sub packages, and no sub-sub-sub packages (keep things reasonably shallow, no reflex.component.components.behaviors.progress.scroll.ScrollBehavior type stuff)
• some congruency with Flash built-in naming conventions where it makes sense - having an events package, utils, possibly display or other
• no regard or consideration to Flex package naming conventions

kidding on that last one, sortof. ;)

That's my input, thoughts?

Tyler

[Ben Stucki]

I think we're going to get resistence for having both a singular & plural package in each category (mainly from me perhaps). I get the logic, but I think the practicality may be difficult. At the very least we'll end up having to explain our distinction each time we present it, which doesn't speak well for being self descriptive.

I could go with a core folder, which is probably my preference (although I'm not 100% sold), or I could go with putting core architecture elements (interfaces and base classes) in the plural package along with their concrete implementations - possibly even putting the concrete implementation in a totally separate lib project. The case for a "core" package is that it promotes a convention in which "core" elements (largely interfaces) may be referenced throughout the framework (they are core to the framework - required for it to exist), but outside classes (largely base & concrete implementations) may not be referenced across packages. The drawback, of course, is that the core package can get crowded and contain many otherwise separate concerns.

Again, I see both sides, but I think we would get push-back on having singular AND plural packages. Maybe we should check with our good friend twitter though.

- Ben

[Jacob Wright]

Are we really having this conversation?? Dude, let's write the framework and worry about names when we've got something. No one will care about package names.

[Ben Stucki]

I was having the conversation. No one is halting progress based on package names, but I already work with the code and as it happens I do care. I'm going to hazard a guess that other people care, and that it does matter aesthetically. However, in case I'm wrong I recommend we use packages with an animal name that starts with the same letter as the class.

reflex/buffalo/Button
reflex/hippopotamus/HorizontalLayout
reflex/velociraptor/VerticalLayout

... go on, you know you want to.

- Ben

[Simeon Bateman]

Everytime they change the name of something in the flex framework I wish they had some foresight and actually thought about how to name things as a team. 

I don't actually care if the are singular or plural but I do hope they are consistent. 

Sim

Sent from my iPhone

[Tyler Wright]

I could go with a core folder, which is probably my preference (although I'm not 100% sold), or I could go with putting core architecture elements (interfaces and base classes) in the plural package along with their concrete implementations - possibly even putting the concrete implementation in a totally separate lib project. The case for a "core" package is that it promotes a convention in which "core" elements (largely interfaces) may be referenced throughout the framework (they are core to the framework - required for it to exist), but outside classes (largely base & concrete implementations) may not be referenced across packages. The drawback, of course, is that the core package can get crowded and contain many otherwise separate concerns.

Because the framework is made up of a conglomerate of independent solutions (ie IBehavior doesn't know or care about Component) I think we should keep it out of core and in a behavior(s) package. I can be happy with plural packages for behavior and skin classes, just like events holds the core IEventDispatcher and EventDispatcher in addition to all of the event concretes. IBehavior and Behavior go in behaviors while ISkin and Skin go in skins. I'd still like to find a way to avoid core, which if we go with this scenario the package can be named component instead of core.

While on the topic, do we replicate Flex controls and containers packages? Is there a better organization of our components? We talked once about separation by data structure, but I don't know if I still like that idea.

Tyler

[Ben Stucki]

Plurals work for me, and I'm fine with avoiding core. I do think that a lot of people will look for the familiar controls, containers, etc packages to find items that they're used to. I'm not totally against coming up with something different, but I don't know what our better alternative would be. It needs to make enough sense and have enough benefit to overcome the familiar.

- Ben

[Tyler Wright]

 It needs to make enough sense and have enough benefit to overcome the familiar.

Unless its purpose is to defy the familiar  ;)

You're right, I don't have a better suggestion and controls and containers is familiar.

[Jacob Wright]

If you want to follow Adobe, they're putting all the spark components into spark.components.*

I don't know if we'll really have many containers since the concept of layout. Panel and Window? Canvas, HBox, VBox, are things of the past. The familiar will be changing with Flex 4.

My 2¢

[Tyler Wright]

Thanks, good suggestion.

I've already changed package names to plural, 'behavior' to 'behaviors', 'skin' to 'skins'. It sounds like it's time for 'component' to become 'components' and hold more than just the base Component class and Application (the only 2 classes left-over from 'core')

Tyler