1. Event data; Understand what you are saying now. My problem and I was probably confusing you is more on an application level and models. So this is a mute point since it's the way I design applications with the mediator.
As far as the framework, I agree, having the "data" represented on the component and casting the event target is the best thing, my use case was dealing with high level composite components that may not have the concrete API, thus sending data is dynamic and has the trade off of faster development time. 2. Prefixing EVENT_ on component events I think it's a good idea. :) 3. FlexJS IS a javascript/html framework. I have a really bad problem of over thinking things. Alex, what I am trying to do right now is digest 2 years of development within a couple weeks time. :) My goal is mobile targets with FlexJS and Cordova. SO I really need to know the edges of the framework because not only to I have to know the limitations of FlexJS is, I need to know HTML/JS limitations. The above may not make sense but it's the way my mind things, I think of the extremes to the point of impossible and work back to the possible. I have always learned and developed like this. It's also why FlaconJX got written, I did the same thing with the BURM and FlaconJS and Falcon when I learned it. I went as far as I could and then came back and realized I could write something that was within my understanding. Same applies with me and FlexJS/mobile HTML/JS frameworks. Mike On Tue, May 19, 2015 at 11:52 AM, Alex Harui <aha...@adobe.com> wrote: > > > 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 > >
