You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2013/11/07 09:10:35 UTC
[FlexJS] Interfaces, DataGrids, new MXML codegen
Hi,
I uploaded a new FlexJSOverlay.zip to my people.a.o folder. You can
follow the instructions at [1] to try it out.
This version contains support for Interfaces on the JS side, thanks to
Erik de Bruin, and the beginnings of a DataGrid, thanks to Peter Ent. It
also contains an updated Falcon compiler that successfully used the new
MXML and DataBinding codegen to compile and start up an application that
has a 10MB SWF consisting of some 4000 compilation units.
November starts the Adobe Season of Giving, so I'm going to be spending
the next several days finishing up the BlazeDS donation and trying to get
other stuff donated, then I'll be working on better FB integration for
FlexJS (after I figure out which health insurance plan I should sign up
for).
-Alex
[1]
https://cwiki.apache.org/confluence/display/FLEX/Using+FlexJS+with+Adobe+Fl
ash+Builder
Re: [FlexJS] Interfaces, DataGrids, new MXML codegen
Posted by Erik de Bruin <er...@ixsoftware.nl>.
>> - 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 ;-)
>>
>
> Big +1 for this idea. If there is any chance I get to not write JavaScript
> directly, I want to make full use of it. Any chance you can publish your
> process for doing this? As an overly simple example, if I write a Chart
> component in AS, it would be so much easier if I go and replace the AS
> 'graphics' object to a JS 'canvas' or 'd3' object. Most other stuff should
> (hopefully) remain the same.
All I did was stuff 'FlexJSUIClasses.as' into FalconJx and watched it
churn out a sizeable part of the FlexJS SDK as JS... But not all of
it. And that is where the "for another time" comment comes in, we'd
probably have to parse some manifests in an ant build setup (or
something) to get the whole FlexJS SDK.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FlexJS] Interfaces, DataGrids, new MXML codegen
Posted by Alex Harui <ah...@adobe.com>.
On 11/7/13 10:27 AM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>On Thu, Nov 7, 2013 at 8:56 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>
>> 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'?
>>
>
>+1
>On the JS side, it should not cost us anything to have this kind of class
>inheritance hierarchy parity, right? Are we worried about performance in
>case of too much prototype chaining [1]?
Download size as well.
Internally, the AS side should be able to take full advantage of Sprite,
but we don't want the public API to be littered with all of Sprite,
otherwise we're back to emulating FP in the browser. I was thinking of
teaching the compiler to warn or error about certain Flash API usage in
certain classes.
>
>
>>
>> - 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 ;-)
>>
>
>Big +1 for this idea. If there is any chance I get to not write
>JavaScript
>directly, I want to make full use of it. Any chance you can publish your
>process for doing this? As an overly simple example, if I write a Chart
>component in AS, it would be so much easier if I go and replace the AS
>'graphics' object to a JS 'canvas' or 'd3' object. Most other stuff
>should
>(hopefully) remain the same.
Might work for some Charts, but if a chart needs clickable-moveable
pieces, it may need to be constructed out of Divs on the JS side.
Re: [FlexJS] Interfaces, DataGrids, new MXML codegen
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Thu, Nov 7, 2013 at 8:56 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> 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'?
>
+1
On the JS side, it should not cost us anything to have this kind of class
inheritance hierarchy parity, right? Are we worried about performance in
case of too much prototype chaining [1]?
>
> - 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 ;-)
>
Big +1 for this idea. If there is any chance I get to not write JavaScript
directly, I want to make full use of it. Any chance you can publish your
process for doing this? As an overly simple example, if I write a Chart
component in AS, it would be so much easier if I go and replace the AS
'graphics' object to a JS 'canvas' or 'd3' object. Most other stuff should
(hopefully) remain the same.
>
> 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...
>
> EdB
>
>
[1]
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Inheritance_and_the_prototype_chain
>
>
> On Thu, Nov 7, 2013 at 5:45 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >
> > On 11/7/13 7:49 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> >
> >>> was last built by MXMLC and not Falcon (or was built by Falcon without
> >>>the
> >>> -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
>
Re: [FlexJS] Interfaces, DataGrids, new MXML codegen
Posted by Alex Harui <ah...@adobe.com>.
I can certainly see that certain "higher-level" components might be able
to have the same structure and have the JS side generated by the compiler.
But it seems to me that at some point,you need your platform abstraction
layer and what happens underneath it will vary.
Are you really suggesting creating
Sprite->InteractiveObject->DisplayObject on the JS side? How would you do
it for the Button that wraps a Jquery or Dojo button? Would you really
want to wrap JS accessibility in something that looks like accImpl or
vice-versa? I know you "can" do it, but I would want each platform's
implementations to be optimal, otherwise we are trying to emulate FP in
the browser or vice versa, neither of which I think will be optimal.
So, a tool that compares the API surface of an AS and JS class would be
good, but I'm not sure it has to check base class ancestry and maybe
certain interfaces can be marked as exceptions?
-Alex
On 11/7/13 11:38 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>Oh oh oh, I got another one: refactoring... If both sides aren't
>equal, you'll never figure out what goes where in the new situation
>without too much trail and error.
>
>EdB
>
>
>
>On Thu, Nov 7, 2013 at 6:49 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>> On the parity issue: if we manage a proper introspection thing on the
>> JS side, we should - in case of parity - be able to set up an
>> automated way of checking both sides for completeness and sameness.
>>
>> EdB
>>
>>
>>
>> On Thu, Nov 7, 2013 at 5:56 PM, Erik de Bruin <er...@ixsoftware.nl>
>>wrote:
>>> 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...
>>>
>>> EdB
>>>
>>>
>>>
>>> On Thu, Nov 7, 2013 at 5:45 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>
>>>>
>>>> On 11/7/13 7:49 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>>
>>>>>> was last built by MXMLC and not Falcon (or was built by Falcon
>>>>>>without
>>>>>>the
>>>>>> -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
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>
>
>
>--
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl
Re: [FlexJS] Interfaces, DataGrids, new MXML codegen
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Oh oh oh, I got another one: refactoring... If both sides aren't
equal, you'll never figure out what goes where in the new situation
without too much trail and error.
EdB
On Thu, Nov 7, 2013 at 6:49 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> On the parity issue: if we manage a proper introspection thing on the
> JS side, we should - in case of parity - be able to set up an
> automated way of checking both sides for completeness and sameness.
>
> EdB
>
>
>
> On Thu, Nov 7, 2013 at 5:56 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>> 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...
>>
>> EdB
>>
>>
>>
>> On Thu, Nov 7, 2013 at 5:45 PM, Alex Harui <ah...@adobe.com> wrote:
>>>
>>>
>>> On 11/7/13 7:49 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>
>>>>> was last built by MXMLC and not Falcon (or was built by Falcon without
>>>>>the
>>>>> -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
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FlexJS] Interfaces, DataGrids, new MXML codegen
Posted by Erik de Bruin <er...@ixsoftware.nl>.
On the parity issue: if we manage a proper introspection thing on the
JS side, we should - in case of parity - be able to set up an
automated way of checking both sides for completeness and sameness.
EdB
On Thu, Nov 7, 2013 at 5:56 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> 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...
>
> EdB
>
>
>
> On Thu, Nov 7, 2013 at 5:45 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>>
>> On 11/7/13 7:49 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>
>>>> was last built by MXMLC and not Falcon (or was built by Falcon without
>>>>the
>>>> -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
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FlexJS] Interfaces, DataGrids, new MXML codegen
Posted by Erik de Bruin <er...@ixsoftware.nl>.
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...
EdB
On Thu, Nov 7, 2013 at 5:45 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 11/7/13 7:49 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>>> was last built by MXMLC and not Falcon (or was built by Falcon without
>>>the
>>> -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
Re: [FlexJS] Interfaces, DataGrids, new MXML codegen
Posted by Alex Harui <ah...@adobe.com>.
On 11/7/13 9:22 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>Ok, I have this working... It turns out that if you import the
>FlexJSUI project as a library and link to that in your test project,
>it works as advertised.
>
>Not too surprising: this is Alex's exact setup.
>
>So, another clue and another TODO item ;-)
There's more to it than just that, I think, but worth noting. Right now I
don't have FlexJSUI as a project in my workspace and most of the time it
just works.
-Alex
Re: [FlexJS] Interfaces, DataGrids, new MXML codegen
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Ok, I have this working... It turns out that if you import the
FlexJSUI project as a library and link to that in your test project,
it works as advertised.
Not too surprising: this is Alex's exact setup.
So, another clue and another TODO item ;-)
EdB
On Thu, Nov 7, 2013 at 5:20 PM, OmPrakash Muppirala
<bi...@gmail.com> wrote:
> On Nov 7, 2013 7:50 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>
>> > was last built by MXMLC and not Falcon (or was built by Falcon without
> the
>> > -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 :-(
>
> I managed to figure out a workaround for myself. You should be able to
> search for my previous [FLEXJS] emails about this.
>
> I added some info on the wiki page as well.
>
> If you are not able to find them, I will dig it out when I wake up
> completely :-)
>
> Thanks,
> Om
>
>>
>> Something to look into, as the number of people NOT able to run now
>> equal the number who can (figuring both you and Peter are able to run
>> it in Flash Builder).
>>
>> 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.
>>
>> EdB
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FlexJS] Interfaces, DataGrids, new MXML codegen
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Nov 7, 2013 7:50 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
> > was last built by MXMLC and not Falcon (or was built by Falcon without
the
> > -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 :-(
I managed to figure out a workaround for myself. You should be able to
search for my previous [FLEXJS] emails about this.
I added some info on the wiki page as well.
If you are not able to find them, I will dig it out when I wake up
completely :-)
Thanks,
Om
>
> Something to look into, as the number of people NOT able to run now
> equal the number who can (figuring both you and Peter are able to run
> it in Flash Builder).
>
> 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.
>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
Re: [FlexJS] Interfaces, DataGrids, new MXML codegen
Posted by Alex Harui <ah...@adobe.com>.
On 11/7/13 7:49 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>> was last built by MXMLC and not Falcon (or was built by Falcon without
>>the
>> -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
Re: [FlexJS] Interfaces, DataGrids, new MXML codegen
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> was last built by MXMLC and not Falcon (or was built by Falcon without the
> -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 :-(
Something to look into, as the number of people NOT able to run now
equal the number who can (figuring both you and Peter are able to run
it in Flash Builder).
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.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FlexJS] Interfaces, DataGrids, new MXML codegen
Posted by Alex Harui <ah...@adobe.com>.
On 11/7/13 3:42 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>Alex,
>
>I tried the new FlexJSOverlay and I encountered a few issues.
>
>First: the deploy.sh and setuplaunches.sh don't handle spaces in the
>file paths and don't handle relative paths. I've put the fixed files
>here:
>
>http://people.apache.org/~erikdebruin/flexjs/
Thanks.
>
>Second: the compiler.jar (Closure) you've added to the overlay seems
>to be a bit out of date. Replacing it with the latest version makes
>the various warnings generate by the most recent library go away.
OK, I'll look into upgrading.
>
>Third: when I use the overlay and import the correct launchers, and
>select 'Run/External Tools/FlexJS (Debug Build)', all seems well. But
>when I want to run it - it doesn't launch when I use the launcher - by
>selecting 'Run/Debug', I get the following error:
>
>ReferenceError: Error #1056: Cannot create property itemsFactory on
>mx.states.AddItems.
>at
>mx.states::AddItems/initializeFromObject()[/Users/aharui/git/flex/master/f
>lex-asjs/frameworks/as/src/mx/states/AddItems.as:61]
>at
>MyInitialView()[/Users/erik/Documents/ApacheFlex/git/flex-asjs/examples/Da
>taBindingTest/src/MyInitialView.mxml:23]
>at DataBindingTest/_DataBindingTest_MyInitialView1_c()
>at
>DataBindingTest()[/Users/erik/Documents/ApacheFlex/git/flex-asjs/examples/
>DataBindingTest/src/DataBindingTest.mxml:26]
>
>Any idea what I'm doing wrong?
Whenever you get an error running the SWF version, first thing to look for
is methods in the call stack ending with "_c()" or "_i()" like
"DataBindingTest/_DataBindingTest_MyInitialView1_c()". This means the SWF
was last built by MXMLC and not Falcon (or was built by Falcon without the
-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.
-Alex
Re: [FlexJS] Interfaces, DataGrids, new MXML codegen
Posted by Alex Harui <ah...@adobe.com>.
On 11/7/13 3:42 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>Alex,
>
>I tried the new FlexJSOverlay and I encountered a few issues.
>
>First: the deploy.sh and setuplaunches.sh don't handle spaces in the
>file paths and don't handle relative paths. I've put the fixed files
>here:
>
>http://people.apache.org/~erikdebruin/flexjs/
>
>Second: the compiler.jar (Closure) you've added to the overlay seems
>to be a bit out of date. Replacing it with the latest version makes
>the various warnings generate by the most recent library go away.
FYI, I updated the FlexJSOverlay.zip with the new shell scripts and
hopefully a later closure compiler.jar.
Thanks for these improvements,
-Alex
Re: [FlexJS] Interfaces, DataGrids, new MXML codegen
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Alex,
I tried the new FlexJSOverlay and I encountered a few issues.
First: the deploy.sh and setuplaunches.sh don't handle spaces in the
file paths and don't handle relative paths. I've put the fixed files
here:
http://people.apache.org/~erikdebruin/flexjs/
Second: the compiler.jar (Closure) you've added to the overlay seems
to be a bit out of date. Replacing it with the latest version makes
the various warnings generate by the most recent library go away.
Third: when I use the overlay and import the correct launchers, and
select 'Run/External Tools/FlexJS (Debug Build)', all seems well. But
when I want to run it - it doesn't launch when I use the launcher - by
selecting 'Run/Debug', I get the following error:
ReferenceError: Error #1056: Cannot create property itemsFactory on
mx.states.AddItems.
at mx.states::AddItems/initializeFromObject()[/Users/aharui/git/flex/master/flex-asjs/frameworks/as/src/mx/states/AddItems.as:61]
at MyInitialView()[/Users/erik/Documents/ApacheFlex/git/flex-asjs/examples/DataBindingTest/src/MyInitialView.mxml:23]
at DataBindingTest/_DataBindingTest_MyInitialView1_c()
at DataBindingTest()[/Users/erik/Documents/ApacheFlex/git/flex-asjs/examples/DataBindingTest/src/DataBindingTest.mxml:26]
Any idea what I'm doing wrong?
EdB
On Thu, Nov 7, 2013 at 9:10 AM, Alex Harui <ah...@adobe.com> wrote:
> Hi,
>
> I uploaded a new FlexJSOverlay.zip to my people.a.o folder. You can
> follow the instructions at [1] to try it out.
>
> This version contains support for Interfaces on the JS side, thanks to
> Erik de Bruin, and the beginnings of a DataGrid, thanks to Peter Ent. It
> also contains an updated Falcon compiler that successfully used the new
> MXML and DataBinding codegen to compile and start up an application that
> has a 10MB SWF consisting of some 4000 compilation units.
>
> November starts the Adobe Season of Giving, so I'm going to be spending
> the next several days finishing up the BlazeDS donation and trying to get
> other stuff donated, then I'll be working on better FB integration for
> FlexJS (after I figure out which health insurance plan I should sign up
> for).
>
> -Alex
>
> [1]
> https://cwiki.apache.org/confluence/display/FLEX/Using+FlexJS+with+Adobe+Fl
> ash+Builder
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl