[ASJS] VanillaSDK as part of the SDK
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
Re: [ASJS] VanillaSDK as part of the SDK
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 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 >
Re: [ASJS] VanillaSDK as part of the SDK
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 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 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 >> -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [ASJS] VanillaSDK as part of the SDK
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" 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 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 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
Re: [ASJS] VanillaSDK as part of the SDK
Alex, > 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. I will join you with your work on FlexJS, don't worry. I think I can be helpful with your transition to FalconJx and in emitting a more 'goog' oriented output. That way FlexJS and the VanillaSDK can share the 'goog' emitter in FalconJx, one less thing to worry about for you. That way you (and Om?) can focus on the frameworks. But first I'm putting the finishing touches on the inclusion of the Closure Compiler into FalconJx, loosing the Python dependency along the way, which is a (very) good thing -- that dependency was kinda ruining the prospects for the VanillaSDK approach ;-) Then I'm off skiing next week! Have fun, EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl