InteractiveObject

[Tyler Wright]

Behaviors and their utilities could (and have done) target either InteractiveObject or IEventDispatcher. By targeting IEventDispatcher the behavior is more flexible and could be added to a non-displayObject class like Flex 4's Rect (which actually doesn't dispatch any useful events). On the flip side, by targeting InteractiveObject the behavior has direct API access to mouse and keyboard events and properties (such as mouseX/mouseY, MouseEvent.CLICK, KeyboardEvent.KEY_DOWN).

Though using IEventDispatcher might be more flexible, almost all of our current (and I think future) behaviors will have to type to InteractiveObject(target) somewhere in their implementation. I propose we dictate that Behaviors are compositional objects specific to the display list, or InteractiveObjects, and that if you want to use a similar compositional approach then you should create a unique base class, call it AddOn perhaps, and give it a target of _whateveryouwant_. Unless SlideBehavior and DragBehavior are able to listen to MouseEvents, retrieve the mouseX and mouseY values, and udpate the x/y coordinates on every IEventDispatcher they target (display objects or otherwise) then I think Behaviors should be typed to InteractiveObject. The implementation of Behavior is so minimal there would be little shared code for another solution. If the desire is to pair the name Behavior with this concept of composition then I'd like to have a specific compositional implementation for InteractiveObject called Controller. Either name works for me, I just want InteractiveObject or higher.

thoughts?

Tyler

[Jacob Wright]

Shouting out from the sidelines here.

I agree. There may be a desire to use "Behaviors" in other systems, but I think that desire is a misguided desire to use composition, to add flexibility for flexibilities sake, or to simply use the name Behavior. The concept and root definition of a behavior in Reflex is: additive functionality to user interface controls or components through composition. We could even target Component if we wanted to and probably be just fine but for TextFields. InteractiveObject would be the most base class in which any user interface control might extend (Sprite, TextField, SimpleButton). We should definitely go with that to reduce the ways in which you might use Behavior and thus complexity.

If anyone needs a compositional system with objects called Behaviors that target IEventDispatchers, ping me off list and I'll write you an interface with a property of "target" that is typed to IEventDispatcher. I can even throw in an AbstractBehavior which takes an IEventDispatcher as a constructor argument.

:)

Jacob

[Ben Stucki]

Hey guys,

I'm not against using InteractiveObject in the implementations or in the utility, but I'd like to keep IEventDispatcher on the interface for right now. I guess we could create another recognized interface with InteractiveObject, but I don't want to mix terminologies by calling it a controller or addon or whatever. We could just call it InteractiveBahavior or something. Down the line if we find that every Behavior uses InteractiveObject we can adjust, but I'm finding that targeting IEventDispatcher makes unit testing really easy. Take the ButtonBehaviorTest for example, you just extend EventDispatcher, dispatch some events and see if the right thing happens. It's not that it couldn't be done in another way, but it's a valid use case. Easy unit testing for component functionality is a big selling point.

I'd also like to play with some examples using PaperVision's DisplayObject3D before we cut off the possability entirely. I know these are outside use cases, but I'm just saying let's keep them open for now and reevaluate down the road. Plus, referencing concrete classes on an interface raises a little warning flag in my "you're going to regret this" center of the brain.

- Ben