There is already precedence for mapping existing components to a new namespace. Some spark components are just MX components also referenced from the spark manifest (SWFLoader, ArrayCollection).
So yes, while I still have reservations about your approach and wish I could convince you to join me on my re-write, I think you are making a good proposal for helping folks know the boundaries on what components you are supporting. -Alex On 1/30/13 12:05 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: > I'm proposing to use what the SDK has to offer, mx and spark, and add > a thin wrapper class around each of those: goog. However, the goog > components don't add any functionality, they only provide support for > the JS workflow. From a developer point of view they'll look and act > just like their mx and spark counterparts. > > EdB > > > > On Wed, Jan 30, 2013 at 6:08 AM, Avi Kessner <akess...@gmail.com> wrote: >> Something isn't clear to me. >> >> Are you proposing that the AS3 code for Flex contains 3 groups of >> components? (mx or it's equivilent, spark, and goog) >> Or are you proposing that there are 2 groups of AS3 components, mx and >> spark, and one set of JS components (goog) which have different levels >> of compatibility with the first 2 groups? >> >> brought to you by the letters A, V, and I >> and the number 47 >> >> >> On Tue, Jan 29, 2013 at 9:30 PM, Erik de Bruin <e...@ixsoftware.nl> wrote: >> >>> Hi, >>> >>> One of the goals behind the vanilla SDK is to create a JS compatible >>> framework that closely resembles the Flex SDK. The idea is that the >>> coding and workflow in the AS IDE (likely Flash Builder) closely >>> matches working with Flex as we know it. This way ASJS has no learning >>> curve at all: it's just another release build option. JS output that >>> "just works" :-) >>> >>> In order to do accomplish this, I'm working on integrating the >>> VanillaSDK into the SDK proper. Don't worry, it's all happening in my >>> whiteboard for now. >>> >>> But I'd like your feedback on some of my ideas, while the >>> implementation is still in it's early stages: >>> >>> 1) create a new namespace in the SDK: http://flex.apache.org/js/goog >>> 2) add only the components to this namespace that are compatible with JS >>> output >>> 3) create JS compatible versions of spark (and other?) components, >>> using composition >>> 4) create JS versions of these components: the VanillaSDK >>> >>> This way hope to achieve the following: >>> 1) isolate the new components from the rest of the SDK, to avoid >>> "confusion" for developers >>> 2) allow for incremental development, since only properly prepared >>> components will be available >>> 3) by using composition instead of inheritance we keep control over >>> what we expose to the developer, allowing for API compatibility on the >>> JS and AS side, while still use Flex components on the AS side >>> >>> There's (much) more to it, but for now I'd like to ask: does this make >>> any sense, and if it does, how might we improve on this idea to make >>> it work better? >>> >>> EdB >>> >>> >>> >>> -- >>> Ix Multimedia Software >>> >>> Jan Luykenstraat 27 >>> 3521 VB Utrecht >>> >>> T. 06-51952295 >>> I. www.ixsoftware.nl >>> > > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
