Om, > Just to be clear, for all practical purposes, when I say FXG, I really mean > MXML. This is because, the Flex implementation of FXG ensures that FXG > elements can be pluggable inline into any MXML component. So, if we are to > support MXML, then we must support FXG. > > In what I am doing currently, I am actually processing an MXML file, ignore > things that I dont care about (like fx:Script, fx:Metadata, and any > non-visual component) > > It just happens that for Spark components, the FXG elements appear only in > their Spark skins. This makes my job easier because if I target only the > spark skins, I wont have to deal with a lot of other MXML functional (i.e. > non view) elements.
Currently, the way it's (going to be) set up is that when parsing MXML (which FalconJx now knows how to do), all script blocks and other non-MXML entities encountered along the way are parsed by their own type of parsers. So I imagine that you'd be writing a parser specifically for the FXG elements and that parser will be called when the MXML contains a FXG element. Would be my suggestion... >> >> 3) Ah, there is the CSS, I guess (fxg -> svg + css). The AS code will >> be cross-compiled to AS (weird, I know) or any form of JS we chose, >> most likely 'goog' JS, as it will have to be compatible with FlexJS >> and the VanillaSDK. Due to the way FalconJx is set up, it will be easy >> to add FXG specific JS parsing, if needed. >> > > What if I want to handcode some javascript? For example, if I want to > support the current 'states' paradigm used in spark skins, I need to write > some javascript to make it a reusable component. I am not sure if this is > the right approach, though. What do you guys think? All JS only, 'handcoded' scripts go in either the FlexJS and/or VanillaSDK JS frameworks (flex-asjs->frameworks->js), so I guess the FlexJS JS framework would be great place to put that for now (VanillaSDK is being held back a bit on account of me being only one person ;-). >> 4) Sounds like and excellent starting point... however, you'll >> probably have to tweak your local SDK 'a bit' to get both the Flex and >> JS side working. Or should be start one of those much rumored >> 'shared' feature branches of the SDK? >> > > What kind of tweaking do you mean? Actually, I dont understand anything > you just said. Please explain like I am 5 years old :-) Well, VanillaSDK requires you to work with a modified Flex SDK and I don't have one ready to be shared just yet (hence the tweaking). Since Alex indicated FlexJS is nearly ready to handle your type of contribution, I think you best work with FlexJS for now. > Cautious optimism abounds! Unbridled naiveté for the win :-P EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
