ButtonEvent

[nick r]

Hi just want to say I'm really enjoying tinkering with the framework,
I've noticed something a little odd though. Just wondering why the
event capturing and distribution logic for buttons is built into the
ButtonEvent class? I may have missed something pertinent but this
seems like the sort of code that would be perfectly encapsulated by
the ButtonBehavior or a utility class within it, not as a collection
of static methods in the actual event which is dispatched by this
behavior. Was there a special reason behind this decision?
Thanks,
Nick

[Jacob Wright]

The ButtonEvent is the special utility you might say. I'll defer to
Tyler on answering this question more fully.

Jac

> --
> To unsubscribe, reply using "remove me" as the subject.

[Ben Stucki]

Yeah, I didn't like the naming on this either. I have a feeling it'll get moved around or renamed (unless Tyler has some special reasoning for it that I don't remember).

[Tyler Wright]

ButtonEvent for the masses:

ActionScript 3 and its new Event approach in the Display List is powerful, but along with that power is some complexity. It is more difficult to create a properly working button out of a Sprite in AS3 than it was in AS2. The ButtonEvent utility re-introduces the dragOver, dragOut, release & releaseOutside events to ActionScript 3, also including a few new events such as drag, hold & stateUp/Over/Down. It makes it easy for anyone to create a button (lower-case 'b') out of any InteractiveObject in their Flash Movie.

Reason for ButtonEvent (why not make it a Behavior?):

Behaviors are a powerful feature in Reflex for adding interactivity and state to components. Their sole purpose is to add that functionality to components by listening to events dispatched by the component (or its skin) and if necessary update state properties such as progress, position, selection, etc. The ButtonBehavior uses the ButtonEvent to help make its target act like a button and then stores the button-state. As a developer you have the option to use the Behavior system if you intend to build components, or the lighter ButtonEvent by itself to get some simple button functionality out of any graphic.

To understand the trade-off, lets look at what the ButtonBehavior adds:

• a behavior object in memory
• stored button-state
• property binding
• bound event listeners
• and (for now at least) very light reflection

ButtonEvent just adds a new event type that gets dispatched from an InteractiveObject. It extends MouseEvent, allowing listeners to type to function (event:MouseEvent); and it adds the additional ButtonEvent types as static const HOLD:String = "hold".

These additions with the Behavior are shared by the component framework and so are of no consequence when using Reflex. But when a Flash designer needs a quick button that works properly (most custom AS3 buttons don't) they have an alternative without a component framework. I'm following the pay-as-you-go concept in this area.

Other benefits of abstracting more complex logic from the Behavior is that it keeps the behaviors small, easy to read and customize, and allows shared logic. Tooltip, Cursor and Popup behaviors can all rely on the same top-level manager which exposes various options in a clean API, allowing targeted components to reside over the top of a UI with different configurations. The complexity lies in the utility while the behaviors themselves remain light and easy to approach.

Tyler

For more information on AS3 button-behavior see an old blog post of mine as well as Andre Michelle's

[Ben Stucki]

Yep, so I don't think we disagree with the approach or the fact that it's advantageous for it not to be a behavior. I think we just have confusion around the naming. For the most part this isn't an event at all. It's a utility. Should we put the static methods in a ButtonUtil or ButtonManager class and just let the ButtonEvent be an event? I can do the coding (cut & pasting) if that works for you Tyler. Naming options are open as well. Is there something you'd be more comfortable calling it?

- Ben

[Jacob Wright]

The naming makes sense to me since it is an event (extends MouseEvent) and contains the statics for the events it provides (releaseOutside). It works like I would expect:

myButton.addEventListener(ButtonEvent.PRESS, onPress);

function onPress(event:ButtonEvent):void

{...}

I feel the only thing it needed was some explanation or documentation. Thanks Tyler!

Jacob

[Ben Stucki]

I think this thread (+ my initial reaction) bears some evidence that the naming doesn't make sense. To be clear, we're talking about splitting the code into two classes: a new utility and the original event. It's not really a sticking point for me right now, but I think if we leave it as is we'll keep hearing similar reactions. Using it as an event makes sense of course and event functionality should stay in ButtonEvent. However utility functions aren't typically carried around in an event class, so it's weird. You actually have to describe two separate pieces of functionality when talking about the class.

| The naming makes sense to me since it is an event (extends MouseEvent) and contains the statics for the events it provides (releaseOutside). It works like I would expect:

...and APIs normally work like you would expect when you're the one who writes them. :)

Like I said, it's not a big issue to me. There's no fundamental architectural problem or anything. So, I'm happy to wait it out.

- Ben

[Tyler Wright]

| The naming makes sense to me since it is an event (extends MouseEvent) and contains the statics for the events it provides (releaseOutside). It works like I would expect:

...and APIs normally work like you would expect when you're the one who writes them. :)

Actually I wrote that class. There are two pieces, the ButtonEvent and the button initialization that sets up listeners to the InteractiveObject and dispatches ButtonEvent. I implemented the initialization code in ButtonEvent to reduce the number of classes needed. Traditionally Event classes don't actually do anything, they just represent a type and sometimes hold data. ButtonEvent exposes the static utility for efficiency.

So now you have the background to my design decisions. If it becomes a problem we can certainly take it into review. I have no qualms about refactoring to improve API now or ongoing into the future, since I don't believe anyone can predict all the potential problems or solutions.

Are we on the same page with Behaviors and their occasional use of external libraries or utilities?

[Ben Stucki]

| Are we on the same page with Behaviors and their occasional use of external libraries or utilities?

Yep. We're on the same page about using utilities in behaviors. I don't think that's at issue.

| There are two pieces...

I know, that's exactly what I'm saying!

| I implemented the initialization code in ButtonEvent to reduce the number of classes

I'm not sure there's an upper or lower limit on number of classes, only a logical grouping of functionality. I guess we have a difference of opinion regarding whether or not utility functions should exist in an Event class or be moved to their own utility class.

| ButtonEvent exposes the static utility for efficiency.

Yep. No one's arguing that the functionality shouldn't exist, only where it belongs.

Plainly stated, calling ButtonEvent.initialize(button) is not at all intuitive - in my opinion. I immediately think, "Wait, I thought this was an event? Do I need to dispatch something now?" Looking through the code I can see that this applies to RenderEvent as well.

I feel a little weird that two against one don't view this in the same way. I think I'm going to wait for this to come up again just for my own self assurance, but I'll probably push for refactoring these at that time. Again, no one's concerned about the logic or architecture involved here. It's just an API issue.

- Ben

[Jacob Wright]

At least with all the discussion over every piece we'll have quite a mature base to build on. We won't please everyone, but we will probably please most with out APIs.

Great feedback!

[Baz]

I immediately think, "Wait, I thought this was an event? Do I need to dispatch something now?" Looking through the code I can see that this applies to RenderEvent as well.

+1

[nick r]

Hey great to see some discussion on it.

Tyler, I see your point in separating the basic button functionality
from the concrete ButtonBehavior and it definitely makes sense but I
have to agree with Ben & Baz that the initialisation probably belongs
in a separate class from the Event itself.

What are your thoughts on a package level function, something like
reflex.helper::initialiseButton(InteractiveObject). Then it still
exists as a separate entity from the reflex Behaviors system, can be
used by Flash as a single line initialisation function and the
listeners inside it can still dispatch simple ButtonEvents. I think
it's a patten that more new-comers will find familiar; an Event class
that manages its own dispatch is a bit confusing. You could apply the
same logic to the RenderEvent like reflex.helper::initialiseRenderer()
though the rendering logic probably requires a full static / singleton
class implementation.

Anyway, just thought I'd throw that out there. Please excuse my funny
australian spelling of initialise :)

On Apr 13, 1:51 pm, Jacob Wright <jacwri...@gmail.com> wrote:
> At least with all the discussion over every piece we'll have quite a  
> mature base to build on. We won't please everyone, but we will  
> probably please most with out APIs.
>
> Great feedback!
>

[Tyler Wright]

I feel a little weird that two against one don't view this in the same way. I think I'm going to wait for this to come up again just for my own self assurance, but I'll probably push for refactoring these at that time. Again, no one's concerned about the logic or architecture involved here. It's just an API issue.

No one is against anyone. Jacob stated that 'ButtonEvent' wasn't too off-base because there was indeed an event being dispatched and event types to be represented on the static. I was explaining that this is true, but there is another non-event element, the utility - and yes, this is what you were saying. The rest is background to why it was approached this way and an invitation to change API as necessary.

I don't know why I'm explaining my previous email, I went back and read it and it seems clear. Unless anyone else is disagreeing on this topic then the API is free to change. On that note, any preference for the utility naming and package location?

Tyler

[Tyler Wright]

What are your thoughts on a package level function, something like
reflex.helper::initialiseButton(InteractiveObject). Then it still
exists as a separate entity from the reflex Behaviors system, can be
used by Flash as a single line initialisation function and the
listeners inside it can still dispatch simple ButtonEvents.

Package-level methods seem more friendly to Flash devs, it's not a bad idea at all. Thanks Nick!

Anyway, just thought I'd throw that out there. Please excuse my funny
australian spelling of initialise :)

Aussies welcome! I lived two years in the Melbourne area, I hope to go back and visit someday.

Tyler