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. 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. 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
