flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik de Bruin <e...@ixsoftware.nl>
Subject Re: [FlexJS] Interfaces, DataGrids, new MXML codegen
Date Thu, 07 Nov 2013 16:56:52 GMT
Well, I figured that if we have structural parity between the two
frameworks, several things will happen:

- type checking becomes consistent: as soon as there is a different
inheritance/implementation chain on the JS side, things go
pear-shaped: how about 'myClass is Sprite'?

- the frameworks will become easier to develop and maintain: build it
on the AS side, and start the work on the JS side by copying the class
structure. Or better yet, run the AS through the compiler and start
with the JS output, that way you should be able to start with a
reasonable functional JS class ;-) This is really cool, by the way. I
put the entire AS framework through the compiler the other day and was
amazed at how clean and nearly usable the JS output was... it got me
thinking if we wouldn't want to just do the AS side (FlexJS style) and
then see what's missing on the JS side (mostly flash.* classes,
apparently). But that's for another time ;-)

The other way around (only do what's really needed on either side)
will get messy and obscure pretty soon, especially with the lack of a
good code discovery/completion tool on the JS side. I got confused by
the structural differences between the frameworks as it is right now,
and we're only getting started...


On Thu, Nov 7, 2013 at 5:45 PM, Alex Harui <aharui@adobe.com> wrote:
> On 11/7/13 7:49 AM, "Erik de Bruin" <erik@ixsoftware.nl> wrote:
>>> was last built by MXMLC and not Falcon (or was built by Falcon without
>>> -compiler.mxml.children-as-data flag).  Every once in a while, FB will
>>> suddenly re-build the SWF when you launch it.  Not sure why.  Om says it
>>> happens every time for him.  For me, I just run the external tool again
>>> and it goes away.
>>I figured as much, but the thing is, like Om, I haven't been able to
>>run it at all :-(
> Yeah.  Will have to figure this out some day.  The workflow shouldn't
> require special launch configs if we can avoid it.
>>Since next on my list is an attempt to get the class structure on the
>>JS side to match that on the AS side, it's not high priority for me,
>>but it would be nice to have to occasionally run a test on both side
>>of the aisle.
> I'd like to make sure we're on the same page on this.  Now that you've
> provided interfaces on the JS side I can see that we should use them more,
> but I don't think the set of superclasses and interfaces need to match
> exactly.  For example, we don't need a Sprite superclass in JS just
> because there is one under the covers on the AS side.  IMO, the only thing
> that needs to match is the "API Surface", the set of public APIs.
> Your thoughts?
> -Alex

Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

View raw message