flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject AW: AW: [FLEXJS] Strange Flat manifest
Date Thu, 19 May 2016 15:47:10 GMT
Hi Alex,

well I set the priorities differently ... so currently you would vote for code duplication
and I would vote for subclassing. We shouldn't just continue that path but should decide as
a project. If the project votes for code duplication I will try to adjust, but I wouldn't
simply go that path just because you on your own think it's the way to go.

You might get a teenieweenie bit of performance, but maintenance is a nightmare as you have
to post every minor change to every component "Copy-Paste-Derived" from that.

In general we should discuss design decisions a little more an not just implement what we
think is best ... that's ok for a POC but not the way we should do in general.


Von: Alex Harui <aharui@adobe.com>
Gesendet: Donnerstag, 19. Mai 2016 17:10:11
An: dev@flex.apache.org
Betreff: Re: AW: [FLEXJS] Strange Flat manifest

On 5/19/16, 7:01 AM, "Christofer Dutz" <christofer.dutz@c-ware.de> wrote:

>We already have enough duplicated code is my opinion on this.
>We shouldn't start duplicating stuff and should rather implement skinning
>the same way it was done in Flex4 ... or do it the way I did it for the
>Flat example by using the Flat components where I wanted them and using
>the normal ones where there weren't any Flat ones.

Well, in FlexJS I am promoting the idea of "component sets".  Many of the
SWCs will represent a set of UI widgets like Button, CheckBox, etc for a
particular JS UI framework.  We have pieces for CreateJS and Jquery
already.  HTML5 might have extra components only available in HTML5.  Flat
is sort of an attempt at Bootstrap (but needs more advanced CSS support
before it can really be Bootstrap).

Many of these component sets will be able to re-use the basic Label, for
example.  So that's why there is "duplication".  Now we could require that
component sets must subclass/wrap anything it borrows from the HTML SWC so
it has its own package, but each subclass costs a little bit in
download/startup and the compiler already supports this duplicate mapping
so I'd rather let folks leverage it and save a little.  Especially if the
only thing we need to do to make it easier for Maven is to populate the
catalog.xml with the mappings that aren't in the SWC.

Anyone is certainly welcome to use a mix of namespaces for their UI
widgets, but the advantage of using one is that you can remap the xmlns
and switch component sets that way.

Flex 4 skinning is inefficient:  it is two UIComponents for every
component (the main component and the Skin).  The MX/Spark port to FlexJS
will duplicate Flex 4 skinning and its inefficiencies, but I don't see a
reason to push that onto the JS frameworks we are trying to emulate.  In
FlexJS we are trying to thinly wrap existing JS behavior, and not force
Flash-isms into the JS code for performance reasons.  The MX/Spark port
will bring in some of the Flash-isms.  Of course, folks are free to code
up anything they want in their own component sets.


View raw message