On 2/26/14 4:03 PM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote:
>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.
I finally got a chance to look at your .js and .svg files. For those who
haven't looked, the SVG file has SVG for different view states in it and
logic to handle mouse activity and switching SVG "trees".
Therefore this TextButton is not using an HTML Button with an SVG
backgroundImage and is instead emulating a button in SVG. Did you rule out
the HTML Button with BackgroundImage option? I think there were concerns
with flickering? Have you looked into what it will take to implement
accessibility in the SVG button?
Anyway, back to skinning. The following is long-winded and mostly just
thinking out loud. None of this is set in stone.
I think the most straightforward cross-compilation that would be easiest
to implement in the compiler would simply make a .js file for each .fxg
file where the JS file knows how to inject the SVG into the DOM.
Here's a pseudo-code example:
<!-- someskin.mxml -->
<Skin backgroundImage.normal="{normalfxg}"
backgroundImage.hover="{hoverfxg}">
<states>
<State name="normal" />
<State name="hover" />
</states>
</Skin>
<!-- normalfxg.fxg -->
<Graphic>
<Path x='0' y='0' data='M0 100 100 100 100 0 0 0>
<fill>
<SolidColor color="#ffff00" />
</fill>
</Path>
</Graphic>
The MXML compiler generates code for someskin.mxml that essentially does
this:
if (currentState == "hover")
backgroundImage = new hoverfxg();
else
backgroundImage = new normalfxg();
And I believe the .fxg files becomes essentially
public class normalfxg extends Sprite
{
public function normalfxg()
{
graphics.beginFill(0xFFFF00);
graphics.drawPath(...);
graphics.endFill();
}
}
The cross-compiler would cross-compile the fxg files to normalfxg.js and
hoverfxg.js.
normalfxg = function() {
this.element = document.createElement('div');
this.element.innerHTML = '<svg><polygon points="0,0 0,100 100,100,
100,0"
style="fill:#ffff00;" /></svg>'
}
I think this puts an extra div in the DOM though. It may be possible to
optimize away the extra div. But the .js file for someskin.mxml as the
same logic:
if (currentState == "hover")
backgroundImage = new hoverfxg();
else
backgroundImage = new normalfxg();
Now, I'm currently calling these skins "views" in FlexJS and am
distinguishing skinning as something else. The above example generates
what I call a static view. It's look cannot be changed by CSS unless you
swap out the entire view. But since the browsers have powerful CSS
implementations, I want to use CSS more. The Web Components spec and its
Shadow Dom also makes me want to head in the direction of more CSS as I
think browsers are going to optimize for it.
This will have an interesting impact on skinning. In Spark, you specify
whole skins via CSS via skinClass and maybe there are some styles
supported by that skin. In FlexJS, we've been forced by the HTML
components to have separate View and "Skin" concepts. A Button's View is
baked into the native control, but for a more complex component like a
Panel, the View is composed of a TitleBar and a ContentArea, and other
Panel Views may have a StatusBar and/or ControlBar. But the actual
visuals of the TitleBar are defined (or will be defined as we haven't
fully developed this yet) via CSS. To change the look, you change the
CSS, including backgroundImages. Themes are effectively different CSS
files.
It is certainly allowed to bake your visuals into the View, but then it
won't respond to CSS changes unless you swap in whole Views. So, do we
want to encourage folks to do that or encourage them to separate out the
SVG from the subcomponent structure in the View?
If you separate out the SVG files then I think we end up loading .svg
files like we would the png/jpg/gif files for backgroundImage in the HTML
controls.
BTW, I think both of these two plans also mean that the SVG doesn't have
to have event management in it. The event management goes in the View
logic and makes for "code-less" skins which are easier for designers to
work with.
Anyway, enough rambling for now. What are your thoughts? Both of these
proposals would result in a different setup than you have now. What are
the advantages of the way you configured things?
Thanks,
-Alex
