incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Arno" <>
Subject [Discussion] Flex 5 and non-SWF targets: Skinning
Date Fri, 03 Feb 2012 17:23:13 GMT
I have been thinking about how we might develop Flex so that it can target
technologies other than the flash player. I have been using JavaScript as my
theoretical target because it poses the most problems: we have to convert
the AS3 source to another language (not bytecode), we need the output to be
as small and fast as possible and - the topic of my thoughts here - we
cannot render to the Canvas as it is just too slow, instead components will
need to be "rendered" using the DOM and CSS.

My knowledge of skinning Flex 4 components is minimal, but my understanding
is that spark components hand off *all* rendering to skin classes. If this
is the case, then it might be relatively simple to come up with a
multi-target solution.

Take a trivially simple app:

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="" 
    <s:Button skinClass="MyButtonSkin"/>

It references MyButtonSkin class, which might be defined as below:
MyButtonSkin.mxml (based on example at

<?xml version="1.0" encoding="utf-8"?>
<s:Skin xmlns:fx=""
xmlns:s="library://" alpha.disabled=".5"

    <s:Rect id="rect" radiusX="4" radiusY="4" top="0" right="0" bottom="0"

    <s:Label text="Button" .../> 

Notice that I have added
implements="org.apache.flex.compilectrl.INativeClass." When compiled with,
for example --target-javascript, the compiler will disregard the AS3 version
of MyButtonSkin, as it is marked as a native class. Instead, the compiler
will expect some form of JavaScript, CSS & HTML MyButtonSkin "bundle", which
it will link/merge or whatever with the generated JavaScript-based output.

The Button class still gets compiled to JavaScript (or .NET bytecode, C++ or
whatever we choose to target), but the actual rendering process is handled
natively in each case.

Would this approach work, or have I missed something important? Obviously
having classes implement an interface may not be the most elegant way of
handling this and maybe either a new language keyword or metadata could be
used instead. Also, this technique would mean that only spark components
could be targeted at anything other than the flash player, but I don't see
this as a bad thing. Are there any fundamental flaws with the idea though?


View raw message