On 5/19/15, 8:18 AM, "Michael Schmalle" <teotigraphix...@gmail.com> wrote:
>>I couldn’t tell quickly whether Starling has only one Event class, but
>>I’d
>> suggest we start with an Event with no data since that’s built in to the
>> runtimes, then a ValueChangeEvent that has oldValue/newValue and add an
>> EventWithData when we come up with a need for it. Also note that:
>>
>> MyClass(event.target).selectedIndex
>>
>> is type-checked by the compiler, where as
>>
>> event.data
>>
>> is probably not, so IMO, I’d recommend the former instead of passing the
>> payload in a data field in most cases.
>>
>>
>Starling has a couple but not many, like TouchEvent etc.
>
>So you are saying use a ValueChangeEvent for things that need a payload,
>don't tack data onto event correct?
>
>I am confused as to the " I’d recommend the former instead of passing the
>payload in a data field in most cases." Can you give a concrete example of
>what your context is? Just trying to fully understand what you are saying.
I think ValueChangeEvent has two properties (oldValue and newValue). If
we come up with a need for sending around only one extra property, we
should then make an Event subclass called EventWithData or DataEvent. But
the base Event probably should correspond to the base Event in the
runtimes, which doesn’t have an extra field for data.
But it just isn’t clear to me that you need to pass a data item around
like selectedIndex in your example. I think it is a better practice in
most cases to simply query the event target. The exception is
ValueChangeEvent since there is no way to query the target for the old
value.
For an example like selectedIndex, what is the usability trade-off that
makes it work passing selectedIndex as a parameter and assigning it to the
Event object? Why shouldn’t you just use:
MyComp(event.target).selectedIndex
instead of
event.data
Then no extra work of passing a parameter and assigning it to an object
and the compiler knows that selectedIndex is an int and not Object or *.
You can run into some interesting edge cases assigning event.data to
certain data types.
But like I said, I could be wrong here.
>I already do this, I put events on ALL my components as constants. That
>way
>a mediator always knows what it can get from a component. I the dev.....
>neve have to use my crappy memory to remeber all these rediculous event
>class names, just use autocompletion;
>
>addEventListener(myView.EVENT_[name goes here], )
I’d be up for prefixing event constants on the class with EVENT_. Let’s
do that for FlexJS unless someone else objects.
>>
>> Regarding where and how the JavaScript line is, I’m not quite sure what
>> pieces of information you are looking for, but consider this: the goal
>>of
>> FlexJS is to produce an optimal HTML/JS/CSS app, not an optimal SWF.
>
>
>
>You know, I think I am just getting this now. Honestly I thought this was
>the "NEXT" Flex framework for SWF.
>
>Now reading this I may have got the framework all wrong.
Well, I do want FlexJS to build great SWFs as well, but, IMO, the growth
of Flex is tied to acceptance of the technology as a way to build
HTML/JS/CSS apps and if folks snoop through the code and see that we’re
running a lot of code to emulate Flash player behavior, even things like
Dictionary and/or event priorities, we won’t be as successful. We’ll be
compared against Angular, Jquery and others on the final .JS output size
and how fast things run.
So I want the cross-compiled output to have as little overhead as possible
and look like you took an HTML/JS/CSS from some other framework and simply
cut it into pieces with more hardened API surfaces.
-Alex
