Good discussions on UGO list today (no, I don’t know how to get there). There are a lot of initiatives, as well as proposed approaches, and everyone has an agenda (unlike my last AtlMMUG speech… bleh, my fault, learned though). I feel like there is a plethora of talent that once focused, like Voltron, will be awesome to behold.
We’re currently discussing our issues ranging from Flash’s component framework, the Flash IDE, components, to the Flash Player itself. Really it’s about indentifying the strengths, weaknesses, holes, and then merging those with the goals of the poeple there.
One the one hand, I dig the Flash MX 2004 Framework. However, there are certain times I cannot use some of the components because they do not work within the design I am giving for a project. Each of them support runtime skinning to a point, but it’s not true runtime skinning. You can set a symbol to use, that symbol was defined at authortime. If one were to have the capability (hint, hint MM) to set the linkage URL of an Imported Shared Library, then you could use whatever SWF you wanted, and therefore, any asset you wanted. This would empower true, runtime skinning for components, as well as a plethora of other media dynamcism. Whoa, is that a word?
Anyway, a lot of good ideas brewing. I think there is a target market for a lightweight AS2 framework for designers to easily customize. I think everyone would like a lightweight one. There are a few, too, from the enterprise world would like some the true runtime rendering combing XUL forms building as well as dynamic classes.
It really boils down to this: Current Shared Libraries do not expediate compile time. Because of this, even if one utilizes them, or even SWC’s, your still having to compile the class itself in the main SWF. Therefore, a combination of an agreed upon Interface + utilizing Brandon’s Outlet component allows one to utilize loaded SWF’s via loadMovie, and treat them as components. The issues therein are abudant; class exclusion, inheritance, ect. But the flexibility gains for some of the larger projects enterprise developers are doing, as well as some of the development benefits they offer in terms of recompiling only smaller parts of your project are cool.
Anyway, interesting mix of people, perspectives, and goals. Really neat to see the dynamic as each brings great talents, knowledge, and experiences to the table. For, at least, it seems that the majority agree upon utilizing what we have now rather than looking at a future version of Flash to solve our development needs. The needs of a differing framework for compactness, runtime rendering of graphics (non-bitmap), and support for design standards such as XUL forms (think I got that last part right) seem to be the most wide-spread agreements. After that is where individual inititives differ.