+1 For saving the skinning (Doesn't have to be 100% the same, but the concept of skinnable component + Skin implementation was very valuable to me)
As for me this finally was a way to concentrate on implementing the logic and I could have the Skin developed externally. This is the one Thing I am currently missing with any other Framework I have to deal with. Chris ________________________________________ Von: carlos.rov...@gmail.com <carlos.rov...@gmail.com> im Auftrag von Carlos Rovira <carlos.rov...@codeoscopic.com> Gesendet: Donnerstag, 27. Februar 2014 11:13 An: dev@flex.apache.org Betreff: Re: [FlexJS] SVG based TextButton and example checked in 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. 2 - SkinPart MetaData. In general MetaData is where Flex 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) 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
