Well, first off, thanks for motivating me to spend more time thinking about
skinning. Honestly, I don't have a formal plan and your input is quite
welcome. I spent a fair amount of time mulling over how to re-use as much
of existing spark skins as possible and how to leverage your FXG->SVG work.
On 3/25/13 6:28 PM, "Om" <bigosma...@gmail.com> wrote:
>>>
>> Well, if you want to re-use Spark skins, then FlexJS is not for you.
>
> I don't want to reuse spark skins. I just want to use the spark paradigm
> for skinning. I am using the current spark skins as examples for the POC.
I'm not sure what it means if you don't want to reuse spark skins but want
to use the spark paradigm. What are the key pieces?
>
> FlexJS
>> is a rewrite of Flex and the skinning model will likely be different
> because
>> I want to try to fix the problems of Spark skins like the skin part
>> contract, the extra display object, and the fact that most default skins
> had
>> code in them. Over time, we can add enough alternative beads to fully
> mimic
>> Spark Skins, but I really don't want to make that the default pattern for
>> FlexJS.
>
> As long as we use MXMLG for the skins I would be happy. Do you still plan
> to use MXMLG in FlexJS?
I hadn't given it much thought. At minimum, we could create components like
Rect, Line, Path like we have for Button, CheckBox and Label. They would
inject SVG into the DOM as appropriate.
But in thinking more about it, your transform of MXMLG or FXG to SVG is
essentially an optimization. The reason I say that is because, if you start
from SparkSkin, you have the problem that in more complex components, the
skin is not pure MXMLG/FXG, it is comprised of other top-level components.
It is only in cases where you have an uninterrupted stream of graphics that
you can apply this transform. I guess we could make the compiler that
smart, but that sounds like advanced work.
One way I think about developing FlexJS is that we are trying to identify
the smallest, most self-contained, best practice for doing things in HTML
(whether it is skinning, drag-drop, effects) and then designing an
ActionScript equivalent for it, and then tweaking both sides to make it more
Flex-like. At least for now, that is the most efficient way to get more
components up and running faster because there is less mucking around in JS
trying to get it to do something that was easy in Flash.
So, I need to research more about how skinning works in HTML5, but I have
this vague recollection that skins in HTML5 are entirely graphics. IOW, a
complex component comprised of subcomponents doesn't have a skin that
describes those sub-components like Spark does. Instead, the set of
sub-components is fixed and you can alter the visuals of those
sub-components via CSS. For example, you use advanced CSS selectors to set
the visuals for a Button in a ComboBox.
I also need to understand how an HTML5 button skin changes its visuals with
hover/down/selected/focused/emphasized. That would also educate how we set
up a skinning model for FlexJS.
And something like that is more in tune with FlexJS. Today, the AS
components have a view bead that determines the subcomponents. Those
subcomponents have their own view beads. The leaves of that tree of view
beads is entirely graphics (today in AS, next stop for me was bitmaps, you
are welcome to take on MXML or FXG or some vector description). Someday,
I'll get enough CSS working so that you can set the view beads at the leaves
of the tree, and then we can say that you can define those view beads
entirely in graphics with certain restrictions, like no sub-components.
Maybe we'll give that a separate file suffix, then the compiler can know to
run your transform on it.
Thoughts on that?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
