Om, I know there is a lot(on this thread) but I already stated that my use case was on an application level and didn't really apply to a core framework.
Why? Because Using a mediator, it's view IS the component, it's already coupled. So going back to the original, having a SomethingType class for constants is an interface. Yeah having them ON the component is debatable and I might take that back since FlexJS is so heavily based on composition, I was referring to my custom composite components. Mike On Tue, May 19, 2015 at 1:33 PM, OmPrakash Muppirala <bigosma...@gmail.com> wrote: > On May 19, 2015 8:00 AM, "Alex Harui" <aha...@adobe.com> wrote: > > > > Some (many) thoughts on this: > > > > I considered event pooling in the current Flex SDK and have suggested > > pooling other objects in people’s apps at times in the past. Some folks > > claimed that instantiating lots of small objects fragmented memory and > > made the Flash Garbage Collector work harder. Flex does pool item > > renderers, but, IMO, more for instantiation time than GC impact. For > > sure, if I was running a 3D graphic simulation I would not want hiccups > on > > occasion to collect garbage. > > > > But at least for now, the FlexJS focus is on 2D applications, so I’d want > > to see if event instantiation is having a negative impact before > > implementing a pool. Also, since the root event dispatching for FlexJS > is > > implemented within the runtimes and I believe event.target is read-only, > > it is problematic to create a pool without causing other memory leaks. > > > > FWIW, the other way to optimize for event instantiation is to simply fire > > less events. In current Flex, lots of events are fired “just-in-case". > > With replaceable models and other parts in FlexJS, you should be able to > > replace parts with parts that only fire the events you are actually going > > to use if it turns out to be important. > > > > Another way to fire less events is to not use bubbling like I’ve seen > some > > folks do. Bubbling is an easy way to hoist an event up to a listener, > but > > breaks encapsulation and is the equivalent of shouting from the sidewalk > > to someone on the top floor of an apartment building. Bubbling is really > > intended for when the listener doesn’t know who is going to have > something > > to say, which is why Keyboard and Mouse events bubble, but for most > custom > > events, the better practice is to have each abstraction boundary dispatch > > an event that doesn’t bubble and has a unique semantic meaning, and have > > the one listener listen directly at the boundary. That’s like texting > the > > person on the top floor. Not everybody has to hear it. > > > > Separately, it looks like you like an API where you pass in a few > > parameters instead of an event instance. The JS side already does that > > and we could do that on the AS side. > > > > 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. > > > > And then, unlike Starling and current Flex which has dozens of constants > > declared on the Event class, I want to experiment with putting those > > constants on the class that dispatches the event. Having every constant > > on Event doesn’t scale well. When you get to 100’s of constants you > could > > be bringing in lots of strings that aren’t used and the documentation > gets > > unwieldy. Third-parties can’t be changing the Event class for their > > components so instead of creating subclasses of Event, why not just > > declare the constant on the same class that is dispatching it? > > This thread is moving too fast for me. I want to concentrate on this > point a bit now. > > The problem with declaring the constant on the same class that is > dispatching it is that it would create an unnecessary compile time > dependency between the class that is dispatching the event and the class > that is listening to it. I think having classes loosely coupled via > events is a good thing. Is it bad OO practise? I think that is > debatable. But, this is truly where the power of event driven applications > lies in. > > I usually organize my shared components in a library project, then create > one or multiple app projects that compose these components as needed. > > I could have two different view component dispatch a 'dateRangeChanged' > event with the same payload of an array of dates. In my listening class, I > dont want to have to deal with having Component1.DATE_RANGE_CHANGED vs. > Component2.DATE_RANGE_CHANGED > vs. any other additional view components that may be built in the future. > > The same way, I can bubble up the event from my view component and add a > listener on a ancestor higher up in the view heirarchy so that I dont have > worry about the type of component that dispatched the particular event. > > Micro-frameworks like PureMVC, etc. try to solve this problem by creating a > Notifications.as class and list every event (notification) name in that > class. This would probably be the only additional dependency needed, > rather than depending on the classes that dispatch the events. > > Thanks, > Om > > > > > 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. So > I > > will sacrifice a bit of being more like current Flex for using different > > APIs to make the final cross-compiled output run better. Thus, at the > > lowest level, I’m going to try to leverage HTMLElements, CSS, and > > EventDispatchers built into the browsers rather than layering code on top > > of it. IMO, you can always sacrifice performance and add layers on top > of > > your low-level, but the problem with current Flex is that there is no > > low-level below the 13,000 lines of UIComponent and the nearly 200K of > SWF > > bytecode it is hard-coded to bring in. The composition-orientation of > the > > framework should allow you to build up things into higher levels where > you > > need them, but allow for optimization, replacement, testing, mocking, etc > > of individual pieces. > > > > Finally, here’s the layout wiki page: > > https://cwiki.apache.org/confluence/display/FLEX/FlexJS+Layout > > > > HTH, > > -Alex > > > > On 5/19/15, 5:41 AM, "Michael Schmalle" <teotigraphix...@gmail.com> > wrote: > > > > >So are you saying Starling traded a bit of performance in event > > >dispatching > > >to get object pools? Or was is that they needed to implement bubbling of > > >their own display list, so they sacrificed performance. > > > > > >Mike > > > > > >On Tue, May 19, 2015 at 8:32 AM, Kessler CTR Mark J < > > >mark.kessler....@usmc.mil> wrote: > > > > > >> Just a side bar on this. I believe a concern about using the > > >> eventdispatcher like the one in starling was that it was slower than > > >>one we > > >> use from flash.events. It had to do with the fact the player was > > >>managing > > >> the events vs using an actionscript driven one. Bumped into that when > I > > >> explored managing the lists of the active events and I even made > single > > >> serving events that would remove themselves after one call. > > >> > > >> > > >> -Mark > > >> > > >> > > >> -----Original Message----- > > >> From: Michael Schmalle [mailto:teotigraphix...@gmail.com] > > >> Sent: Tuesday, May 19, 2015 6:30 AM > > >> To: dev@flex.apache.org > > >> Subject: Re: [FlexJS] Event names > > >> > > >> NOTE: I forgot to say that in the EventManager in the component > > >>framework > > >> can do it; > > >> > > >> > > >> > > >> > https://github.com/Gamua/Starling-Framework/blob/master/starling/src/star > > >>ling/events/EventDispatcher.as > > >> > > >> See the method invokeEvent(), line 140. In a way, this makes the need > > >>for a > > >> subclassed Event obsolete, the data IS the payload which can be a > > >>primitive > > >> value or vo/struct class. > > >> > > >> The client knows what it needs. > > >> > > >> Mike > > >> > > >
