On 2/27/14 2:13 AM, "Carlos Rovira" <carlos.rov...@codeoscopic.com> wrote:
>Hi Alex, > >I think spark was a huge step in Flex, and it was copied by other >technologies (I think JavaFx has the SkinPart element and other things >like >that thanks to Flex 4 Spark arquitecture). >But as you said there's some draw backs. Here's my list pros and cons in >Spark Skin arquitecture: > >PROS: > >1 - With spark we get a clean separation between View/Skin in all >application components, so all *view controller* code was in the AS3 >SkinnableComponent/SkinnableContainer extension class (addEventListeners, >handlers, and all *logic* behind visuals), and the Skin had only >declarative MXML layout positioning (basic, horizontal, vertical >layouts..., view states,...), style assignments (styleName, CSS,...) and >effects/transitions(for view states). > >This should not be lost in FlexJS, since it was one of the things make >flex >lead the race. Yes, there will definitely be view separation from controllers and even models in FlexJS. The component really just composites these pieces. Were you really able to create custom skins that didn't have code in them? Most of the Spark skins we ship have fx:Script blocks to handle certain layout aspects that were hard or inefficient to declare in MXML. I really hope the "skin" portion of the visuals in FlexJS (which are going to be png/gif/jpg or SVG, I think) is code-less. > >2 - SkinPart MetaData. In general MetaData is where Flex This got cut off so I'm not sure what your thoughts were. I'm not a huge fan of MetaData but we will have it in FlexJS. But SkinPart, IMO, had some issues about too much knowledge of the child by the parent. When a parent pushes stuff to the child, it gets in the way of deferred instantiation and late-loading tricks that might be used by the child for performance reasons. One of the mantras of FlexJS is "pull don't push". > >CONS: > >1 - Skins in Flex 4 needs to be copied to be extended, what make us to >duplicate lots of MXML code. This is due to mxml declaration hierarchy >layout that makes impossible to extend something without duplication to >get >the same visuals and layout. > >This is something to improve > >2 - Model Problem (this's the same point you mentioned with the >Button-icon >use case). This was a problem due to the lack of model separation, since >we >have real MVC at component level this would be address now with the new >FlexJS component model (Model: BeadModel, Controller:View-AS3 logo Bead, >V: >new Skin SVG model). > >Note: It's importante to maintain skin - view code separated, so if with >have some code in skin, should be only related to skin internals and not >dependent of any var in the model/controller parts. > > >I think that's all IMO, and now that we have a new output (JS) aside the >old one (SWF), I think we should try to get both outputs use the same SVG >code, if it's possible (this one maybe is not possible) > There was one other issue with skins, and that was with the skin states. It worked great for simple skins, but for complex skins, even with state groups, the number of states and state groups became unwieldy. Panel had "normal", "disabled", "normalWithControlBar", "disabledWithControlBar" and we stopped there and went to code before going on to "normalWithControlBarAndStatusBar" and adding "inactive" dimensions. Even a full button needed to deal with emphasized states. Flex cheats by not allowing every visual aspect to be in the skin. Focus, for example is not a skin state. And the result is there is code in the skin to try to defend a generalized focus algorithm from affecting parts of the visuals. If you had focus as a skin state the number of states in the skin would be unwieldy. I'm hoping to make data binding much faster/smarter in FlexJS so you can bind aspects of your view to various properties in the model and not have to tie everything to the currentState property. -Alex > > > > > > >2014-02-27 2:21 GMT+01:00 Alex Harui <aha...@adobe.com>: > >> >> >> On 2/26/14 4:59 PM, "Carlos Rovira" <carlos.rov...@codeoscopic.com> >>wrote: >> >> >So it seems we need to wire up a similar functionality to spark >> >SkinnableComponent to get parts of a component or view (AS3 class) >> >match thinks in a skin (SVG, and eventually MXML in flash side), isn't >>it? >> > >> >We need [SkinPart] metadata, right? >> IMO, we won't be able to do Spark skinning in FlexJS. Well, at least >>not >> for this set of components that we've currently built that leverage the >> built-in HTML widgets. Some heavier component set will try to emulate >> Spark and MX components someday. >> >> Spark skins are a combination of sub components and visuals. In the >>older >> browsers, there is no way to inject sub components and certain visuals >> into the built-in HTML widgets. So, in the FlexJS components we've >> currently built, we are creating Views which hold the sub components and >> using CSS for the visuals. >> >> SkinPart also had a major flaw: The host component made assumptions >>about >> the parts in the skin. In general it removes flexibility when you know >> something about your view/children. The classic example was when Flex 4 >> first came out and didn't have an IconButton. There was no way to add >>an >> assignable icon property with subclassing Button. In FlexJS, you >>replace >> the model and the view. >> >> > >> > >> > >> >2014-02-27 1:03 GMT+01:00 OmPrakash Muppirala <bigosma...@gmail.com>: >> > >> >> On Wed, Feb 26, 2014 at 9:57 AM, Alex Harui <aha...@adobe.com> wrote: >> >> >> >> > Sorry, wasn't clear. >> >> > >> >> > Thanks for reminding me that FXG is a class linked into the SWF and >> >> > referenced as a class by the AS code. On the JS side, do we want >>that >> >> FXG >> >> > class to be a "class" (its own JS file that loads or has SVG data >>in >> >>it)? >> >> > Or is more "conversion" needed. >> >> > >> >> > >> >> I have been thinking of a spark skin (ex. spark button skin) having >>an >> >> equivalent SVG document on the JS side. The button class itself will >> >>have >> >> an equivalent in js. >> >> >> >> Example: >> >> TextButton.as + TextButtonSkin.mxml === TextButton.js + >> >>TextButtonSkin.svg >> >> >> >> The TextButtonSkin.mxml links all the required FXGs to make up the >> >>various >> >> button states' visuals. It also has the code required to switch the >> >> states, etc. The same thing happens in TextButtonSkin.svg - it >>contains >> >> all the SVG elements and the JS code (or SMIL) >> >> >> >> I suppose this is quite similar to the spark architecture. >> >> >> >> >> >> > On the JS side, is there is a way to embed SVG data in an HTML >>page? >> >> > >> >> >> >> There are multiple ways to this - >> >> * inline svg code in HTML, >> >> * use <embed> element (what I have used in this case) >> >> * use <object> element >> >> * use <img> element >> >> >> >> <embed> seems to be safe to use across most modern browsers, whereas >> >> <object> has browser support issues + security restrictions. <img> >> >>element >> >> is useless to us because it causes the SVG to lose its interactivity. >> >> >> >> I suppose we can also directly emebed SVG in HTML, it seems safe to >>use >> >> these days [1] >> >> >> >> [1] http://caniuse.com/#feat=svg-html5 >> >> >> >> >> >> > >> >> > -Alex >> >> > >> >> > On 2/26/14 12:59 AM, "OmPrakash Muppirala" <bigosma...@gmail.com> >> >>wrote: >> >> > >> >> > >On Wed, Feb 26, 2014 at 12:48 AM, Alex Harui <aha...@adobe.com> >> >>wrote: >> >> > > >> >> > >> >> >> > >> >> >> > >> On 2/26/14 12:42 AM, "OmPrakash Muppirala" >><bigosma...@gmail.com> >> >> > wrote: >> >> > >> >> >> > >> >>3. Falcon should be able to compile FXG now, but I think it >>will >> >>use >> >> > >> >>Spark >> >> > >> >> components like Group. The compiler either needs to output >> >> different >> >> > >> >> primitives or we need to fake up lighter weight Spark >> >>components. >> >> > >>I'd >> >> > >> >> strongly prefer the first option. >> >> > >> >> >> >> > >> > >> >> > >> >I think I understand. Can we break this up into a very simple >>use >> >> case >> >> > >> >and >> >> > >> >see which direction we want to go? I may need a bit of hand >> >>holding >> >> on >> >> > >> >this one. >> >> > >> >> >> > >> Was FXG always embedded? >> >> > >> >> >> > >> >> >> > >You can also instantiate it just like a component in MXML. If you >> >>embed >> >> > >it, the compiler seems to rasterize it and you will lose the >>scaling, >> >> etc. >> >> > >properties that makes vectors so attractive. >> >> > > >> >> > > >> >> > >> Is there a way to "embed" SVG? >> >> > >> >> >> > > >> >> > >Yes, just like an image: >> >> > > >> >> > >[Embed(source="logo.svg")] >> >> > >[Bindable] >> >> > >public var imgCls:Class; >> >> > > >> >> > >Adobe had deprecated it. But, at Apache Flex, we un-deprecated >>it a >> >> while >> >> > >ago. >> >> > > >> >> > >Thanks, >> >> > >Om >> >> > > >> >> > > >> >> > >> >> >> > >> Anyway, yes a simple test case would help us find the desired >> >>workflow >> >> > >>and >> >> > >> fix what is needed. >> >> > >> >> >> > >> -Alex >> >> > >> >> >> > >> >> >> > >> >> > >> >> >> > >> > >> > >> >-- >> >Carlos Rovira >> >Director de Tecnología >> >M: +34 607 22 60 05 >> >F: +34 912 94 80 80 >> >http://www.codeoscopic.com >> >http://www.directwriter.es >> >http://www.avant2.es >> >> > > >-- >Carlos Rovira >Director de Tecnología >M: +34 607 22 60 05 >F: +34 912 94 80 80 >http://www.codeoscopic.com >http://www.directwriter.es >http://www.avant2.es
