On Feb 9, 2014 10:44 PM, "Alex Harui" <aha...@adobe.com> wrote: > > > > On 2/9/14 9:58 PM, "DarkStone" <darkst...@163.com> wrote: > > >Hi all, > > > >I've just skimmed through the FlexJS asdoc: > >http://people.apache.org/~pent/asdoc-flexjs/ > > > >And I haven't found SkinnableComponent, GroupBase, Group & DataGroup, > >Skin, IVisualElement, etc. These are the core featured classes of Flex > >Spark architecture. > > > >In flex, by extending the SkinnableComponent class, defining SkinParts, > >SkinStates, and design the component's skin by extending the Skin class, > >using markup language (mxml) and css to do the layouts and styles, these > >are of the highly efficiency feature of Flex Spark architecture. > > > >I fully understand that FlexJS has just started, it has a long way to go, > >I'm so grateful to see it. I just wanna know will SkinnableComponent and > >related Spark architecture features be supported by FlexJS in the future? > > > >Thanks for any replies! > Hi. Unlike the Flex SDK, where a particular component set was supposed to > be the "only one", FlexJS should be able to support many different > component sets. The one we are working on right now that is in ASDoc is > designed to be the most lightweight component set that maps cleanly from > the HTML/JS/CSS stack to Flash, while trying to keep as much of the "feel" > of Flex. That component set will not support Spark Skinning as it is my > estimation that Spark Skinning is not going to efficiently work in > HTML/JS/CSS. I expect that someday, someone will generate a component set > that tries to better emulate the Flex SDK Spark components, but would > expect the resultant apps will be fatter and slower. > > Yes, this means you have to learn a new skinning workflow to use the > lightweight FlexJS component set, but many of you have proven you could > learn Spark Skinning after doing MX skinning, and I think there are > benefits to how we are handling custom visuals in the FlexJS "basic" > components. > > A Spark Skin is often a composition of subcomponents. Even Button's skin > composes a Label. In FlexJS the Button converts directly to the HTML > button, and it does not support that kind of complex custom visuals. So, > in the FlexJS basic components, there is are separate model, view, and > controller beads, and the view holds that composition of subcomponents, if > any. Then CSS is used to alter the visuals in the subcomponents. It is a > goal to make that all map cleanly to shadow DOMs in HTML5/CSS3. > > This highlights an important distinction about this basic component set. > The goal is to take HTML and/or HTML5 constructs and map them to Flash, > not the other way around, so that there is as little "emulation" going on > in the final HTML/JS/CSS output. > > FWIW, Spark Skinning had some flaws, mainly around the > hostComponent/skinPart piece. IMO, it is not a good idea for the host > component to know about a set of skin parts in the Skin. I believe this > was a performance optimization at the sacrifice of good design. This flaw > was further compounded by the Spark component containing the model (the > public properties). Really, the model should not know anything about the > view. This limitation resulted in the "icon button" problem where it > wasn't possible to add a per-instance Icon to the Skin without subclassing > the host component. In FlexJS, you can simply swap in an extended model > and an extended skin, set up your CSS and it just works. > > In really complex Spark skins, it means you can't defer creation of skin > parts without making them optional. In FlexJS, you should be able to do > just about anything you want as long as the model, view, and controller > agree. > > The "mantra" is this: If you have an existing app of 10K lines of MXML > and 100K lines of AS, you will have to recode some of it, but should be > much less than recoding all of it to some other JS framework. And once > you do get it recoded, the output will have as little overhead over having > rewritten it in another JS framework as possible. > > Now, the baseline for FlexJS is IE8/HTML, not HTML5. Omprakash has been > looking at FXG->SVG conversion for those of you who can assume HTML5 > browsers as the baseline.
It is still my goal to try and build a FXG to SVG conversion subsystem in FlexJS. From my experiments so far, I have proven that it is possible to have close to 100% rendering fidelity between FXG and SVG. I may need help plugging it into FlexJS in a seamless way. And in that case, being able to cross-compile > MXMLG in an existing Spark Skin starts to become interesting, but again, > I'm not sure what to do about subcomponents that might be mixed in. Maybe skins won't have sub components. Not sure how that would work, though. > > But hey, this is in fact a prototype. Ideas and this kind of feedback is > quite welcome. If you have thoughts on how FlexJS can map more Flex SDK > code without having to do a lot of emulation on the JS side, definitely > let us know. > > HTH, > -Alex >
