New Flex to JS project

[Erik de Bruin <er...@ixsoftware.nl>]

Hi,

I'm working on creating a way to publish vanilla Flex SDK projects to
JavaScript on latest gen browsers. This project consists of several sub
projects, and I'm wondering what is the best way forward with regard to
contributing them:

1) two new namespaces and accompanying projects in the main Flex SDK:
vf2js_mx and vf2js_s. These namespaces will contain shim objects for (you
guessed it) MX and Spark components.

2) two new code paths in FalconJX: one for AS and one for MXML

3) a new JavaScript library for the components and shims for AS classes

4) a testing framework for the JS components, loosely based on Marmotinni

Questions:

A - I would very much like to work in the 'develop' branches of the
projects involved, but especially on the part of '1)' I'm not sure if I did
it right. All tests I can think of seem to pass, but maybe someone has the
time to do a code review on a branch that I can publish?

B - In order for this to work, FalconJX needs to be part of the regular SDK
distribution. Folks who did this on the FlexJS overlay: what does it take
to make FalconJX part of the SDK?

That's it, for now :-)

Thanks,

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

Re: New Flex to JS project

[Erik de Bruin <er...@ixsoftware.nl>]

>
> > B - In order for this to work, FalconJX needs to be part of the regular
> SDK
> > distribution.
> Why not make it an optional download via the installer ant script /
> installer?
>

Because that is just what this project needs, more complexity.

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

Re: New Flex to JS project

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> A - I would very much like to work in the 'develop' branches of the
> projects involved

Would be better if you work in a branch, if you;re worried about getting out of date just merge develop into your branch every now and then. Git tools eg source tree can make this easier for you.

> B - In order for this to work, FalconJX needs to be part of the regular SDK
> distribution.
Why not make it an optional download via the installer ant script / installer?

Thanks,
Justin

Re: New Flex to JS project

[Erik de Bruin <er...@ixsoftware.nl>]

As soon as I know what steps there are, sure ;-)

I'll create a guide to using this stuff. The idea is to keep it simple:
nothing special required on the MXML/AS side (business as usual, vanilla
Flex), with an FB 'External Tool' to launch the JS publishing. The
Installer should be able to handle most of the client side setup. For
developers, things should also be relatively straight forward: create a
shim for an MX or Spark component in either one of the new namespaces and
then focus on implementing it's public API in JS. "That's all" :-P

This will take substantial work on the FalconJX compiler, as I aim to use
the Google Closure Tools to the max in the JS output and framework, and I
plan to support only current versions of the major browsers, allowing me to
do some ES5 and ES6 trickery ;-)

EdB



On Wed, Jul 2, 2014 at 3:53 PM, jude <fl...@gmail.com> wrote:

> If applicable please add the steps you take to the wiki so others can know
> how to get started as well. IE, something like this for setting up your
> environment,
> https://cwiki.apache.org/confluence/display/FLEX/1.+Setting+up+the+SDK.
> There may be something added since I last checked.
>
>
> On Wed, Jul 2, 2014 at 5:57 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>
> > Merge sounds like the way to go... Let's not revisit the whole Git usage
> > thread(s) ;-)
> >
> > EdB
> >
> >
> >
> >
> > On Wed, Jul 2, 2014 at 10:39 AM, OmPrakash Muppirala <
> bigosmallm@gmail.com
> > >
> > wrote:
> >
> > > On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz <
> > christofer.dutz@c-ware.de
> > > >
> > > wrote:
> > >
> > > > You don't loose the history when rebasing ... you sort of serialize
> it.
> > > Ok
> > > > the order of commits is messed up, but I never really care about
> this.
> > > > It might look less interesting in a GIT visualization tool where you
> > > could
> > > > see tons of different branches and merges, but it should be a lot
> > easier
> > > to
> > > > maintain, as a serial history is definiely the one that causes the
> > least
> > > > trouble ;-)
> > > >
> > > > In IntelliJ I usually set my "update" operation to "Rebase" using
> > "Stash"
> > > > and have never really had any problems. One click on "Update SCM"
> and I
> > > > still work on my featrue branch, but pull in all changes from develop
> > or
> > > > whatever branch I branched from. When it comes to commit, the commit
> > > itself
> > > > should be a fast-forward commit.
> > > >
> > > > But I guess there are several flavours here ... depending on the guy
> > you
> > > > ask or listen too, a different way will probably be recommended. I
> > guess
> > > > manually merging changes from develop to the feature branch is as
> valid
> > > as
> > > > rebasing, but I think rebasing is easier and causes less trouble, but
> > you
> > > > loose the "real-order" of commits (Which I don't really care about).
> > > >
> > > > Chris
> > > >
> > >
> > > I will let Erik decide if he wants to rebase or merge.  My
> recommendation
> > > is that, since it is a feature branch, it will be useful to retain the
> > > commit history intact.  So, merge makes sense.
> > >
> > > If Erik does not want to keep the commit history intact, rebase will
> just
> > > work fine.
> > >
> > > Thanks,
> > > Om
> > >
> > >
> > > >
> > > >
> > > >
> > > > ________________________________________
> > > > Von: omuppi1@gmail.com <om...@gmail.com> im Auftrag von OmPrakash
> > > > Muppirala <bi...@gmail.com>
> > > > Gesendet: Mittwoch, 2. Juli 2014 10:25
> > > > An: dev@flex.apache.org
> > > > Betreff: Re: New Flex to JS project
> > > >
> > > > On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin <er...@ixsoftware.nl>
> > > wrote:
> > > >
> > > > > Ok, just checking:
> > > > >
> > > > > I create a local branch, let's call it 'vf2js', off
> > 'origin/develop'. I
> > > > > select this as my active branch.
> > > >
> > > >
> > > > So far so good.
> > > >
> > > >
> > > > > If I then 'rebase', all changes that have
> > > > > been made to 'origin/develop' will be pulled into my local branch?
> So
> > > > far,
> > > > > so good.
> > > >
> > > >
> > > > Rebase at this point is not required.  The code from origin/develop
> is
> > > > already in the 'vf2js' branch.  You will need to 'merge' from
> > > > origin/develop into vf2js once in a while to make sure that you are
> in
> > > sync
> > > > with whats happening with origin/develop.  When you are done with the
> > > > feature, you just 'merge' vf2js into develop.  If the history of the
> > > > 'vf2js' branch is not important, then you use the rebase option.
> > > >
> > > >
> > > > > But now I want the world to see what's in my local vf2js branch,
> > > > > so I 'publish' it. Is keeping the remote copy of my local branch up
> > to
> > > > date
> > > > > just a question of 'pushing' all commits to that remote branch?
> > > >
> > > >
> > > > Yes, that is correct.
> > > >
> > > >
> > > > > Will
> > > > > changes that come from the remote 'develop' via my local 'vf2js'
> also
> > > in
> > > > > the remote 'vf2js' that way?
> > > > >
> > > >
> > > > Cannot compute.  Can you rephrase the question?
> > > >
> > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > > EdB
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz <
> > > > christofer.dutz@c-ware.de
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > No effort at all ... that's what GIT rebase is for.
> > > > > >
> > > > > > You can think of this sort of an automated "Create-Patch, Revert,
> > > > Update,
> > > > > > Apply Patch" ... if all goes well, it's just this one command, if
> > > there
> > > > > are
> > > > > > conflicts, you get the usual conflict editor you would get anyway
> > if
> > > > you
> > > > > > created conflicts on develop.
> > > > > >
> > > > > > Chris
> > > > > >
> > > > > >
> > > > > > ________________________________________
> > > > > > Von: Erik de Bruin <er...@ixsoftware.nl>
> > > > > > Gesendet: Mittwoch, 2. Juli 2014 09:50
> > > > > > An: dev@flex.apache.org
> > > > > > Betreff: Re: New Flex to JS project
> > > > > >
> > > > > > Hi Chris,
> > > > > >
> > > > > > Thanks for the feedback.
> > > > > >
> > > > > > I'm talking about FalconJX, not Falcon. The latter is the "new"
> SWF
> > > > > > compiler, the former is the Flex to JavaScript cross compiler.
> > > > > >
> > > > > > I guess a feature branch might work... But I'm afraid that
> keeping
> > > that
> > > > > > branch up to date with the 'develop' branch will add extra work.
> > How
> > > to
> > > > > > best handle that part, so I don't spend what little time I have
> on
> > > Git
> > > > > > stuff instead of code?
> > > > > >
> > > > > > EdB
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz <
> > > > > christofer.dutz@c-ware.de
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I think the reason for the overlay is that by this we are
> > tricking
> > > > the
> > > > > > > FlashBuilder to use Falcon instead of the old compiler.
> > > > > > > It should be possible to have Falcon separate from the normal
> > > > compiler.
> > > > > > > It's just that FlashBuilder will probably not be albe to use it
> > > that
> > > > > way.
> > > > > > > Probably IntelliJ would support this withn a few hours,
> Flexmojos
> > > > > within
> > > > > > a
> > > > > > > few weeks and FlashBuilder never ;-)
> > > > > > >
> > > > > > > You shouldn't implement this in the develop branch but create a
> > > > > > > feature-branch instead that forks off the develop branch. This
> > way
> > > > your
> > > > > > > changes are available to anyone interested and as soon as the
> > > feature
> > > > > is
> > > > > > > finished, you merge it back to develop.
> > > > > > >
> > > > > > > Chris
> > > > > > > ________________________________________
> > > > > > > Von: Erik de Bruin <er...@ixsoftware.nl>
> > > > > > > Gesendet: Mittwoch, 2. Juli 2014 09:33
> > > > > > > An: dev@flex.apache.org
> > > > > > > Betreff: New Flex to JS project
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I'm working on creating a way to publish vanilla Flex SDK
> > projects
> > > to
> > > > > > > JavaScript on latest gen browsers. This project consists of
> > several
> > > > sub
> > > > > > > projects, and I'm wondering what is the best way forward with
> > > regard
> > > > to
> > > > > > > contributing them:
> > > > > > >
> > > > > > > 1) two new namespaces and accompanying projects in the main
> Flex
> > > SDK:
> > > > > > > vf2js_mx and vf2js_s. These namespaces will contain shim
> objects
> > > for
> > > > > (you
> > > > > > > guessed it) MX and Spark components.
> > > > > > >
> > > > > > > 2) two new code paths in FalconJX: one for AS and one for MXML
> > > > > > >
> > > > > > > 3) a new JavaScript library for the components and shims for AS
> > > > classes
> > > > > > >
> > > > > > > 4) a testing framework for the JS components, loosely based on
> > > > > Marmotinni
> > > > > > >
> > > > > > > Questions:
> > > > > > >
> > > > > > > A - I would very much like to work in the 'develop' branches of
> > the
> > > > > > > projects involved, but especially on the part of '1)' I'm not
> > sure
> > > > if I
> > > > > > did
> > > > > > > it right. All tests I can think of seem to pass, but maybe
> > someone
> > > > has
> > > > > > the
> > > > > > > time to do a code review on a branch that I can publish?
> > > > > > >
> > > > > > > B - In order for this to work, FalconJX needs to be part of the
> > > > regular
> > > > > > SDK
> > > > > > > distribution. Folks who did this on the FlexJS overlay: what
> does
> > > it
> > > > > take
> > > > > > > to make FalconJX part of the SDK?
> > > > > > >
> > > > > > > That's it, for now :-)
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > 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
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 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: New Flex to JS project

[jude <fl...@gmail.com>]

If applicable please add the steps you take to the wiki so others can know
how to get started as well. IE, something like this for setting up your
environment,
https://cwiki.apache.org/confluence/display/FLEX/1.+Setting+up+the+SDK.
There may be something added since I last checked.


On Wed, Jul 2, 2014 at 5:57 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:

> Merge sounds like the way to go... Let's not revisit the whole Git usage
> thread(s) ;-)
>
> EdB
>
>
>
>
> On Wed, Jul 2, 2014 at 10:39 AM, OmPrakash Muppirala <bigosmallm@gmail.com
> >
> wrote:
>
> > On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz <
> christofer.dutz@c-ware.de
> > >
> > wrote:
> >
> > > You don't loose the history when rebasing ... you sort of serialize it.
> > Ok
> > > the order of commits is messed up, but I never really care about this.
> > > It might look less interesting in a GIT visualization tool where you
> > could
> > > see tons of different branches and merges, but it should be a lot
> easier
> > to
> > > maintain, as a serial history is definiely the one that causes the
> least
> > > trouble ;-)
> > >
> > > In IntelliJ I usually set my "update" operation to "Rebase" using
> "Stash"
> > > and have never really had any problems. One click on "Update SCM" and I
> > > still work on my featrue branch, but pull in all changes from develop
> or
> > > whatever branch I branched from. When it comes to commit, the commit
> > itself
> > > should be a fast-forward commit.
> > >
> > > But I guess there are several flavours here ... depending on the guy
> you
> > > ask or listen too, a different way will probably be recommended. I
> guess
> > > manually merging changes from develop to the feature branch is as valid
> > as
> > > rebasing, but I think rebasing is easier and causes less trouble, but
> you
> > > loose the "real-order" of commits (Which I don't really care about).
> > >
> > > Chris
> > >
> >
> > I will let Erik decide if he wants to rebase or merge.  My recommendation
> > is that, since it is a feature branch, it will be useful to retain the
> > commit history intact.  So, merge makes sense.
> >
> > If Erik does not want to keep the commit history intact, rebase will just
> > work fine.
> >
> > Thanks,
> > Om
> >
> >
> > >
> > >
> > >
> > > ________________________________________
> > > Von: omuppi1@gmail.com <om...@gmail.com> im Auftrag von OmPrakash
> > > Muppirala <bi...@gmail.com>
> > > Gesendet: Mittwoch, 2. Juli 2014 10:25
> > > An: dev@flex.apache.org
> > > Betreff: Re: New Flex to JS project
> > >
> > > On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin <er...@ixsoftware.nl>
> > wrote:
> > >
> > > > Ok, just checking:
> > > >
> > > > I create a local branch, let's call it 'vf2js', off
> 'origin/develop'. I
> > > > select this as my active branch.
> > >
> > >
> > > So far so good.
> > >
> > >
> > > > If I then 'rebase', all changes that have
> > > > been made to 'origin/develop' will be pulled into my local branch? So
> > > far,
> > > > so good.
> > >
> > >
> > > Rebase at this point is not required.  The code from origin/develop is
> > > already in the 'vf2js' branch.  You will need to 'merge' from
> > > origin/develop into vf2js once in a while to make sure that you are in
> > sync
> > > with whats happening with origin/develop.  When you are done with the
> > > feature, you just 'merge' vf2js into develop.  If the history of the
> > > 'vf2js' branch is not important, then you use the rebase option.
> > >
> > >
> > > > But now I want the world to see what's in my local vf2js branch,
> > > > so I 'publish' it. Is keeping the remote copy of my local branch up
> to
> > > date
> > > > just a question of 'pushing' all commits to that remote branch?
> > >
> > >
> > > Yes, that is correct.
> > >
> > >
> > > > Will
> > > > changes that come from the remote 'develop' via my local 'vf2js' also
> > in
> > > > the remote 'vf2js' that way?
> > > >
> > >
> > > Cannot compute.  Can you rephrase the question?
> > >
> > >
> > > >
> > > > Thanks,
> > > >
> > > > EdB
> > > >
> > > >
> > > >
> > > > On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz <
> > > christofer.dutz@c-ware.de
> > > > >
> > > > wrote:
> > > >
> > > > > No effort at all ... that's what GIT rebase is for.
> > > > >
> > > > > You can think of this sort of an automated "Create-Patch, Revert,
> > > Update,
> > > > > Apply Patch" ... if all goes well, it's just this one command, if
> > there
> > > > are
> > > > > conflicts, you get the usual conflict editor you would get anyway
> if
> > > you
> > > > > created conflicts on develop.
> > > > >
> > > > > Chris
> > > > >
> > > > >
> > > > > ________________________________________
> > > > > Von: Erik de Bruin <er...@ixsoftware.nl>
> > > > > Gesendet: Mittwoch, 2. Juli 2014 09:50
> > > > > An: dev@flex.apache.org
> > > > > Betreff: Re: New Flex to JS project
> > > > >
> > > > > Hi Chris,
> > > > >
> > > > > Thanks for the feedback.
> > > > >
> > > > > I'm talking about FalconJX, not Falcon. The latter is the "new" SWF
> > > > > compiler, the former is the Flex to JavaScript cross compiler.
> > > > >
> > > > > I guess a feature branch might work... But I'm afraid that keeping
> > that
> > > > > branch up to date with the 'develop' branch will add extra work.
> How
> > to
> > > > > best handle that part, so I don't spend what little time I have on
> > Git
> > > > > stuff instead of code?
> > > > >
> > > > > EdB
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz <
> > > > christofer.dutz@c-ware.de
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > I think the reason for the overlay is that by this we are
> tricking
> > > the
> > > > > > FlashBuilder to use Falcon instead of the old compiler.
> > > > > > It should be possible to have Falcon separate from the normal
> > > compiler.
> > > > > > It's just that FlashBuilder will probably not be albe to use it
> > that
> > > > way.
> > > > > > Probably IntelliJ would support this withn a few hours, Flexmojos
> > > > within
> > > > > a
> > > > > > few weeks and FlashBuilder never ;-)
> > > > > >
> > > > > > You shouldn't implement this in the develop branch but create a
> > > > > > feature-branch instead that forks off the develop branch. This
> way
> > > your
> > > > > > changes are available to anyone interested and as soon as the
> > feature
> > > > is
> > > > > > finished, you merge it back to develop.
> > > > > >
> > > > > > Chris
> > > > > > ________________________________________
> > > > > > Von: Erik de Bruin <er...@ixsoftware.nl>
> > > > > > Gesendet: Mittwoch, 2. Juli 2014 09:33
> > > > > > An: dev@flex.apache.org
> > > > > > Betreff: New Flex to JS project
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I'm working on creating a way to publish vanilla Flex SDK
> projects
> > to
> > > > > > JavaScript on latest gen browsers. This project consists of
> several
> > > sub
> > > > > > projects, and I'm wondering what is the best way forward with
> > regard
> > > to
> > > > > > contributing them:
> > > > > >
> > > > > > 1) two new namespaces and accompanying projects in the main Flex
> > SDK:
> > > > > > vf2js_mx and vf2js_s. These namespaces will contain shim objects
> > for
> > > > (you
> > > > > > guessed it) MX and Spark components.
> > > > > >
> > > > > > 2) two new code paths in FalconJX: one for AS and one for MXML
> > > > > >
> > > > > > 3) a new JavaScript library for the components and shims for AS
> > > classes
> > > > > >
> > > > > > 4) a testing framework for the JS components, loosely based on
> > > > Marmotinni
> > > > > >
> > > > > > Questions:
> > > > > >
> > > > > > A - I would very much like to work in the 'develop' branches of
> the
> > > > > > projects involved, but especially on the part of '1)' I'm not
> sure
> > > if I
> > > > > did
> > > > > > it right. All tests I can think of seem to pass, but maybe
> someone
> > > has
> > > > > the
> > > > > > time to do a code review on a branch that I can publish?
> > > > > >
> > > > > > B - In order for this to work, FalconJX needs to be part of the
> > > regular
> > > > > SDK
> > > > > > distribution. Folks who did this on the FlexJS overlay: what does
> > it
> > > > take
> > > > > > to make FalconJX part of the SDK?
> > > > > >
> > > > > > That's it, for now :-)
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > 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
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > 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: New Flex to JS project

[Erik de Bruin <er...@ixsoftware.nl>]

Merge sounds like the way to go... Let's not revisit the whole Git usage
thread(s) ;-)

EdB




On Wed, Jul 2, 2014 at 10:39 AM, OmPrakash Muppirala <bi...@gmail.com>
wrote:

> On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz <christofer.dutz@c-ware.de
> >
> wrote:
>
> > You don't loose the history when rebasing ... you sort of serialize it.
> Ok
> > the order of commits is messed up, but I never really care about this.
> > It might look less interesting in a GIT visualization tool where you
> could
> > see tons of different branches and merges, but it should be a lot easier
> to
> > maintain, as a serial history is definiely the one that causes the least
> > trouble ;-)
> >
> > In IntelliJ I usually set my "update" operation to "Rebase" using "Stash"
> > and have never really had any problems. One click on "Update SCM" and I
> > still work on my featrue branch, but pull in all changes from develop or
> > whatever branch I branched from. When it comes to commit, the commit
> itself
> > should be a fast-forward commit.
> >
> > But I guess there are several flavours here ... depending on the guy you
> > ask or listen too, a different way will probably be recommended. I guess
> > manually merging changes from develop to the feature branch is as valid
> as
> > rebasing, but I think rebasing is easier and causes less trouble, but you
> > loose the "real-order" of commits (Which I don't really care about).
> >
> > Chris
> >
>
> I will let Erik decide if he wants to rebase or merge.  My recommendation
> is that, since it is a feature branch, it will be useful to retain the
> commit history intact.  So, merge makes sense.
>
> If Erik does not want to keep the commit history intact, rebase will just
> work fine.
>
> Thanks,
> Om
>
>
> >
> >
> >
> > ________________________________________
> > Von: omuppi1@gmail.com <om...@gmail.com> im Auftrag von OmPrakash
> > Muppirala <bi...@gmail.com>
> > Gesendet: Mittwoch, 2. Juli 2014 10:25
> > An: dev@flex.apache.org
> > Betreff: Re: New Flex to JS project
> >
> > On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin <er...@ixsoftware.nl>
> wrote:
> >
> > > Ok, just checking:
> > >
> > > I create a local branch, let's call it 'vf2js', off 'origin/develop'. I
> > > select this as my active branch.
> >
> >
> > So far so good.
> >
> >
> > > If I then 'rebase', all changes that have
> > > been made to 'origin/develop' will be pulled into my local branch? So
> > far,
> > > so good.
> >
> >
> > Rebase at this point is not required.  The code from origin/develop is
> > already in the 'vf2js' branch.  You will need to 'merge' from
> > origin/develop into vf2js once in a while to make sure that you are in
> sync
> > with whats happening with origin/develop.  When you are done with the
> > feature, you just 'merge' vf2js into develop.  If the history of the
> > 'vf2js' branch is not important, then you use the rebase option.
> >
> >
> > > But now I want the world to see what's in my local vf2js branch,
> > > so I 'publish' it. Is keeping the remote copy of my local branch up to
> > date
> > > just a question of 'pushing' all commits to that remote branch?
> >
> >
> > Yes, that is correct.
> >
> >
> > > Will
> > > changes that come from the remote 'develop' via my local 'vf2js' also
> in
> > > the remote 'vf2js' that way?
> > >
> >
> > Cannot compute.  Can you rephrase the question?
> >
> >
> > >
> > > Thanks,
> > >
> > > EdB
> > >
> > >
> > >
> > > On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz <
> > christofer.dutz@c-ware.de
> > > >
> > > wrote:
> > >
> > > > No effort at all ... that's what GIT rebase is for.
> > > >
> > > > You can think of this sort of an automated "Create-Patch, Revert,
> > Update,
> > > > Apply Patch" ... if all goes well, it's just this one command, if
> there
> > > are
> > > > conflicts, you get the usual conflict editor you would get anyway if
> > you
> > > > created conflicts on develop.
> > > >
> > > > Chris
> > > >
> > > >
> > > > ________________________________________
> > > > Von: Erik de Bruin <er...@ixsoftware.nl>
> > > > Gesendet: Mittwoch, 2. Juli 2014 09:50
> > > > An: dev@flex.apache.org
> > > > Betreff: Re: New Flex to JS project
> > > >
> > > > Hi Chris,
> > > >
> > > > Thanks for the feedback.
> > > >
> > > > I'm talking about FalconJX, not Falcon. The latter is the "new" SWF
> > > > compiler, the former is the Flex to JavaScript cross compiler.
> > > >
> > > > I guess a feature branch might work... But I'm afraid that keeping
> that
> > > > branch up to date with the 'develop' branch will add extra work. How
> to
> > > > best handle that part, so I don't spend what little time I have on
> Git
> > > > stuff instead of code?
> > > >
> > > > EdB
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz <
> > > christofer.dutz@c-ware.de
> > > > >
> > > > wrote:
> > > >
> > > > > I think the reason for the overlay is that by this we are tricking
> > the
> > > > > FlashBuilder to use Falcon instead of the old compiler.
> > > > > It should be possible to have Falcon separate from the normal
> > compiler.
> > > > > It's just that FlashBuilder will probably not be albe to use it
> that
> > > way.
> > > > > Probably IntelliJ would support this withn a few hours, Flexmojos
> > > within
> > > > a
> > > > > few weeks and FlashBuilder never ;-)
> > > > >
> > > > > You shouldn't implement this in the develop branch but create a
> > > > > feature-branch instead that forks off the develop branch. This way
> > your
> > > > > changes are available to anyone interested and as soon as the
> feature
> > > is
> > > > > finished, you merge it back to develop.
> > > > >
> > > > > Chris
> > > > > ________________________________________
> > > > > Von: Erik de Bruin <er...@ixsoftware.nl>
> > > > > Gesendet: Mittwoch, 2. Juli 2014 09:33
> > > > > An: dev@flex.apache.org
> > > > > Betreff: New Flex to JS project
> > > > >
> > > > > Hi,
> > > > >
> > > > > I'm working on creating a way to publish vanilla Flex SDK projects
> to
> > > > > JavaScript on latest gen browsers. This project consists of several
> > sub
> > > > > projects, and I'm wondering what is the best way forward with
> regard
> > to
> > > > > contributing them:
> > > > >
> > > > > 1) two new namespaces and accompanying projects in the main Flex
> SDK:
> > > > > vf2js_mx and vf2js_s. These namespaces will contain shim objects
> for
> > > (you
> > > > > guessed it) MX and Spark components.
> > > > >
> > > > > 2) two new code paths in FalconJX: one for AS and one for MXML
> > > > >
> > > > > 3) a new JavaScript library for the components and shims for AS
> > classes
> > > > >
> > > > > 4) a testing framework for the JS components, loosely based on
> > > Marmotinni
> > > > >
> > > > > Questions:
> > > > >
> > > > > A - I would very much like to work in the 'develop' branches of the
> > > > > projects involved, but especially on the part of '1)' I'm not sure
> > if I
> > > > did
> > > > > it right. All tests I can think of seem to pass, but maybe someone
> > has
> > > > the
> > > > > time to do a code review on a branch that I can publish?
> > > > >
> > > > > B - In order for this to work, FalconJX needs to be part of the
> > regular
> > > > SDK
> > > > > distribution. Folks who did this on the FlexJS overlay: what does
> it
> > > take
> > > > > to make FalconJX part of the SDK?
> > > > >
> > > > > That's it, for now :-)
> > > > >
> > > > > Thanks,
> > > > >
> > > > > 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
> > > >
> > >
> > >
> > >
> > > --
> > > 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: New Flex to JS project

[OmPrakash Muppirala <bi...@gmail.com>]

On Jul 2, 2014 8:21 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
> On git: let's assume I work on these branches for 6 months (while keeping
> them up to date with develop). How much of a hassle will it be to merge
> them back into their respective 'develop' branches?

That depends on what files you touch and what others touch in develop.  If
there are a lot of conflicts, merging after 6 months could get hairy.

But then, if you keep merging develop into your branch once in a while, you
can keep resolving the small set of potential conflicts as you go on.  In
then end you will probably have no conflicts to resolve.  You can merge in
a matter of minutes.

Thanks,
Om

>
> EdB
>
>
>
> On Wed, Jul 2, 2014 at 10:39 AM, OmPrakash Muppirala <bigosmallm@gmail.com
>
> wrote:
>
> > On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz <
christofer.dutz@c-ware.de
> > >
> > wrote:
> >
> > > You don't loose the history when rebasing ... you sort of serialize
it.
> > Ok
> > > the order of commits is messed up, but I never really care about this.
> > > It might look less interesting in a GIT visualization tool where you
> > could
> > > see tons of different branches and merges, but it should be a lot
easier
> > to
> > > maintain, as a serial history is definiely the one that causes the
least
> > > trouble ;-)
> > >
> > > In IntelliJ I usually set my "update" operation to "Rebase" using
"Stash"
> > > and have never really had any problems. One click on "Update SCM" and
I
> > > still work on my featrue branch, but pull in all changes from develop
or
> > > whatever branch I branched from. When it comes to commit, the commit
> > itself
> > > should be a fast-forward commit.
> > >
> > > But I guess there are several flavours here ... depending on the guy
you
> > > ask or listen too, a different way will probably be recommended. I
guess
> > > manually merging changes from develop to the feature branch is as
valid
> > as
> > > rebasing, but I think rebasing is easier and causes less trouble, but
you
> > > loose the "real-order" of commits (Which I don't really care about).
> > >
> > > Chris
> > >
> >
> > I will let Erik decide if he wants to rebase or merge.  My
recommendation
> > is that, since it is a feature branch, it will be useful to retain the
> > commit history intact.  So, merge makes sense.
> >
> > If Erik does not want to keep the commit history intact, rebase will
just
> > work fine.
> >
> > Thanks,
> > Om
> >
> >
> > >
> > >
> > >
> > > ________________________________________
> > > Von: omuppi1@gmail.com <om...@gmail.com> im Auftrag von OmPrakash
> > > Muppirala <bi...@gmail.com>
> > > Gesendet: Mittwoch, 2. Juli 2014 10:25
> > > An: dev@flex.apache.org
> > > Betreff: Re: New Flex to JS project
> > >
> > > On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin <er...@ixsoftware.nl>
> > wrote:
> > >
> > > > Ok, just checking:
> > > >
> > > > I create a local branch, let's call it 'vf2js', off
'origin/develop'. I
> > > > select this as my active branch.
> > >
> > >
> > > So far so good.
> > >
> > >
> > > > If I then 'rebase', all changes that have
> > > > been made to 'origin/develop' will be pulled into my local branch?
So
> > > far,
> > > > so good.
> > >
> > >
> > > Rebase at this point is not required.  The code from origin/develop is
> > > already in the 'vf2js' branch.  You will need to 'merge' from
> > > origin/develop into vf2js once in a while to make sure that you are in
> > sync
> > > with whats happening with origin/develop.  When you are done with the
> > > feature, you just 'merge' vf2js into develop.  If the history of the
> > > 'vf2js' branch is not important, then you use the rebase option.
> > >
> > >
> > > > But now I want the world to see what's in my local vf2js branch,
> > > > so I 'publish' it. Is keeping the remote copy of my local branch up
to
> > > date
> > > > just a question of 'pushing' all commits to that remote branch?
> > >
> > >
> > > Yes, that is correct.
> > >
> > >
> > > > Will
> > > > changes that come from the remote 'develop' via my local 'vf2js'
also
> > in
> > > > the remote 'vf2js' that way?
> > > >
> > >
> > > Cannot compute.  Can you rephrase the question?
> > >
> > >
> > > >
> > > > Thanks,
> > > >
> > > > EdB
> > > >
> > > >
> > > >
> > > > On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz <
> > > christofer.dutz@c-ware.de
> > > > >
> > > > wrote:
> > > >
> > > > > No effort at all ... that's what GIT rebase is for.
> > > > >
> > > > > You can think of this sort of an automated "Create-Patch, Revert,
> > > Update,
> > > > > Apply Patch" ... if all goes well, it's just this one command, if
> > there
> > > > are
> > > > > conflicts, you get the usual conflict editor you would get anyway
if
> > > you
> > > > > created conflicts on develop.
> > > > >
> > > > > Chris
> > > > >
> > > > >
> > > > > ________________________________________
> > > > > Von: Erik de Bruin <er...@ixsoftware.nl>
> > > > > Gesendet: Mittwoch, 2. Juli 2014 09:50
> > > > > An: dev@flex.apache.org
> > > > > Betreff: Re: New Flex to JS project
> > > > >
> > > > > Hi Chris,
> > > > >
> > > > > Thanks for the feedback.
> > > > >
> > > > > I'm talking about FalconJX, not Falcon. The latter is the "new"
SWF
> > > > > compiler, the former is the Flex to JavaScript cross compiler.
> > > > >
> > > > > I guess a feature branch might work... But I'm afraid that keeping
> > that
> > > > > branch up to date with the 'develop' branch will add extra work.
How
> > to
> > > > > best handle that part, so I don't spend what little time I have on
> > Git
> > > > > stuff instead of code?
> > > > >
> > > > > EdB
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz <
> > > > christofer.dutz@c-ware.de
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > I think the reason for the overlay is that by this we are
tricking
> > > the
> > > > > > FlashBuilder to use Falcon instead of the old compiler.
> > > > > > It should be possible to have Falcon separate from the normal
> > > compiler.
> > > > > > It's just that FlashBuilder will probably not be albe to use it
> > that
> > > > way.
> > > > > > Probably IntelliJ would support this withn a few hours,
Flexmojos
> > > > within
> > > > > a
> > > > > > few weeks and FlashBuilder never ;-)
> > > > > >
> > > > > > You shouldn't implement this in the develop branch but create a
> > > > > > feature-branch instead that forks off the develop branch. This
way
> > > your
> > > > > > changes are available to anyone interested and as soon as the
> > feature
> > > > is
> > > > > > finished, you merge it back to develop.
> > > > > >
> > > > > > Chris
> > > > > > ________________________________________
> > > > > > Von: Erik de Bruin <er...@ixsoftware.nl>
> > > > > > Gesendet: Mittwoch, 2. Juli 2014 09:33
> > > > > > An: dev@flex.apache.org
> > > > > > Betreff: New Flex to JS project
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I'm working on creating a way to publish vanilla Flex SDK
projects
> > to
> > > > > > JavaScript on latest gen browsers. This project consists of
several
> > > sub
> > > > > > projects, and I'm wondering what is the best way forward with
> > regard
> > > to
> > > > > > contributing them:
> > > > > >
> > > > > > 1) two new namespaces and accompanying projects in the main Flex
> > SDK:
> > > > > > vf2js_mx and vf2js_s. These namespaces will contain shim objects
> > for
> > > > (you
> > > > > > guessed it) MX and Spark components.
> > > > > >
> > > > > > 2) two new code paths in FalconJX: one for AS and one for MXML
> > > > > >
> > > > > > 3) a new JavaScript library for the components and shims for AS
> > > classes
> > > > > >
> > > > > > 4) a testing framework for the JS components, loosely based on
> > > > Marmotinni
> > > > > >
> > > > > > Questions:
> > > > > >
> > > > > > A - I would very much like to work in the 'develop' branches of
the
> > > > > > projects involved, but especially on the part of '1)' I'm not
sure
> > > if I
> > > > > did
> > > > > > it right. All tests I can think of seem to pass, but maybe
someone
> > > has
> > > > > the
> > > > > > time to do a code review on a branch that I can publish?
> > > > > >
> > > > > > B - In order for this to work, FalconJX needs to be part of the
> > > regular
> > > > > SDK
> > > > > > distribution. Folks who did this on the FlexJS overlay: what
does
> > it
> > > > take
> > > > > > to make FalconJX part of the SDK?
> > > > > >
> > > > > > That's it, for now :-)
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > 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
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > 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: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

Hi Igor,

Can you donate some of your FlexJS/Polymer code to Apache?  We've already
got the beginnings of Cordova, Jquery and CreateJS.  Polymer sounds like a
good addition.

Thanks,
-Alex

On 7/2/14 1:31 PM, "Igor Costa" <ig...@gmail.com> wrote:

>Erik
>
>Right now I'm on a stage of prove of concept using FlexJS and using
>Polymer
>as the output template. I made with success at least with a simple button.
>Polymer has similar architecture as Flex.
>
>Is there a way I can  share each other code? I'm not so familiar with
>vanila sdk.
>
>
>Best Regards
>
>----------------------------
>Igor Costa
>www.igorcosta.com
>www.igorcosta.org
>
>
>On Wed, Jul 2, 2014 at 4:59 PM, Nicholas Kwiatkowski <ni...@spoon.as>
>wrote:
>
>> It's pretty much one command.  The same one you use to keep develop
>>current
>> with your branch :)
>>
>> -Nick
>>
>>
>> On Wed, Jul 2, 2014 at 11:20 AM, Erik de Bruin <er...@ixsoftware.nl>
>>wrote:
>>
>> > On git: let's assume I work on these branches for 6 months (while
>>keeping
>> > them up to date with develop). How much of a hassle will it be to
>>merge
>> > them back into their respective 'develop' branches?
>> >
>> > EdB
>> >
>> >
>> >
>> > On Wed, Jul 2, 2014 at 10:39 AM, OmPrakash Muppirala <
>> bigosmallm@gmail.com
>> > >
>> > wrote:
>> >
>> > > On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz <
>> > christofer.dutz@c-ware.de
>> > > >
>> > > wrote:
>> > >
>> > > > You don't loose the history when rebasing ... you sort of
>>serialize
>> it.
>> > > Ok
>> > > > the order of commits is messed up, but I never really care about
>> this.
>> > > > It might look less interesting in a GIT visualization tool where
>>you
>> > > could
>> > > > see tons of different branches and merges, but it should be a lot
>> > easier
>> > > to
>> > > > maintain, as a serial history is definiely the one that causes the
>> > least
>> > > > trouble ;-)
>> > > >
>> > > > In IntelliJ I usually set my "update" operation to "Rebase" using
>> > "Stash"
>> > > > and have never really had any problems. One click on "Update SCM"
>> and I
>> > > > still work on my featrue branch, but pull in all changes from
>>develop
>> > or
>> > > > whatever branch I branched from. When it comes to commit, the
>>commit
>> > > itself
>> > > > should be a fast-forward commit.
>> > > >
>> > > > But I guess there are several flavours here ... depending on the
>>guy
>> > you
>> > > > ask or listen too, a different way will probably be recommended. I
>> > guess
>> > > > manually merging changes from develop to the feature branch is as
>> valid
>> > > as
>> > > > rebasing, but I think rebasing is easier and causes less trouble,
>>but
>> > you
>> > > > loose the "real-order" of commits (Which I don't really care
>>about).
>> > > >
>> > > > Chris
>> > > >
>> > >
>> > > I will let Erik decide if he wants to rebase or merge.  My
>> recommendation
>> > > is that, since it is a feature branch, it will be useful to retain
>>the
>> > > commit history intact.  So, merge makes sense.
>> > >
>> > > If Erik does not want to keep the commit history intact, rebase will
>> just
>> > > work fine.
>> > >
>> > > Thanks,
>> > > Om
>> > >
>> > >
>> > > >
>> > > >
>> > > >
>> > > > ________________________________________
>> > > > Von: omuppi1@gmail.com <om...@gmail.com> im Auftrag von
>>OmPrakash
>> > > > Muppirala <bi...@gmail.com>
>> > > > Gesendet: Mittwoch, 2. Juli 2014 10:25
>> > > > An: dev@flex.apache.org
>> > > > Betreff: Re: New Flex to JS project
>> > > >
>> > > > On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin <er...@ixsoftware.nl>
>> > > wrote:
>> > > >
>> > > > > Ok, just checking:
>> > > > >
>> > > > > I create a local branch, let's call it 'vf2js', off
>> > 'origin/develop'. I
>> > > > > select this as my active branch.
>> > > >
>> > > >
>> > > > So far so good.
>> > > >
>> > > >
>> > > > > If I then 'rebase', all changes that have
>> > > > > been made to 'origin/develop' will be pulled into my local
>>branch?
>> So
>> > > > far,
>> > > > > so good.
>> > > >
>> > > >
>> > > > Rebase at this point is not required.  The code from
>>origin/develop
>> is
>> > > > already in the 'vf2js' branch.  You will need to 'merge' from
>> > > > origin/develop into vf2js once in a while to make sure that you
>>are
>> in
>> > > sync
>> > > > with whats happening with origin/develop.  When you are done with
>>the
>> > > > feature, you just 'merge' vf2js into develop.  If the history of
>>the
>> > > > 'vf2js' branch is not important, then you use the rebase option.
>> > > >
>> > > >
>> > > > > But now I want the world to see what's in my local vf2js branch,
>> > > > > so I 'publish' it. Is keeping the remote copy of my local
>>branch up
>> > to
>> > > > date
>> > > > > just a question of 'pushing' all commits to that remote branch?
>> > > >
>> > > >
>> > > > Yes, that is correct.
>> > > >
>> > > >
>> > > > > Will
>> > > > > changes that come from the remote 'develop' via my local 'vf2js'
>> also
>> > > in
>> > > > > the remote 'vf2js' that way?
>> > > > >
>> > > >
>> > > > Cannot compute.  Can you rephrase the question?
>> > > >
>> > > >
>> > > > >
>> > > > > Thanks,
>> > > > >
>> > > > > EdB
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz <
>> > > > christofer.dutz@c-ware.de
>> > > > > >
>> > > > > wrote:
>> > > > >
>> > > > > > No effort at all ... that's what GIT rebase is for.
>> > > > > >
>> > > > > > You can think of this sort of an automated "Create-Patch,
>>Revert,
>> > > > Update,
>> > > > > > Apply Patch" ... if all goes well, it's just this one
>>command, if
>> > > there
>> > > > > are
>> > > > > > conflicts, you get the usual conflict editor you would get
>>anyway
>> > if
>> > > > you
>> > > > > > created conflicts on develop.
>> > > > > >
>> > > > > > Chris
>> > > > > >
>> > > > > >
>> > > > > > ________________________________________
>> > > > > > Von: Erik de Bruin <er...@ixsoftware.nl>
>> > > > > > Gesendet: Mittwoch, 2. Juli 2014 09:50
>> > > > > > An: dev@flex.apache.org
>> > > > > > Betreff: Re: New Flex to JS project
>> > > > > >
>> > > > > > Hi Chris,
>> > > > > >
>> > > > > > Thanks for the feedback.
>> > > > > >
>> > > > > > I'm talking about FalconJX, not Falcon. The latter is the
>>"new"
>> SWF
>> > > > > > compiler, the former is the Flex to JavaScript cross compiler.
>> > > > > >
>> > > > > > I guess a feature branch might work... But I'm afraid that
>> keeping
>> > > that
>> > > > > > branch up to date with the 'develop' branch will add extra
>>work.
>> > How
>> > > to
>> > > > > > best handle that part, so I don't spend what little time I
>>have
>> on
>> > > Git
>> > > > > > stuff instead of code?
>> > > > > >
>> > > > > > EdB
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz <
>> > > > > christofer.dutz@c-ware.de
>> > > > > > >
>> > > > > > wrote:
>> > > > > >
>> > > > > > > I think the reason for the overlay is that by this we are
>> > tricking
>> > > > the
>> > > > > > > FlashBuilder to use Falcon instead of the old compiler.
>> > > > > > > It should be possible to have Falcon separate from the
>>normal
>> > > > compiler.
>> > > > > > > It's just that FlashBuilder will probably not be albe to
>>use it
>> > > that
>> > > > > way.
>> > > > > > > Probably IntelliJ would support this withn a few hours,
>> Flexmojos
>> > > > > within
>> > > > > > a
>> > > > > > > few weeks and FlashBuilder never ;-)
>> > > > > > >
>> > > > > > > You shouldn't implement this in the develop branch but
>>create a
>> > > > > > > feature-branch instead that forks off the develop branch.
>>This
>> > way
>> > > > your
>> > > > > > > changes are available to anyone interested and as soon as
>>the
>> > > feature
>> > > > > is
>> > > > > > > finished, you merge it back to develop.
>> > > > > > >
>> > > > > > > Chris
>> > > > > > > ________________________________________
>> > > > > > > Von: Erik de Bruin <er...@ixsoftware.nl>
>> > > > > > > Gesendet: Mittwoch, 2. Juli 2014 09:33
>> > > > > > > An: dev@flex.apache.org
>> > > > > > > Betreff: New Flex to JS project
>> > > > > > >
>> > > > > > > Hi,
>> > > > > > >
>> > > > > > > I'm working on creating a way to publish vanilla Flex SDK
>> > projects
>> > > to
>> > > > > > > JavaScript on latest gen browsers. This project consists of
>> > several
>> > > > sub
>> > > > > > > projects, and I'm wondering what is the best way forward
>>with
>> > > regard
>> > > > to
>> > > > > > > contributing them:
>> > > > > > >
>> > > > > > > 1) two new namespaces and accompanying projects in the main
>> Flex
>> > > SDK:
>> > > > > > > vf2js_mx and vf2js_s. These namespaces will contain shim
>> objects
>> > > for
>> > > > > (you
>> > > > > > > guessed it) MX and Spark components.
>> > > > > > >
>> > > > > > > 2) two new code paths in FalconJX: one for AS and one for
>>MXML
>> > > > > > >
>> > > > > > > 3) a new JavaScript library for the components and shims
>>for AS
>> > > > classes
>> > > > > > >
>> > > > > > > 4) a testing framework for the JS components, loosely based
>>on
>> > > > > Marmotinni
>> > > > > > >
>> > > > > > > Questions:
>> > > > > > >
>> > > > > > > A - I would very much like to work in the 'develop'
>>branches of
>> > the
>> > > > > > > projects involved, but especially on the part of '1)' I'm
>>not
>> > sure
>> > > > if I
>> > > > > > did
>> > > > > > > it right. All tests I can think of seem to pass, but maybe
>> > someone
>> > > > has
>> > > > > > the
>> > > > > > > time to do a code review on a branch that I can publish?
>> > > > > > >
>> > > > > > > B - In order for this to work, FalconJX needs to be part of
>>the
>> > > > regular
>> > > > > > SDK
>> > > > > > > distribution. Folks who did this on the FlexJS overlay: what
>> does
>> > > it
>> > > > > take
>> > > > > > > to make FalconJX part of the SDK?
>> > > > > > >
>> > > > > > > That's it, for now :-)
>> > > > > > >
>> > > > > > > Thanks,
>> > > > > > >
>> > > > > > > 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
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > 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: New Flex to JS project

[Igor Costa <ig...@gmail.com>]

Erik

Right now I'm on a stage of prove of concept using FlexJS and using Polymer
as the output template. I made with success at least with a simple button.
Polymer has similar architecture as Flex.

Is there a way I can  share each other code? I'm not so familiar with
vanila sdk.


Best Regards

----------------------------
Igor Costa
www.igorcosta.com
www.igorcosta.org


On Wed, Jul 2, 2014 at 4:59 PM, Nicholas Kwiatkowski <ni...@spoon.as>
wrote:

> It's pretty much one command.  The same one you use to keep develop current
> with your branch :)
>
> -Nick
>
>
> On Wed, Jul 2, 2014 at 11:20 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>
> > On git: let's assume I work on these branches for 6 months (while keeping
> > them up to date with develop). How much of a hassle will it be to merge
> > them back into their respective 'develop' branches?
> >
> > EdB
> >
> >
> >
> > On Wed, Jul 2, 2014 at 10:39 AM, OmPrakash Muppirala <
> bigosmallm@gmail.com
> > >
> > wrote:
> >
> > > On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz <
> > christofer.dutz@c-ware.de
> > > >
> > > wrote:
> > >
> > > > You don't loose the history when rebasing ... you sort of serialize
> it.
> > > Ok
> > > > the order of commits is messed up, but I never really care about
> this.
> > > > It might look less interesting in a GIT visualization tool where you
> > > could
> > > > see tons of different branches and merges, but it should be a lot
> > easier
> > > to
> > > > maintain, as a serial history is definiely the one that causes the
> > least
> > > > trouble ;-)
> > > >
> > > > In IntelliJ I usually set my "update" operation to "Rebase" using
> > "Stash"
> > > > and have never really had any problems. One click on "Update SCM"
> and I
> > > > still work on my featrue branch, but pull in all changes from develop
> > or
> > > > whatever branch I branched from. When it comes to commit, the commit
> > > itself
> > > > should be a fast-forward commit.
> > > >
> > > > But I guess there are several flavours here ... depending on the guy
> > you
> > > > ask or listen too, a different way will probably be recommended. I
> > guess
> > > > manually merging changes from develop to the feature branch is as
> valid
> > > as
> > > > rebasing, but I think rebasing is easier and causes less trouble, but
> > you
> > > > loose the "real-order" of commits (Which I don't really care about).
> > > >
> > > > Chris
> > > >
> > >
> > > I will let Erik decide if he wants to rebase or merge.  My
> recommendation
> > > is that, since it is a feature branch, it will be useful to retain the
> > > commit history intact.  So, merge makes sense.
> > >
> > > If Erik does not want to keep the commit history intact, rebase will
> just
> > > work fine.
> > >
> > > Thanks,
> > > Om
> > >
> > >
> > > >
> > > >
> > > >
> > > > ________________________________________
> > > > Von: omuppi1@gmail.com <om...@gmail.com> im Auftrag von OmPrakash
> > > > Muppirala <bi...@gmail.com>
> > > > Gesendet: Mittwoch, 2. Juli 2014 10:25
> > > > An: dev@flex.apache.org
> > > > Betreff: Re: New Flex to JS project
> > > >
> > > > On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin <er...@ixsoftware.nl>
> > > wrote:
> > > >
> > > > > Ok, just checking:
> > > > >
> > > > > I create a local branch, let's call it 'vf2js', off
> > 'origin/develop'. I
> > > > > select this as my active branch.
> > > >
> > > >
> > > > So far so good.
> > > >
> > > >
> > > > > If I then 'rebase', all changes that have
> > > > > been made to 'origin/develop' will be pulled into my local branch?
> So
> > > > far,
> > > > > so good.
> > > >
> > > >
> > > > Rebase at this point is not required.  The code from origin/develop
> is
> > > > already in the 'vf2js' branch.  You will need to 'merge' from
> > > > origin/develop into vf2js once in a while to make sure that you are
> in
> > > sync
> > > > with whats happening with origin/develop.  When you are done with the
> > > > feature, you just 'merge' vf2js into develop.  If the history of the
> > > > 'vf2js' branch is not important, then you use the rebase option.
> > > >
> > > >
> > > > > But now I want the world to see what's in my local vf2js branch,
> > > > > so I 'publish' it. Is keeping the remote copy of my local branch up
> > to
> > > > date
> > > > > just a question of 'pushing' all commits to that remote branch?
> > > >
> > > >
> > > > Yes, that is correct.
> > > >
> > > >
> > > > > Will
> > > > > changes that come from the remote 'develop' via my local 'vf2js'
> also
> > > in
> > > > > the remote 'vf2js' that way?
> > > > >
> > > >
> > > > Cannot compute.  Can you rephrase the question?
> > > >
> > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > > EdB
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz <
> > > > christofer.dutz@c-ware.de
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > No effort at all ... that's what GIT rebase is for.
> > > > > >
> > > > > > You can think of this sort of an automated "Create-Patch, Revert,
> > > > Update,
> > > > > > Apply Patch" ... if all goes well, it's just this one command, if
> > > there
> > > > > are
> > > > > > conflicts, you get the usual conflict editor you would get anyway
> > if
> > > > you
> > > > > > created conflicts on develop.
> > > > > >
> > > > > > Chris
> > > > > >
> > > > > >
> > > > > > ________________________________________
> > > > > > Von: Erik de Bruin <er...@ixsoftware.nl>
> > > > > > Gesendet: Mittwoch, 2. Juli 2014 09:50
> > > > > > An: dev@flex.apache.org
> > > > > > Betreff: Re: New Flex to JS project
> > > > > >
> > > > > > Hi Chris,
> > > > > >
> > > > > > Thanks for the feedback.
> > > > > >
> > > > > > I'm talking about FalconJX, not Falcon. The latter is the "new"
> SWF
> > > > > > compiler, the former is the Flex to JavaScript cross compiler.
> > > > > >
> > > > > > I guess a feature branch might work... But I'm afraid that
> keeping
> > > that
> > > > > > branch up to date with the 'develop' branch will add extra work.
> > How
> > > to
> > > > > > best handle that part, so I don't spend what little time I have
> on
> > > Git
> > > > > > stuff instead of code?
> > > > > >
> > > > > > EdB
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz <
> > > > > christofer.dutz@c-ware.de
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I think the reason for the overlay is that by this we are
> > tricking
> > > > the
> > > > > > > FlashBuilder to use Falcon instead of the old compiler.
> > > > > > > It should be possible to have Falcon separate from the normal
> > > > compiler.
> > > > > > > It's just that FlashBuilder will probably not be albe to use it
> > > that
> > > > > way.
> > > > > > > Probably IntelliJ would support this withn a few hours,
> Flexmojos
> > > > > within
> > > > > > a
> > > > > > > few weeks and FlashBuilder never ;-)
> > > > > > >
> > > > > > > You shouldn't implement this in the develop branch but create a
> > > > > > > feature-branch instead that forks off the develop branch. This
> > way
> > > > your
> > > > > > > changes are available to anyone interested and as soon as the
> > > feature
> > > > > is
> > > > > > > finished, you merge it back to develop.
> > > > > > >
> > > > > > > Chris
> > > > > > > ________________________________________
> > > > > > > Von: Erik de Bruin <er...@ixsoftware.nl>
> > > > > > > Gesendet: Mittwoch, 2. Juli 2014 09:33
> > > > > > > An: dev@flex.apache.org
> > > > > > > Betreff: New Flex to JS project
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I'm working on creating a way to publish vanilla Flex SDK
> > projects
> > > to
> > > > > > > JavaScript on latest gen browsers. This project consists of
> > several
> > > > sub
> > > > > > > projects, and I'm wondering what is the best way forward with
> > > regard
> > > > to
> > > > > > > contributing them:
> > > > > > >
> > > > > > > 1) two new namespaces and accompanying projects in the main
> Flex
> > > SDK:
> > > > > > > vf2js_mx and vf2js_s. These namespaces will contain shim
> objects
> > > for
> > > > > (you
> > > > > > > guessed it) MX and Spark components.
> > > > > > >
> > > > > > > 2) two new code paths in FalconJX: one for AS and one for MXML
> > > > > > >
> > > > > > > 3) a new JavaScript library for the components and shims for AS
> > > > classes
> > > > > > >
> > > > > > > 4) a testing framework for the JS components, loosely based on
> > > > > Marmotinni
> > > > > > >
> > > > > > > Questions:
> > > > > > >
> > > > > > > A - I would very much like to work in the 'develop' branches of
> > the
> > > > > > > projects involved, but especially on the part of '1)' I'm not
> > sure
> > > > if I
> > > > > > did
> > > > > > > it right. All tests I can think of seem to pass, but maybe
> > someone
> > > > has
> > > > > > the
> > > > > > > time to do a code review on a branch that I can publish?
> > > > > > >
> > > > > > > B - In order for this to work, FalconJX needs to be part of the
> > > > regular
> > > > > > SDK
> > > > > > > distribution. Folks who did this on the FlexJS overlay: what
> does
> > > it
> > > > > take
> > > > > > > to make FalconJX part of the SDK?
> > > > > > >
> > > > > > > That's it, for now :-)
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > 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
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 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: New Flex to JS project

[Nicholas Kwiatkowski <ni...@spoon.as>]

It's pretty much one command.  The same one you use to keep develop current
with your branch :)

-Nick


On Wed, Jul 2, 2014 at 11:20 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:

> On git: let's assume I work on these branches for 6 months (while keeping
> them up to date with develop). How much of a hassle will it be to merge
> them back into their respective 'develop' branches?
>
> EdB
>
>
>
> On Wed, Jul 2, 2014 at 10:39 AM, OmPrakash Muppirala <bigosmallm@gmail.com
> >
> wrote:
>
> > On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz <
> christofer.dutz@c-ware.de
> > >
> > wrote:
> >
> > > You don't loose the history when rebasing ... you sort of serialize it.
> > Ok
> > > the order of commits is messed up, but I never really care about this.
> > > It might look less interesting in a GIT visualization tool where you
> > could
> > > see tons of different branches and merges, but it should be a lot
> easier
> > to
> > > maintain, as a serial history is definiely the one that causes the
> least
> > > trouble ;-)
> > >
> > > In IntelliJ I usually set my "update" operation to "Rebase" using
> "Stash"
> > > and have never really had any problems. One click on "Update SCM" and I
> > > still work on my featrue branch, but pull in all changes from develop
> or
> > > whatever branch I branched from. When it comes to commit, the commit
> > itself
> > > should be a fast-forward commit.
> > >
> > > But I guess there are several flavours here ... depending on the guy
> you
> > > ask or listen too, a different way will probably be recommended. I
> guess
> > > manually merging changes from develop to the feature branch is as valid
> > as
> > > rebasing, but I think rebasing is easier and causes less trouble, but
> you
> > > loose the "real-order" of commits (Which I don't really care about).
> > >
> > > Chris
> > >
> >
> > I will let Erik decide if he wants to rebase or merge.  My recommendation
> > is that, since it is a feature branch, it will be useful to retain the
> > commit history intact.  So, merge makes sense.
> >
> > If Erik does not want to keep the commit history intact, rebase will just
> > work fine.
> >
> > Thanks,
> > Om
> >
> >
> > >
> > >
> > >
> > > ________________________________________
> > > Von: omuppi1@gmail.com <om...@gmail.com> im Auftrag von OmPrakash
> > > Muppirala <bi...@gmail.com>
> > > Gesendet: Mittwoch, 2. Juli 2014 10:25
> > > An: dev@flex.apache.org
> > > Betreff: Re: New Flex to JS project
> > >
> > > On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin <er...@ixsoftware.nl>
> > wrote:
> > >
> > > > Ok, just checking:
> > > >
> > > > I create a local branch, let's call it 'vf2js', off
> 'origin/develop'. I
> > > > select this as my active branch.
> > >
> > >
> > > So far so good.
> > >
> > >
> > > > If I then 'rebase', all changes that have
> > > > been made to 'origin/develop' will be pulled into my local branch? So
> > > far,
> > > > so good.
> > >
> > >
> > > Rebase at this point is not required.  The code from origin/develop is
> > > already in the 'vf2js' branch.  You will need to 'merge' from
> > > origin/develop into vf2js once in a while to make sure that you are in
> > sync
> > > with whats happening with origin/develop.  When you are done with the
> > > feature, you just 'merge' vf2js into develop.  If the history of the
> > > 'vf2js' branch is not important, then you use the rebase option.
> > >
> > >
> > > > But now I want the world to see what's in my local vf2js branch,
> > > > so I 'publish' it. Is keeping the remote copy of my local branch up
> to
> > > date
> > > > just a question of 'pushing' all commits to that remote branch?
> > >
> > >
> > > Yes, that is correct.
> > >
> > >
> > > > Will
> > > > changes that come from the remote 'develop' via my local 'vf2js' also
> > in
> > > > the remote 'vf2js' that way?
> > > >
> > >
> > > Cannot compute.  Can you rephrase the question?
> > >
> > >
> > > >
> > > > Thanks,
> > > >
> > > > EdB
> > > >
> > > >
> > > >
> > > > On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz <
> > > christofer.dutz@c-ware.de
> > > > >
> > > > wrote:
> > > >
> > > > > No effort at all ... that's what GIT rebase is for.
> > > > >
> > > > > You can think of this sort of an automated "Create-Patch, Revert,
> > > Update,
> > > > > Apply Patch" ... if all goes well, it's just this one command, if
> > there
> > > > are
> > > > > conflicts, you get the usual conflict editor you would get anyway
> if
> > > you
> > > > > created conflicts on develop.
> > > > >
> > > > > Chris
> > > > >
> > > > >
> > > > > ________________________________________
> > > > > Von: Erik de Bruin <er...@ixsoftware.nl>
> > > > > Gesendet: Mittwoch, 2. Juli 2014 09:50
> > > > > An: dev@flex.apache.org
> > > > > Betreff: Re: New Flex to JS project
> > > > >
> > > > > Hi Chris,
> > > > >
> > > > > Thanks for the feedback.
> > > > >
> > > > > I'm talking about FalconJX, not Falcon. The latter is the "new" SWF
> > > > > compiler, the former is the Flex to JavaScript cross compiler.
> > > > >
> > > > > I guess a feature branch might work... But I'm afraid that keeping
> > that
> > > > > branch up to date with the 'develop' branch will add extra work.
> How
> > to
> > > > > best handle that part, so I don't spend what little time I have on
> > Git
> > > > > stuff instead of code?
> > > > >
> > > > > EdB
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz <
> > > > christofer.dutz@c-ware.de
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > I think the reason for the overlay is that by this we are
> tricking
> > > the
> > > > > > FlashBuilder to use Falcon instead of the old compiler.
> > > > > > It should be possible to have Falcon separate from the normal
> > > compiler.
> > > > > > It's just that FlashBuilder will probably not be albe to use it
> > that
> > > > way.
> > > > > > Probably IntelliJ would support this withn a few hours, Flexmojos
> > > > within
> > > > > a
> > > > > > few weeks and FlashBuilder never ;-)
> > > > > >
> > > > > > You shouldn't implement this in the develop branch but create a
> > > > > > feature-branch instead that forks off the develop branch. This
> way
> > > your
> > > > > > changes are available to anyone interested and as soon as the
> > feature
> > > > is
> > > > > > finished, you merge it back to develop.
> > > > > >
> > > > > > Chris
> > > > > > ________________________________________
> > > > > > Von: Erik de Bruin <er...@ixsoftware.nl>
> > > > > > Gesendet: Mittwoch, 2. Juli 2014 09:33
> > > > > > An: dev@flex.apache.org
> > > > > > Betreff: New Flex to JS project
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I'm working on creating a way to publish vanilla Flex SDK
> projects
> > to
> > > > > > JavaScript on latest gen browsers. This project consists of
> several
> > > sub
> > > > > > projects, and I'm wondering what is the best way forward with
> > regard
> > > to
> > > > > > contributing them:
> > > > > >
> > > > > > 1) two new namespaces and accompanying projects in the main Flex
> > SDK:
> > > > > > vf2js_mx and vf2js_s. These namespaces will contain shim objects
> > for
> > > > (you
> > > > > > guessed it) MX and Spark components.
> > > > > >
> > > > > > 2) two new code paths in FalconJX: one for AS and one for MXML
> > > > > >
> > > > > > 3) a new JavaScript library for the components and shims for AS
> > > classes
> > > > > >
> > > > > > 4) a testing framework for the JS components, loosely based on
> > > > Marmotinni
> > > > > >
> > > > > > Questions:
> > > > > >
> > > > > > A - I would very much like to work in the 'develop' branches of
> the
> > > > > > projects involved, but especially on the part of '1)' I'm not
> sure
> > > if I
> > > > > did
> > > > > > it right. All tests I can think of seem to pass, but maybe
> someone
> > > has
> > > > > the
> > > > > > time to do a code review on a branch that I can publish?
> > > > > >
> > > > > > B - In order for this to work, FalconJX needs to be part of the
> > > regular
> > > > > SDK
> > > > > > distribution. Folks who did this on the FlexJS overlay: what does
> > it
> > > > take
> > > > > > to make FalconJX part of the SDK?
> > > > > >
> > > > > > That's it, for now :-)
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > 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
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > 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: New Flex to JS project

[Erik de Bruin <er...@ixsoftware.nl>]

On git: let's assume I work on these branches for 6 months (while keeping
them up to date with develop). How much of a hassle will it be to merge
them back into their respective 'develop' branches?

EdB



On Wed, Jul 2, 2014 at 10:39 AM, OmPrakash Muppirala <bi...@gmail.com>
wrote:

> On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz <christofer.dutz@c-ware.de
> >
> wrote:
>
> > You don't loose the history when rebasing ... you sort of serialize it.
> Ok
> > the order of commits is messed up, but I never really care about this.
> > It might look less interesting in a GIT visualization tool where you
> could
> > see tons of different branches and merges, but it should be a lot easier
> to
> > maintain, as a serial history is definiely the one that causes the least
> > trouble ;-)
> >
> > In IntelliJ I usually set my "update" operation to "Rebase" using "Stash"
> > and have never really had any problems. One click on "Update SCM" and I
> > still work on my featrue branch, but pull in all changes from develop or
> > whatever branch I branched from. When it comes to commit, the commit
> itself
> > should be a fast-forward commit.
> >
> > But I guess there are several flavours here ... depending on the guy you
> > ask or listen too, a different way will probably be recommended. I guess
> > manually merging changes from develop to the feature branch is as valid
> as
> > rebasing, but I think rebasing is easier and causes less trouble, but you
> > loose the "real-order" of commits (Which I don't really care about).
> >
> > Chris
> >
>
> I will let Erik decide if he wants to rebase or merge.  My recommendation
> is that, since it is a feature branch, it will be useful to retain the
> commit history intact.  So, merge makes sense.
>
> If Erik does not want to keep the commit history intact, rebase will just
> work fine.
>
> Thanks,
> Om
>
>
> >
> >
> >
> > ________________________________________
> > Von: omuppi1@gmail.com <om...@gmail.com> im Auftrag von OmPrakash
> > Muppirala <bi...@gmail.com>
> > Gesendet: Mittwoch, 2. Juli 2014 10:25
> > An: dev@flex.apache.org
> > Betreff: Re: New Flex to JS project
> >
> > On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin <er...@ixsoftware.nl>
> wrote:
> >
> > > Ok, just checking:
> > >
> > > I create a local branch, let's call it 'vf2js', off 'origin/develop'. I
> > > select this as my active branch.
> >
> >
> > So far so good.
> >
> >
> > > If I then 'rebase', all changes that have
> > > been made to 'origin/develop' will be pulled into my local branch? So
> > far,
> > > so good.
> >
> >
> > Rebase at this point is not required.  The code from origin/develop is
> > already in the 'vf2js' branch.  You will need to 'merge' from
> > origin/develop into vf2js once in a while to make sure that you are in
> sync
> > with whats happening with origin/develop.  When you are done with the
> > feature, you just 'merge' vf2js into develop.  If the history of the
> > 'vf2js' branch is not important, then you use the rebase option.
> >
> >
> > > But now I want the world to see what's in my local vf2js branch,
> > > so I 'publish' it. Is keeping the remote copy of my local branch up to
> > date
> > > just a question of 'pushing' all commits to that remote branch?
> >
> >
> > Yes, that is correct.
> >
> >
> > > Will
> > > changes that come from the remote 'develop' via my local 'vf2js' also
> in
> > > the remote 'vf2js' that way?
> > >
> >
> > Cannot compute.  Can you rephrase the question?
> >
> >
> > >
> > > Thanks,
> > >
> > > EdB
> > >
> > >
> > >
> > > On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz <
> > christofer.dutz@c-ware.de
> > > >
> > > wrote:
> > >
> > > > No effort at all ... that's what GIT rebase is for.
> > > >
> > > > You can think of this sort of an automated "Create-Patch, Revert,
> > Update,
> > > > Apply Patch" ... if all goes well, it's just this one command, if
> there
> > > are
> > > > conflicts, you get the usual conflict editor you would get anyway if
> > you
> > > > created conflicts on develop.
> > > >
> > > > Chris
> > > >
> > > >
> > > > ________________________________________
> > > > Von: Erik de Bruin <er...@ixsoftware.nl>
> > > > Gesendet: Mittwoch, 2. Juli 2014 09:50
> > > > An: dev@flex.apache.org
> > > > Betreff: Re: New Flex to JS project
> > > >
> > > > Hi Chris,
> > > >
> > > > Thanks for the feedback.
> > > >
> > > > I'm talking about FalconJX, not Falcon. The latter is the "new" SWF
> > > > compiler, the former is the Flex to JavaScript cross compiler.
> > > >
> > > > I guess a feature branch might work... But I'm afraid that keeping
> that
> > > > branch up to date with the 'develop' branch will add extra work. How
> to
> > > > best handle that part, so I don't spend what little time I have on
> Git
> > > > stuff instead of code?
> > > >
> > > > EdB
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz <
> > > christofer.dutz@c-ware.de
> > > > >
> > > > wrote:
> > > >
> > > > > I think the reason for the overlay is that by this we are tricking
> > the
> > > > > FlashBuilder to use Falcon instead of the old compiler.
> > > > > It should be possible to have Falcon separate from the normal
> > compiler.
> > > > > It's just that FlashBuilder will probably not be albe to use it
> that
> > > way.
> > > > > Probably IntelliJ would support this withn a few hours, Flexmojos
> > > within
> > > > a
> > > > > few weeks and FlashBuilder never ;-)
> > > > >
> > > > > You shouldn't implement this in the develop branch but create a
> > > > > feature-branch instead that forks off the develop branch. This way
> > your
> > > > > changes are available to anyone interested and as soon as the
> feature
> > > is
> > > > > finished, you merge it back to develop.
> > > > >
> > > > > Chris
> > > > > ________________________________________
> > > > > Von: Erik de Bruin <er...@ixsoftware.nl>
> > > > > Gesendet: Mittwoch, 2. Juli 2014 09:33
> > > > > An: dev@flex.apache.org
> > > > > Betreff: New Flex to JS project
> > > > >
> > > > > Hi,
> > > > >
> > > > > I'm working on creating a way to publish vanilla Flex SDK projects
> to
> > > > > JavaScript on latest gen browsers. This project consists of several
> > sub
> > > > > projects, and I'm wondering what is the best way forward with
> regard
> > to
> > > > > contributing them:
> > > > >
> > > > > 1) two new namespaces and accompanying projects in the main Flex
> SDK:
> > > > > vf2js_mx and vf2js_s. These namespaces will contain shim objects
> for
> > > (you
> > > > > guessed it) MX and Spark components.
> > > > >
> > > > > 2) two new code paths in FalconJX: one for AS and one for MXML
> > > > >
> > > > > 3) a new JavaScript library for the components and shims for AS
> > classes
> > > > >
> > > > > 4) a testing framework for the JS components, loosely based on
> > > Marmotinni
> > > > >
> > > > > Questions:
> > > > >
> > > > > A - I would very much like to work in the 'develop' branches of the
> > > > > projects involved, but especially on the part of '1)' I'm not sure
> > if I
> > > > did
> > > > > it right. All tests I can think of seem to pass, but maybe someone
> > has
> > > > the
> > > > > time to do a code review on a branch that I can publish?
> > > > >
> > > > > B - In order for this to work, FalconJX needs to be part of the
> > regular
> > > > SDK
> > > > > distribution. Folks who did this on the FlexJS overlay: what does
> it
> > > take
> > > > > to make FalconJX part of the SDK?
> > > > >
> > > > > That's it, for now :-)
> > > > >
> > > > > Thanks,
> > > > >
> > > > > 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
> > > >
> > >
> > >
> > >
> > > --
> > > 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: New Flex to JS project

[OmPrakash Muppirala <bi...@gmail.com>]

On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz <ch...@c-ware.de>
wrote:

> You don't loose the history when rebasing ... you sort of serialize it. Ok
> the order of commits is messed up, but I never really care about this.
> It might look less interesting in a GIT visualization tool where you could
> see tons of different branches and merges, but it should be a lot easier to
> maintain, as a serial history is definiely the one that causes the least
> trouble ;-)
>
> In IntelliJ I usually set my "update" operation to "Rebase" using "Stash"
> and have never really had any problems. One click on "Update SCM" and I
> still work on my featrue branch, but pull in all changes from develop or
> whatever branch I branched from. When it comes to commit, the commit itself
> should be a fast-forward commit.
>
> But I guess there are several flavours here ... depending on the guy you
> ask or listen too, a different way will probably be recommended. I guess
> manually merging changes from develop to the feature branch is as valid as
> rebasing, but I think rebasing is easier and causes less trouble, but you
> loose the "real-order" of commits (Which I don't really care about).
>
> Chris
>

I will let Erik decide if he wants to rebase or merge.  My recommendation
is that, since it is a feature branch, it will be useful to retain the
commit history intact.  So, merge makes sense.

If Erik does not want to keep the commit history intact, rebase will just
work fine.

Thanks,
Om


>
>
>
> ________________________________________
> Von: omuppi1@gmail.com <om...@gmail.com> im Auftrag von OmPrakash
> Muppirala <bi...@gmail.com>
> Gesendet: Mittwoch, 2. Juli 2014 10:25
> An: dev@flex.apache.org
> Betreff: Re: New Flex to JS project
>
> On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>
> > Ok, just checking:
> >
> > I create a local branch, let's call it 'vf2js', off 'origin/develop'. I
> > select this as my active branch.
>
>
> So far so good.
>
>
> > If I then 'rebase', all changes that have
> > been made to 'origin/develop' will be pulled into my local branch? So
> far,
> > so good.
>
>
> Rebase at this point is not required.  The code from origin/develop is
> already in the 'vf2js' branch.  You will need to 'merge' from
> origin/develop into vf2js once in a while to make sure that you are in sync
> with whats happening with origin/develop.  When you are done with the
> feature, you just 'merge' vf2js into develop.  If the history of the
> 'vf2js' branch is not important, then you use the rebase option.
>
>
> > But now I want the world to see what's in my local vf2js branch,
> > so I 'publish' it. Is keeping the remote copy of my local branch up to
> date
> > just a question of 'pushing' all commits to that remote branch?
>
>
> Yes, that is correct.
>
>
> > Will
> > changes that come from the remote 'develop' via my local 'vf2js' also in
> > the remote 'vf2js' that way?
> >
>
> Cannot compute.  Can you rephrase the question?
>
>
> >
> > Thanks,
> >
> > EdB
> >
> >
> >
> > On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz <
> christofer.dutz@c-ware.de
> > >
> > wrote:
> >
> > > No effort at all ... that's what GIT rebase is for.
> > >
> > > You can think of this sort of an automated "Create-Patch, Revert,
> Update,
> > > Apply Patch" ... if all goes well, it's just this one command, if there
> > are
> > > conflicts, you get the usual conflict editor you would get anyway if
> you
> > > created conflicts on develop.
> > >
> > > Chris
> > >
> > >
> > > ________________________________________
> > > Von: Erik de Bruin <er...@ixsoftware.nl>
> > > Gesendet: Mittwoch, 2. Juli 2014 09:50
> > > An: dev@flex.apache.org
> > > Betreff: Re: New Flex to JS project
> > >
> > > Hi Chris,
> > >
> > > Thanks for the feedback.
> > >
> > > I'm talking about FalconJX, not Falcon. The latter is the "new" SWF
> > > compiler, the former is the Flex to JavaScript cross compiler.
> > >
> > > I guess a feature branch might work... But I'm afraid that keeping that
> > > branch up to date with the 'develop' branch will add extra work. How to
> > > best handle that part, so I don't spend what little time I have on Git
> > > stuff instead of code?
> > >
> > > EdB
> > >
> > >
> > >
> > >
> > > On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz <
> > christofer.dutz@c-ware.de
> > > >
> > > wrote:
> > >
> > > > I think the reason for the overlay is that by this we are tricking
> the
> > > > FlashBuilder to use Falcon instead of the old compiler.
> > > > It should be possible to have Falcon separate from the normal
> compiler.
> > > > It's just that FlashBuilder will probably not be albe to use it that
> > way.
> > > > Probably IntelliJ would support this withn a few hours, Flexmojos
> > within
> > > a
> > > > few weeks and FlashBuilder never ;-)
> > > >
> > > > You shouldn't implement this in the develop branch but create a
> > > > feature-branch instead that forks off the develop branch. This way
> your
> > > > changes are available to anyone interested and as soon as the feature
> > is
> > > > finished, you merge it back to develop.
> > > >
> > > > Chris
> > > > ________________________________________
> > > > Von: Erik de Bruin <er...@ixsoftware.nl>
> > > > Gesendet: Mittwoch, 2. Juli 2014 09:33
> > > > An: dev@flex.apache.org
> > > > Betreff: New Flex to JS project
> > > >
> > > > Hi,
> > > >
> > > > I'm working on creating a way to publish vanilla Flex SDK projects to
> > > > JavaScript on latest gen browsers. This project consists of several
> sub
> > > > projects, and I'm wondering what is the best way forward with regard
> to
> > > > contributing them:
> > > >
> > > > 1) two new namespaces and accompanying projects in the main Flex SDK:
> > > > vf2js_mx and vf2js_s. These namespaces will contain shim objects for
> > (you
> > > > guessed it) MX and Spark components.
> > > >
> > > > 2) two new code paths in FalconJX: one for AS and one for MXML
> > > >
> > > > 3) a new JavaScript library for the components and shims for AS
> classes
> > > >
> > > > 4) a testing framework for the JS components, loosely based on
> > Marmotinni
> > > >
> > > > Questions:
> > > >
> > > > A - I would very much like to work in the 'develop' branches of the
> > > > projects involved, but especially on the part of '1)' I'm not sure
> if I
> > > did
> > > > it right. All tests I can think of seem to pass, but maybe someone
> has
> > > the
> > > > time to do a code review on a branch that I can publish?
> > > >
> > > > B - In order for this to work, FalconJX needs to be part of the
> regular
> > > SDK
> > > > distribution. Folks who did this on the FlexJS overlay: what does it
> > take
> > > > to make FalconJX part of the SDK?
> > > >
> > > > That's it, for now :-)
> > > >
> > > > Thanks,
> > > >
> > > > 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
> > >
> >
> >
> >
> > --
> > Ix Multimedia Software
> >
> > Jan Luykenstraat 27
> > 3521 VB Utrecht
> >
> > T. 06-51952295
> > I. www.ixsoftware.nl
> >
>

AW: New Flex to JS project

[Christofer Dutz <ch...@c-ware.de>]

You don't loose the history when rebasing ... you sort of serialize it. Ok the order of commits is messed up, but I never really care about this. 
It might look less interesting in a GIT visualization tool where you could see tons of different branches and merges, but it should be a lot easier to maintain, as a serial history is definiely the one that causes the least trouble ;-)

In IntelliJ I usually set my "update" operation to "Rebase" using "Stash" and have never really had any problems. One click on "Update SCM" and I still work on my featrue branch, but pull in all changes from develop or whatever branch I branched from. When it comes to commit, the commit itself should be a fast-forward commit.

But I guess there are several flavours here ... depending on the guy you ask or listen too, a different way will probably be recommended. I guess manually merging changes from develop to the feature branch is as valid as rebasing, but I think rebasing is easier and causes less trouble, but you loose the "real-order" of commits (Which I don't really care about).

Chris



________________________________________
Von: omuppi1@gmail.com <om...@gmail.com> im Auftrag von OmPrakash Muppirala <bi...@gmail.com>
Gesendet: Mittwoch, 2. Juli 2014 10:25
An: dev@flex.apache.org
Betreff: Re: New Flex to JS project

On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:

> Ok, just checking:
>
> I create a local branch, let's call it 'vf2js', off 'origin/develop'. I
> select this as my active branch.


So far so good.


> If I then 'rebase', all changes that have
> been made to 'origin/develop' will be pulled into my local branch? So far,
> so good.


Rebase at this point is not required.  The code from origin/develop is
already in the 'vf2js' branch.  You will need to 'merge' from
origin/develop into vf2js once in a while to make sure that you are in sync
with whats happening with origin/develop.  When you are done with the
feature, you just 'merge' vf2js into develop.  If the history of the
'vf2js' branch is not important, then you use the rebase option.


> But now I want the world to see what's in my local vf2js branch,
> so I 'publish' it. Is keeping the remote copy of my local branch up to date
> just a question of 'pushing' all commits to that remote branch?


Yes, that is correct.


> Will
> changes that come from the remote 'develop' via my local 'vf2js' also in
> the remote 'vf2js' that way?
>

Cannot compute.  Can you rephrase the question?


>
> Thanks,
>
> EdB
>
>
>
> On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz <christofer.dutz@c-ware.de
> >
> wrote:
>
> > No effort at all ... that's what GIT rebase is for.
> >
> > You can think of this sort of an automated "Create-Patch, Revert, Update,
> > Apply Patch" ... if all goes well, it's just this one command, if there
> are
> > conflicts, you get the usual conflict editor you would get anyway if you
> > created conflicts on develop.
> >
> > Chris
> >
> >
> > ________________________________________
> > Von: Erik de Bruin <er...@ixsoftware.nl>
> > Gesendet: Mittwoch, 2. Juli 2014 09:50
> > An: dev@flex.apache.org
> > Betreff: Re: New Flex to JS project
> >
> > Hi Chris,
> >
> > Thanks for the feedback.
> >
> > I'm talking about FalconJX, not Falcon. The latter is the "new" SWF
> > compiler, the former is the Flex to JavaScript cross compiler.
> >
> > I guess a feature branch might work... But I'm afraid that keeping that
> > branch up to date with the 'develop' branch will add extra work. How to
> > best handle that part, so I don't spend what little time I have on Git
> > stuff instead of code?
> >
> > EdB
> >
> >
> >
> >
> > On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz <
> christofer.dutz@c-ware.de
> > >
> > wrote:
> >
> > > I think the reason for the overlay is that by this we are tricking the
> > > FlashBuilder to use Falcon instead of the old compiler.
> > > It should be possible to have Falcon separate from the normal compiler.
> > > It's just that FlashBuilder will probably not be albe to use it that
> way.
> > > Probably IntelliJ would support this withn a few hours, Flexmojos
> within
> > a
> > > few weeks and FlashBuilder never ;-)
> > >
> > > You shouldn't implement this in the develop branch but create a
> > > feature-branch instead that forks off the develop branch. This way your
> > > changes are available to anyone interested and as soon as the feature
> is
> > > finished, you merge it back to develop.
> > >
> > > Chris
> > > ________________________________________
> > > Von: Erik de Bruin <er...@ixsoftware.nl>
> > > Gesendet: Mittwoch, 2. Juli 2014 09:33
> > > An: dev@flex.apache.org
> > > Betreff: New Flex to JS project
> > >
> > > Hi,
> > >
> > > I'm working on creating a way to publish vanilla Flex SDK projects to
> > > JavaScript on latest gen browsers. This project consists of several sub
> > > projects, and I'm wondering what is the best way forward with regard to
> > > contributing them:
> > >
> > > 1) two new namespaces and accompanying projects in the main Flex SDK:
> > > vf2js_mx and vf2js_s. These namespaces will contain shim objects for
> (you
> > > guessed it) MX and Spark components.
> > >
> > > 2) two new code paths in FalconJX: one for AS and one for MXML
> > >
> > > 3) a new JavaScript library for the components and shims for AS classes
> > >
> > > 4) a testing framework for the JS components, loosely based on
> Marmotinni
> > >
> > > Questions:
> > >
> > > A - I would very much like to work in the 'develop' branches of the
> > > projects involved, but especially on the part of '1)' I'm not sure if I
> > did
> > > it right. All tests I can think of seem to pass, but maybe someone has
> > the
> > > time to do a code review on a branch that I can publish?
> > >
> > > B - In order for this to work, FalconJX needs to be part of the regular
> > SDK
> > > distribution. Folks who did this on the FlexJS overlay: what does it
> take
> > > to make FalconJX part of the SDK?
> > >
> > > That's it, for now :-)
> > >
> > > Thanks,
> > >
> > > 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
> >
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>

Re: New Flex to JS project

[OmPrakash Muppirala <bi...@gmail.com>]

On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:

> Ok, just checking:
>
> I create a local branch, let's call it 'vf2js', off 'origin/develop'. I
> select this as my active branch.


So far so good.


> If I then 'rebase', all changes that have
> been made to 'origin/develop' will be pulled into my local branch? So far,
> so good.


Rebase at this point is not required.  The code from origin/develop is
already in the 'vf2js' branch.  You will need to 'merge' from
origin/develop into vf2js once in a while to make sure that you are in sync
with whats happening with origin/develop.  When you are done with the
feature, you just 'merge' vf2js into develop.  If the history of the
'vf2js' branch is not important, then you use the rebase option.


> But now I want the world to see what's in my local vf2js branch,
> so I 'publish' it. Is keeping the remote copy of my local branch up to date
> just a question of 'pushing' all commits to that remote branch?


Yes, that is correct.


> Will
> changes that come from the remote 'develop' via my local 'vf2js' also in
> the remote 'vf2js' that way?
>

Cannot compute.  Can you rephrase the question?


>
> Thanks,
>
> EdB
>
>
>
> On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz <christofer.dutz@c-ware.de
> >
> wrote:
>
> > No effort at all ... that's what GIT rebase is for.
> >
> > You can think of this sort of an automated "Create-Patch, Revert, Update,
> > Apply Patch" ... if all goes well, it's just this one command, if there
> are
> > conflicts, you get the usual conflict editor you would get anyway if you
> > created conflicts on develop.
> >
> > Chris
> >
> >
> > ________________________________________
> > Von: Erik de Bruin <er...@ixsoftware.nl>
> > Gesendet: Mittwoch, 2. Juli 2014 09:50
> > An: dev@flex.apache.org
> > Betreff: Re: New Flex to JS project
> >
> > Hi Chris,
> >
> > Thanks for the feedback.
> >
> > I'm talking about FalconJX, not Falcon. The latter is the "new" SWF
> > compiler, the former is the Flex to JavaScript cross compiler.
> >
> > I guess a feature branch might work... But I'm afraid that keeping that
> > branch up to date with the 'develop' branch will add extra work. How to
> > best handle that part, so I don't spend what little time I have on Git
> > stuff instead of code?
> >
> > EdB
> >
> >
> >
> >
> > On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz <
> christofer.dutz@c-ware.de
> > >
> > wrote:
> >
> > > I think the reason for the overlay is that by this we are tricking the
> > > FlashBuilder to use Falcon instead of the old compiler.
> > > It should be possible to have Falcon separate from the normal compiler.
> > > It's just that FlashBuilder will probably not be albe to use it that
> way.
> > > Probably IntelliJ would support this withn a few hours, Flexmojos
> within
> > a
> > > few weeks and FlashBuilder never ;-)
> > >
> > > You shouldn't implement this in the develop branch but create a
> > > feature-branch instead that forks off the develop branch. This way your
> > > changes are available to anyone interested and as soon as the feature
> is
> > > finished, you merge it back to develop.
> > >
> > > Chris
> > > ________________________________________
> > > Von: Erik de Bruin <er...@ixsoftware.nl>
> > > Gesendet: Mittwoch, 2. Juli 2014 09:33
> > > An: dev@flex.apache.org
> > > Betreff: New Flex to JS project
> > >
> > > Hi,
> > >
> > > I'm working on creating a way to publish vanilla Flex SDK projects to
> > > JavaScript on latest gen browsers. This project consists of several sub
> > > projects, and I'm wondering what is the best way forward with regard to
> > > contributing them:
> > >
> > > 1) two new namespaces and accompanying projects in the main Flex SDK:
> > > vf2js_mx and vf2js_s. These namespaces will contain shim objects for
> (you
> > > guessed it) MX and Spark components.
> > >
> > > 2) two new code paths in FalconJX: one for AS and one for MXML
> > >
> > > 3) a new JavaScript library for the components and shims for AS classes
> > >
> > > 4) a testing framework for the JS components, loosely based on
> Marmotinni
> > >
> > > Questions:
> > >
> > > A - I would very much like to work in the 'develop' branches of the
> > > projects involved, but especially on the part of '1)' I'm not sure if I
> > did
> > > it right. All tests I can think of seem to pass, but maybe someone has
> > the
> > > time to do a code review on a branch that I can publish?
> > >
> > > B - In order for this to work, FalconJX needs to be part of the regular
> > SDK
> > > distribution. Folks who did this on the FlexJS overlay: what does it
> take
> > > to make FalconJX part of the SDK?
> > >
> > > That's it, for now :-)
> > >
> > > Thanks,
> > >
> > > 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
> >
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>

AW: New Flex to JS project

[Christofer Dutz <ch...@c-ware.de>]

Have a look at this ... I think it explains things quite well.

https://www.youtube.com/watch?v=cSf8cO0WB4o

Chris

________________________________________
Von: Erik de Bruin <er...@ixsoftware.nl>
Gesendet: Mittwoch, 2. Juli 2014 10:07
An: dev@flex.apache.org
Betreff: Re: New Flex to JS project

Ok, just checking:

I create a local branch, let's call it 'vf2js', off 'origin/develop'. I
select this as my active branch. If I then 'rebase', all changes that have
been made to 'origin/develop' will be pulled into my local branch? So far,
so good. But now I want the world to see what's in my local vf2js branch,
so I 'publish' it. Is keeping the remote copy of my local branch up to date
just a question of 'pushing' all commits to that remote branch? Will
changes that come from the remote 'develop' via my local 'vf2js' also in
the remote 'vf2js' that way?

Thanks,

EdB



On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz <ch...@c-ware.de>
wrote:

> No effort at all ... that's what GIT rebase is for.
>
> You can think of this sort of an automated "Create-Patch, Revert, Update,
> Apply Patch" ... if all goes well, it's just this one command, if there are
> conflicts, you get the usual conflict editor you would get anyway if you
> created conflicts on develop.
>
> Chris
>
>
> ________________________________________
> Von: Erik de Bruin <er...@ixsoftware.nl>
> Gesendet: Mittwoch, 2. Juli 2014 09:50
> An: dev@flex.apache.org
> Betreff: Re: New Flex to JS project
>
> Hi Chris,
>
> Thanks for the feedback.
>
> I'm talking about FalconJX, not Falcon. The latter is the "new" SWF
> compiler, the former is the Flex to JavaScript cross compiler.
>
> I guess a feature branch might work... But I'm afraid that keeping that
> branch up to date with the 'develop' branch will add extra work. How to
> best handle that part, so I don't spend what little time I have on Git
> stuff instead of code?
>
> EdB
>
>
>
>
> On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz <christofer.dutz@c-ware.de
> >
> wrote:
>
> > I think the reason for the overlay is that by this we are tricking the
> > FlashBuilder to use Falcon instead of the old compiler.
> > It should be possible to have Falcon separate from the normal compiler.
> > It's just that FlashBuilder will probably not be albe to use it that way.
> > Probably IntelliJ would support this withn a few hours, Flexmojos within
> a
> > few weeks and FlashBuilder never ;-)
> >
> > You shouldn't implement this in the develop branch but create a
> > feature-branch instead that forks off the develop branch. This way your
> > changes are available to anyone interested and as soon as the feature is
> > finished, you merge it back to develop.
> >
> > Chris
> > ________________________________________
> > Von: Erik de Bruin <er...@ixsoftware.nl>
> > Gesendet: Mittwoch, 2. Juli 2014 09:33
> > An: dev@flex.apache.org
> > Betreff: New Flex to JS project
> >
> > Hi,
> >
> > I'm working on creating a way to publish vanilla Flex SDK projects to
> > JavaScript on latest gen browsers. This project consists of several sub
> > projects, and I'm wondering what is the best way forward with regard to
> > contributing them:
> >
> > 1) two new namespaces and accompanying projects in the main Flex SDK:
> > vf2js_mx and vf2js_s. These namespaces will contain shim objects for (you
> > guessed it) MX and Spark components.
> >
> > 2) two new code paths in FalconJX: one for AS and one for MXML
> >
> > 3) a new JavaScript library for the components and shims for AS classes
> >
> > 4) a testing framework for the JS components, loosely based on Marmotinni
> >
> > Questions:
> >
> > A - I would very much like to work in the 'develop' branches of the
> > projects involved, but especially on the part of '1)' I'm not sure if I
> did
> > it right. All tests I can think of seem to pass, but maybe someone has
> the
> > time to do a code review on a branch that I can publish?
> >
> > B - In order for this to work, FalconJX needs to be part of the regular
> SDK
> > distribution. Folks who did this on the FlexJS overlay: what does it take
> > to make FalconJX part of the SDK?
> >
> > That's it, for now :-)
> >
> > Thanks,
> >
> > 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
>



--
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

Re: New Flex to JS project

[Erik de Bruin <er...@ixsoftware.nl>]

Ok, just checking:

I create a local branch, let's call it 'vf2js', off 'origin/develop'. I
select this as my active branch. If I then 'rebase', all changes that have
been made to 'origin/develop' will be pulled into my local branch? So far,
so good. But now I want the world to see what's in my local vf2js branch,
so I 'publish' it. Is keeping the remote copy of my local branch up to date
just a question of 'pushing' all commits to that remote branch? Will
changes that come from the remote 'develop' via my local 'vf2js' also in
the remote 'vf2js' that way?

Thanks,

EdB



On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz <ch...@c-ware.de>
wrote:

> No effort at all ... that's what GIT rebase is for.
>
> You can think of this sort of an automated "Create-Patch, Revert, Update,
> Apply Patch" ... if all goes well, it's just this one command, if there are
> conflicts, you get the usual conflict editor you would get anyway if you
> created conflicts on develop.
>
> Chris
>
>
> ________________________________________
> Von: Erik de Bruin <er...@ixsoftware.nl>
> Gesendet: Mittwoch, 2. Juli 2014 09:50
> An: dev@flex.apache.org
> Betreff: Re: New Flex to JS project
>
> Hi Chris,
>
> Thanks for the feedback.
>
> I'm talking about FalconJX, not Falcon. The latter is the "new" SWF
> compiler, the former is the Flex to JavaScript cross compiler.
>
> I guess a feature branch might work... But I'm afraid that keeping that
> branch up to date with the 'develop' branch will add extra work. How to
> best handle that part, so I don't spend what little time I have on Git
> stuff instead of code?
>
> EdB
>
>
>
>
> On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz <christofer.dutz@c-ware.de
> >
> wrote:
>
> > I think the reason for the overlay is that by this we are tricking the
> > FlashBuilder to use Falcon instead of the old compiler.
> > It should be possible to have Falcon separate from the normal compiler.
> > It's just that FlashBuilder will probably not be albe to use it that way.
> > Probably IntelliJ would support this withn a few hours, Flexmojos within
> a
> > few weeks and FlashBuilder never ;-)
> >
> > You shouldn't implement this in the develop branch but create a
> > feature-branch instead that forks off the develop branch. This way your
> > changes are available to anyone interested and as soon as the feature is
> > finished, you merge it back to develop.
> >
> > Chris
> > ________________________________________
> > Von: Erik de Bruin <er...@ixsoftware.nl>
> > Gesendet: Mittwoch, 2. Juli 2014 09:33
> > An: dev@flex.apache.org
> > Betreff: New Flex to JS project
> >
> > Hi,
> >
> > I'm working on creating a way to publish vanilla Flex SDK projects to
> > JavaScript on latest gen browsers. This project consists of several sub
> > projects, and I'm wondering what is the best way forward with regard to
> > contributing them:
> >
> > 1) two new namespaces and accompanying projects in the main Flex SDK:
> > vf2js_mx and vf2js_s. These namespaces will contain shim objects for (you
> > guessed it) MX and Spark components.
> >
> > 2) two new code paths in FalconJX: one for AS and one for MXML
> >
> > 3) a new JavaScript library for the components and shims for AS classes
> >
> > 4) a testing framework for the JS components, loosely based on Marmotinni
> >
> > Questions:
> >
> > A - I would very much like to work in the 'develop' branches of the
> > projects involved, but especially on the part of '1)' I'm not sure if I
> did
> > it right. All tests I can think of seem to pass, but maybe someone has
> the
> > time to do a code review on a branch that I can publish?
> >
> > B - In order for this to work, FalconJX needs to be part of the regular
> SDK
> > distribution. Folks who did this on the FlexJS overlay: what does it take
> > to make FalconJX part of the SDK?
> >
> > That's it, for now :-)
> >
> > Thanks,
> >
> > 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
>



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

AW: New Flex to JS project

[Christofer Dutz <ch...@c-ware.de>]

No effort at all ... that's what GIT rebase is for.

You can think of this sort of an automated "Create-Patch, Revert, Update, Apply Patch" ... if all goes well, it's just this one command, if there are conflicts, you get the usual conflict editor you would get anyway if you created conflicts on develop.

Chris


________________________________________
Von: Erik de Bruin <er...@ixsoftware.nl>
Gesendet: Mittwoch, 2. Juli 2014 09:50
An: dev@flex.apache.org
Betreff: Re: New Flex to JS project

Hi Chris,

Thanks for the feedback.

I'm talking about FalconJX, not Falcon. The latter is the "new" SWF
compiler, the former is the Flex to JavaScript cross compiler.

I guess a feature branch might work... But I'm afraid that keeping that
branch up to date with the 'develop' branch will add extra work. How to
best handle that part, so I don't spend what little time I have on Git
stuff instead of code?

EdB




On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz <ch...@c-ware.de>
wrote:

> I think the reason for the overlay is that by this we are tricking the
> FlashBuilder to use Falcon instead of the old compiler.
> It should be possible to have Falcon separate from the normal compiler.
> It's just that FlashBuilder will probably not be albe to use it that way.
> Probably IntelliJ would support this withn a few hours, Flexmojos within a
> few weeks and FlashBuilder never ;-)
>
> You shouldn't implement this in the develop branch but create a
> feature-branch instead that forks off the develop branch. This way your
> changes are available to anyone interested and as soon as the feature is
> finished, you merge it back to develop.
>
> Chris
> ________________________________________
> Von: Erik de Bruin <er...@ixsoftware.nl>
> Gesendet: Mittwoch, 2. Juli 2014 09:33
> An: dev@flex.apache.org
> Betreff: New Flex to JS project
>
> Hi,
>
> I'm working on creating a way to publish vanilla Flex SDK projects to
> JavaScript on latest gen browsers. This project consists of several sub
> projects, and I'm wondering what is the best way forward with regard to
> contributing them:
>
> 1) two new namespaces and accompanying projects in the main Flex SDK:
> vf2js_mx and vf2js_s. These namespaces will contain shim objects for (you
> guessed it) MX and Spark components.
>
> 2) two new code paths in FalconJX: one for AS and one for MXML
>
> 3) a new JavaScript library for the components and shims for AS classes
>
> 4) a testing framework for the JS components, loosely based on Marmotinni
>
> Questions:
>
> A - I would very much like to work in the 'develop' branches of the
> projects involved, but especially on the part of '1)' I'm not sure if I did
> it right. All tests I can think of seem to pass, but maybe someone has the
> time to do a code review on a branch that I can publish?
>
> B - In order for this to work, FalconJX needs to be part of the regular SDK
> distribution. Folks who did this on the FlexJS overlay: what does it take
> to make FalconJX part of the SDK?
>
> That's it, for now :-)
>
> Thanks,
>
> 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: New Flex to JS project

[Erik de Bruin <er...@ixsoftware.nl>]

Hi Chris,

Thanks for the feedback.

I'm talking about FalconJX, not Falcon. The latter is the "new" SWF
compiler, the former is the Flex to JavaScript cross compiler.

I guess a feature branch might work... But I'm afraid that keeping that
branch up to date with the 'develop' branch will add extra work. How to
best handle that part, so I don't spend what little time I have on Git
stuff instead of code?

EdB




On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz <ch...@c-ware.de>
wrote:

> I think the reason for the overlay is that by this we are tricking the
> FlashBuilder to use Falcon instead of the old compiler.
> It should be possible to have Falcon separate from the normal compiler.
> It's just that FlashBuilder will probably not be albe to use it that way.
> Probably IntelliJ would support this withn a few hours, Flexmojos within a
> few weeks and FlashBuilder never ;-)
>
> You shouldn't implement this in the develop branch but create a
> feature-branch instead that forks off the develop branch. This way your
> changes are available to anyone interested and as soon as the feature is
> finished, you merge it back to develop.
>
> Chris
> ________________________________________
> Von: Erik de Bruin <er...@ixsoftware.nl>
> Gesendet: Mittwoch, 2. Juli 2014 09:33
> An: dev@flex.apache.org
> Betreff: New Flex to JS project
>
> Hi,
>
> I'm working on creating a way to publish vanilla Flex SDK projects to
> JavaScript on latest gen browsers. This project consists of several sub
> projects, and I'm wondering what is the best way forward with regard to
> contributing them:
>
> 1) two new namespaces and accompanying projects in the main Flex SDK:
> vf2js_mx and vf2js_s. These namespaces will contain shim objects for (you
> guessed it) MX and Spark components.
>
> 2) two new code paths in FalconJX: one for AS and one for MXML
>
> 3) a new JavaScript library for the components and shims for AS classes
>
> 4) a testing framework for the JS components, loosely based on Marmotinni
>
> Questions:
>
> A - I would very much like to work in the 'develop' branches of the
> projects involved, but especially on the part of '1)' I'm not sure if I did
> it right. All tests I can think of seem to pass, but maybe someone has the
> time to do a code review on a branch that I can publish?
>
> B - In order for this to work, FalconJX needs to be part of the regular SDK
> distribution. Folks who did this on the FlexJS overlay: what does it take
> to make FalconJX part of the SDK?
>
> That's it, for now :-)
>
> Thanks,
>
> 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

AW: New Flex to JS project

[Christofer Dutz <ch...@c-ware.de>]

I think the reason for the overlay is that by this we are tricking the FlashBuilder to use Falcon instead of the old compiler.
It should be possible to have Falcon separate from the normal compiler. It's just that FlashBuilder will probably not be albe to use it that way.
Probably IntelliJ would support this withn a few hours, Flexmojos within a few weeks and FlashBuilder never ;-)

You shouldn't implement this in the develop branch but create a feature-branch instead that forks off the develop branch. This way your changes are available to anyone interested and as soon as the feature is finished, you merge it back to develop.

Chris
________________________________________
Von: Erik de Bruin <er...@ixsoftware.nl>
Gesendet: Mittwoch, 2. Juli 2014 09:33
An: dev@flex.apache.org
Betreff: New Flex to JS project

Hi,

I'm working on creating a way to publish vanilla Flex SDK projects to
JavaScript on latest gen browsers. This project consists of several sub
projects, and I'm wondering what is the best way forward with regard to
contributing them:

1) two new namespaces and accompanying projects in the main Flex SDK:
vf2js_mx and vf2js_s. These namespaces will contain shim objects for (you
guessed it) MX and Spark components.

2) two new code paths in FalconJX: one for AS and one for MXML

3) a new JavaScript library for the components and shims for AS classes

4) a testing framework for the JS components, loosely based on Marmotinni

Questions:

A - I would very much like to work in the 'develop' branches of the
projects involved, but especially on the part of '1)' I'm not sure if I did
it right. All tests I can think of seem to pass, but maybe someone has the
time to do a code review on a branch that I can publish?

B - In order for this to work, FalconJX needs to be part of the regular SDK
distribution. Folks who did this on the FlexJS overlay: what does it take
to make FalconJX part of the SDK?

That's it, for now :-)

Thanks,

EdB



--
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

Re: New Flex to JS project

[Erik de Bruin <er...@ixsoftware.nl>]

Nobody will ever have to use these namespaces in their projects. The
compiler replaces the 's' and 'mx' namespaces with 'vf2js_mx' and 'vf2js_s'
in a temp copy of the project which is only used published to JS before
being deleted again. The shim components in these namespaces are there only
to get feedback from the compiler about any 's' or 'mx' component
properties the project may contain that are not supported on the JS side.

EdB




On Wed, Jul 2, 2014 at 4:57 PM, Justin Mclean <ju...@classsoftware.com>
wrote:

> Hi,
>
> > 1) two new namespaces and accompanying projects in the main Flex SDK:
> > vf2js_mx and vf2js_s. These namespaces will contain shim objects for (you
> > guessed it) MX and Spark components.
>
> Perhaps a friendlier namesace name? mxshim and sshim? or just mxjs and sjs?
>
> Justin
>



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

Re: New Flex to JS project

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> 1) two new namespaces and accompanying projects in the main Flex SDK:
> vf2js_mx and vf2js_s. These namespaces will contain shim objects for (you
> guessed it) MX and Spark components.

Perhaps a friendlier namesace name? mxshim and sshim? or just mxjs and sjs?

Justin

Re:Re: New Flex to JS project

[DarkStone <da...@163.com>]

Hi Alex,

One very important thing I have to point out:

The hardware of the mobile devices are improving rapidly, way faster than the way of the desktop devices do.

In China, there are already millions of Android phones with 2GB RAM + 4 Core CPU, under the price of $100, and I just bought a 2GB RAM + 8 Core CPU + 5 inches screen of Android phone for my mom last month, cost me ￥680 ($108).

Chinese mobile hardware companies are rising, the price war is reaching its climax.

My point is, the mobile applications made with the current Flex SDK are running very smooth in modern cheap mobile devices, and they will be running even smoother in every 3 months.


So I believe the performance issue of Flex is not our primary concerns, no need to re-design the FlexJS architecture from the ground up, just base on the current Spark architecture and make improvements, that's fair enough in my opinion.

I do agree the current Flex SDK is fat and old.
For fat: I think we should get rid of the halo (mx) legacy stuff, and continue improving the Spark architecture to lose weight and gain performance.
For old: I think we should focus more on the mobile supports of Spark framework, like adding more mobile components and skin themes (I know Om is working on one).

DarkStone
2014-07-09


At 2014-07-09 01:10:03, "Alex Harui" <ah...@adobe.com> wrote:
>Hi Erik,
>
>Thanks for the list.  I think this is a valuable discussion.  I'm going to
>respond out of order: hopefully the easiest answers first.  Then at the
>end is more of my continually evolving thoughts on FlexJS that may be hard
>to capture from the slides.
>
>First, keep in mind that one of the FlexJS goals is to support multiple
>component sets.  Unlike current Flex's Spark or MX, the "basic" components
>isn't intended to be a one-size-fits-all component set.  There are already
>the beginnings of component sets for JQUery and CreateJS and Cordova.
>
>Anyway, regarding #4 (MVC).  I originally thought that there would be some
>advantage when cross-compiling to having folks separate business and
>controller logic from view.  However, folks have complained about it, and
>I haven't really seen any advantages so far so in FlexJS 0.0.3 or 0.0.4
>I'll probably remove the MVC requirement.  Having the option of creating
>single-file apps is much more friendly.
>
>#5 (lack of direction).  I call that "exploring", but yeah, I don't have a
>crystal ball to know where we need to end up.  We are changing as we
>discover things and our users provide feedback.  I think that's a good
>strategy and fits with the Apache Way.
>
>#1 (Migration Path).  There is a migration path.  I think it is very
>similar to what you envision for your approach.  You simply switch from a
>current Flex SDK to a FlexJS SDK.  You choose between replacing all mx and
>spark prefixes or replacing just the URI in the xmlns.  Could we add an
>option to Falcon to override xmlns URIs?  Sure, if that's what folks want.
>
>#2 (writing both AS and JS code).  Actually, it is turning out that we are
>not writing both AS and JS as much as I thought we would.  The FlexJSJX
>SWC and components like DataGrid and BarChart don't have any JS
>equivalents in the repo.  The AS in that SWC is cross-compiled.  It is
>looking like lots of components are "higher-level" and can be composed of
>widgets from the FlexJSUI SWC.  But yes, we are writing enough AS so the
>SWF version is operational.  This should provide several developer
>benefits: runtime verification of your code for highly dynamic
>applications, reduced testing if you can deploy SWFs on most browsers, a
>way to support older browsers.
>
>#3 (beads).  There is no requirement that the application developers have
>to deal with a ton of beads.  Only component developers that want to make
>general-purpose components may want to take advantage of beads.  The
>"basic" components Peter and I (and hopefully others someday) are working
>on are trying to leverage beads in order to make sure there is clean
>separation of concerns in the framework code (vs 13,000 line base classes)
>so that some of these pieces can be re-used for other component sets.
>Then we're testing the waters to see whether application developers like
>beads or not.  If not, we can always "bake-in" beads into higher-level
>components.  But at least we'll know that if someone is desperately trying
>to shave off code it is possible.
>
>And from your other post about GCC optimization:  Maybe download size
>doesn't matter and maybe GCC is so good you can add more code without any
>performance and size implications, but that sort of defies logic to me.
>It has been my experience that frameworks grow over time as you add
>features and fix bugs.  And it has been my experience that folks will give
>up on frameworks for size and performance.  That's why a significant
>number of mobile AIR apps do not use Flex and are written in bare-bones
>AS.  I want Apache Flex to have a next-generation framework composed of
>pieces so fewer folks have to bail out.  As we add more features to
>FlexJS, I hope the examples don't grow in size.  IMO, they will for your
>VJS implementation because eventually, the VJS Button needs to wire in the
>code for tooltips even on mobile apps that will never use them.  Or a
>heavy ResourceManager implementation for apps that only need to localize
>strings.  There are 120+ public APIs on Spark Button most apps only use a
>small fraction.
>
>Another thing about FlexJS that has evolved over time is that I am
>thinking that the key advantage of FlexJS is simply in being the best way
>to glue JS together into an application.  The "basic" components will be
>useful to many, but some folks have requirements to use certain JS
>frameworks.  With the SWF version checking your code at runtime, with MXML
>giving you a schematic diagram, I hope to see component sets for Angular
>and other JS frameworks as well as the filling out of the Jquery and
>CreateJS sets, and possible different back-ends outputting to TypeScript
>and/or Dart.  The beads create highly re-usable pieces for folks to build
>out these component sets and the result has little overhead compared to a
>manual port to that same JS framework.  I believe we will always be
>compared to how fast and small a true JS application will be.
>
>So, the way I see it based on my understanding of the VJS approach you
>want to take is that you are just building another component set.  You
>don't have to use beads although I hope you do find some sort of modular
>approach otherwise your UIComponent.js will be 13,000 lines of JS.  My
>hope was that you would build your JS Spark and MX equivalents by
>compositing beads and helping create new beads that we can use in other
>component sets.
>
>Right now you want to hide your AS SWCs and switch to them under the
>covers, but I was thinking you could just make them public SWCs that are
>wrappers of the existing MX and Spark SWCs with some sort of metadata that
>works like the [Deprecated] metadata tag.  I want to teach Falcon to warn
>folks about e4x usage and other things so we both want some sort of
>warning/errors for certain APIs.  But I'm hoping to move the warning phase
>to the AS compile phase instead of waiting until you attempt to
>cross-compile.
>
>So, that's why I see way more similarities than differences.  I'm glad you
>like the current SDK, but I think it has gotten too old, fat, and slow, so
>I am embarking on a next-generation.  I say in one of my slides "if you
>have 10,000 lines of MXML and 100,000 lines of AS, without FlexJS you
>would have to port all of it, with FlexJS you will have to port less."  It
>would be awesome to have some sort of component set where you have to port
>even less.  I'm not clear you can get to zero porting because of things
>like weak references or if you do implement weak references, if there will
>be some cost to it that people will notice when comparing against a true
>JS app.  But then folks can compare and choose. I think the basic
>components will result in smaller faster apps than one that has to support
>all of the ugly interdependencies in the current SDK.  But if I'm wrong,
>that's ok.  We will still have built lots of re-usable pieces to be used
>in the component sets for Jquery, Angular, etc.
>
>I don't know how folks will feel about making API changes to the current
>SDK to support cross-compilation.  By making a wrapper component set, I
>think you won't need to make any changes.  Folks just switch to your VJS
>component set and off they go.
>
>In summary, FlexJS totally supports a component set that is tries to
>emulate Spark and MX.  It just isn't the component set I'm focused on.  If
>we can find common ground on how to warn folks about missing APIs and move
>the warnings to the Falcon compiler, then I think we will truly be on the
>same team, just working on different component sets.
>
>-Alex
>
>On 7/8/14 1:29 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>>OK, here goes - why I think the FlexJS concept can be improved upon (in no
>>particular order):
>>
>>1 - there is no migration path for existing Flex applications; this will
>>make enterprise users reluctant to accept the new framework, even though
>>during development FlexJS is limiting itself because it aims to please the
>>enterprise user (IE 'old' support)
>>2 - FlexJS requires a brand new framework on both the AS and JS side
>>(apart
>>from some stuff that may cross compile), effectively doubling the effort
>>to
>>bring it up to speed with other frameworks - including regular Flex
>>3 - Strands/Beads: it forces developers to know the insides of components,
>>adding a level of complexity and a steeper learning curve to the framework
>>    I - by the time there are enough components/strands and beads to have
>>a
>>useful framework, the set of beads will be too big to easily work with
>>(e.g. "org.apache.flex.html.beads.DataItemRendererFactoryForArrayData" or
>>"org.apache.flex.html.beads.controllers.ListSingleSelectionMouseController
>>")
>>    II - making beads work on all strands makes beads complicated; making
>>beads that don't work on all strands makes beads confusing for the
>>developer
>>4 - forced MVC: as an option it would be great, as a 'feature' not so
>>much:
>>it makes smaller projects unnecessarily complicated (e.g. all examples)
>>5 - lack of direction: FlexJS is a collection of proofs of concept,
>>created
>>top down to make nice looking demos that are then abandoned or superseded
>>by other proofs of concept or demos.
>>
>>I think we already have a pretty nice AS framework, the Flex SDK, which I
>>intend to offer as-is. Rather, I plan to make the 'export to JS' feature a
>>part of the regular Flex SDK. That way the user can open any Flex project,
>>run the export and get a fully functional, identical looking application
>>in
>>JS, or, worst case, a nice list from the compiler explaining which
>>components/properties don't (yet) work in JS and how to fix that.
>>
>>I'm interested to hear more about how you think this approach is related
>>to
>>FlexJS. If there is any synergy to be had, I'm all for it!
>>
>>EdB
>>
>>
>>
>>On Mon, Jul 7, 2014 at 6:27 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>>> I'm not sure what you mean by "philosophical".  I see more similarities
>>> than differences between FlexJS and your approach of trying to mimic
>>>more
>>> of the current SDK in JS.  In fact, I still hope to convince you that
>>>what
>>> you want to do is within the FlexJS charter so we can work together
>>> instead appearing to work on separate efforts.  And then what you are
>>> working on would also be weakened by whatever it is you want to say.  If
>>> you have a killer argument why folks should not be trying to compile
>>>MXML
>>> and AS to JS, I think the whole community will be better served by
>>>finding
>>> out why now.
>>>
>>> -Alex
>>>
>>> On 7/7/14 8:40 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>
>>> >There are no technical issues per se that would need addressing to keep
>>> >FlexJS healthy. I made sure of that.
>>> >
>>> >My argument is basically philosophical, and I think my ranting about
>>>it in
>>> >public would weaken FlexJS' case, so I won't.
>>> >
>>> >EdB
>>> >
>>> >
>>> >
>>> >On Thu, Jul 3, 2014 at 4:47 PM, Alex Harui <ah...@adobe.com> wrote:
>>> >
>>> >> I think it has to be in public.  This is open development.  I'm
>>>hoping
>>> >>you
>>> >> will save me time by doing so.  If we are doing something we
>>>shouldn't
>>> >>we
>>> >> should correct it now otherwise we'll waste time and energy doing
>>>more
>>> >> work in that direction only to find out that customers have the same
>>> >> feedback.
>>> >>
>>> >> Not that all of your feedback is guaranteed to be addressed: there's
>>> >> always a chance that what you don't like is philosophical rather than
>>> >> technical.  That's why there are dozens of JS frameworks already and
>>>why
>>> >> you want to try a different approach.
>>> >>
>>> >> -Alex
>>> >>
>>> >> On 7/3/14 12:00 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>> >>
>>> >> >You want to hear that in public, or do you want to take this off
>>>list?
>>> >> >
>>> >> >EdB
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >On Thu, Jul 3, 2014 at 7:53 AM, Alex Harui <ah...@adobe.com> wrote:
>>> >> >
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> >I've been doing that as well for the last couple of years. I
>>>spent
>>> >> >>most of
>>> >> >> >my time getting FlexJS off the ground. But I don't agree with
>>>some
>>> >>of
>>> >> >>the
>>> >> >> >basic assumptions and choices that FlexJS has made. I said
>>>little or
>>> >> >> >nothing about it to give FlexJS a proper head start and to keep
>>>you
>>> >>and
>>> >> >> >Peter going. But now that I have re-evaluated what the project
>>> >>means to
>>> >> >> >me,
>>> >> >> >and what I would like to spend my time on when contributing, and
>>>I
>>> >> >>have to
>>> >> >> >give my take on Flex to JS a try.
>>> >> >> I'd love to hear your thoughts on what you don't agree with
>>>regarding
>>> >> >> FlexJS.
>>> >> >>
>>> >> >> -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: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

Ah ok. I wasn't aware that the custom UI components was a separate piece.

Thanks,
-Alex

On 7/9/14 11:20 PM, "Harbs" <ha...@gmail.com> wrote:

>Angular does not provide the "lego". Rather, it describes how the pieces
>are supposed to connect and how the pieces should be constructed.
>
>Angular is all about connecting the html markup with javascript.
>
>Angular introduces custom html attributes (the default ones are prefixed
>ng but custom ones can be created as well) which the framework wires
>together (2-way binding) with the model (ng-model) described in the
>$scope of that element. Angular has a elaborate inheritance hierarchy of
>html elements where html elements ³inherit² the $scope of its parent
>element unless it uses a different ng-model.
>
>All the built-in Angular attributes are *behaviors* rather than
>*components*. You could probably put those in two categories:
>1. Those which extend default HTML behavior (i.e. ng-show, ng-mousedown,
>ng-src, etc.)
>2. "functional" attributes like ng-repeat, ng-switch on, etc.
>
>The first category binds javascript objects and properties with html
>elements, while the second category actually changes the html structure.
>
>Of course custom components can be (and should be) created and that¹s
>what AngularUI[1] is all about, but it¹s not part of the core framework.
>
>Does this make more sense?
>
>HTH,
>Harbs
>
>[1] http://angular-ui.github.io/
>On Jul 10, 2014, at 8:57 AM, Alex Harui <ah...@adobe.com> wrote:
>
>> I'm still trying to understand why you don't think there is "lego" in
>> Angular.
>

Re: New Flex to JS project

[Harbs <ha...@gmail.com>]

Angular does not provide the "lego". Rather, it describes how the pieces are supposed to connect and how the pieces should be constructed.

Angular is all about connecting the html markup with javascript.

Angular introduces custom html attributes (the default ones are prefixed ng but custom ones can be created as well) which the framework wires together (2-way binding) with the model (ng-model) described in the $scope of that element. Angular has a elaborate inheritance hierarchy of html elements where html elements “inherit” the $scope of its parent element unless it uses a different ng-model.

All the built-in Angular attributes are *behaviors* rather than *components*. You could probably put those in two categories:
1. Those which extend default HTML behavior (i.e. ng-show, ng-mousedown, ng-src, etc.)
2. "functional" attributes like ng-repeat, ng-switch on, etc.

The first category binds javascript objects and properties with html elements, while the second category actually changes the html structure.

Of course custom components can be (and should be) created and that’s what AngularUI[1] is all about, but it’s not part of the core framework.

Does this make more sense?

HTH,
Harbs

[1] http://angular-ui.github.io/
On Jul 10, 2014, at 8:57 AM, Alex Harui <ah...@adobe.com> wrote:

> I'm still trying to understand why you don't think there is "lego" in
> Angular.

Re: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

On 7/9/14 3:32 PM, "Harbs" <ha...@gmail.com> wrote:

>It seems to me there¹s a question of perception as to what ³Flex² is.
>
>Historically, Flex has been an application framework centered around
>components. The equivalent in the JS world would probably be something
>like Sencha¹s UI frameworks. (i.e. ext js) or JQuery UI. So, when people
>hear ³Flex² they think ³application lego².
>
>Flex also has the functionality of the class of frameworks (in the js
>world) like Ember or Angular which deal mostly with data consumption and
>data binding. Very little lego there. It¹s more the glue that holds stuff
>together.
>
>We also have the Falcon compiler which enables cross-compiling
>ActionScript irrespective of the application components (ala ext js) or
>the application ³glue² ala Angular.
>
>It seems to me that to call all of these things ³FlexJS² seems too broad
>to prevent confusion. It seems to me that there needs to be a distinction
>between these different areas of capabilities.
>
>Thoughts?
Awesome.  I liked your breakdown of the pieces.  I'm definitely open to
ideas around naming.  Hopefully others will offer ideas as well.

I'm still trying to understand why you don't think there is "lego" in
Angular.  I'm not saying you're wrong because all I've really done is read
some of the web-site stuff.  The web-site at [1] looks like it is
introducing custom HTML UI tags.  I thought that was also part of the
reason for its name (the angle brackets in HTML).

[1] https://angularjs.org


-Alex

Re: New Flex to JS project

[Harbs <ha...@gmail.com>]

It seems to me there’s a question of perception as to what “Flex” is.

Historically, Flex has been an application framework centered around components. The equivalent in the JS world would probably be something like Sencha’s UI frameworks. (i.e. ext js) or JQuery UI. So, when people hear “Flex” they think “application lego”.

Flex also has the functionality of the class of frameworks (in the js world) like Ember or Angular which deal mostly with data consumption and data binding. Very little lego there. It’s more the glue that holds stuff together.

We also have the Falcon compiler which enables cross-compiling ActionScript irrespective of the application components (ala ext js) or the application “glue” ala Angular.

It seems to me that to call all of these things “FlexJS” seems too broad to prevent confusion. It seems to me that there needs to be a distinction between these different areas of capabilities.

Thoughts?

On Jul 10, 2014, at 12:43 AM, Alex Harui <ah...@adobe.com> wrote:

> Well, like I said, I'm not an expert on this stuff.  My brief look at
> Angular gave me the impression that it was about declarative markup for an
> extensible component model.  I think that's what we have too.
> 
> The key point that I'm not sure is sticking with folks is that FlexJS may
> have a default framework, but I really want it to be framework-agnostic.
> A framework developer can implement, mimic or mock the JS components from
> some JS framework in an AS SWC to enable the application developer to glue
> their favorite JS components together with AS.  Then the final
> cross-compiled output has a much better chance of working correctly, and
> the net should be better developer productivity.
> 
> -Alex
> 
> On 7/9/14 11:13 AM, "Harbs" <ha...@gmail.com> wrote:
> 
>> Hmm.
>> 
>> I might have been misunderstanding you.
>> 
>> I thought you were discussing getting FlexJS with mxml markup, data
>> binding and everything else to work with Angular. That’s what I don’t see
>> as a fit.
>> 
>> If you mean to simply write Angular applications in AS instead of JS and
>> cross-compile using FalconJX, then yes, that should (probably) work.
>> Besides TypeScript, you can also use CoffeeScript as well as Angular Dart.
>> 
>> I can see an argument to write Angular in AS, but that is just utilizing
>> the compiler, rather than the FlexJS framework as a whole. I also don’t
>> think that it makes sense to create an ActionScript compile target for
>> Angular apps.
>> 
>> Harbs
>> 
>> On Jul 9, 2014, at 8:48 PM, Alex Harui <ah...@adobe.com> wrote:
>> 
>>> OK, I'll try to find time to read up on Angular.  It does appear that
>>> TypeScript works with Angular.  My rudimentary understanding of this
>>> stuff
>>> says that if you can use TS you should be able to use AS as well, but I
>>> could certainly be wrong.
>>> 
>>> -Alex
>>> 
>>> On 7/9/14 10:43 AM, "Harbs" <ha...@gmail.com> wrote:
>>> 
>>>> FWIW, here’s some Angular-compatible components:
>>>> http://angular-ui.github.io/
>>>> http://angular-ui.github.io/bootstrap/
>>>> http://angular-ui.github.io/ng-grid/
>>>> 
>>>> and a whole site dedicated to cataloging Angular modules (some of it
>>>> UI,
>>>> and some of it business logic):
>>>> http://ngmodules.org/
>>>> 
>>>> As you can see, except for the basic HTML elements, any UI that is used
>>>> with Angular is going to be external modules from either existing UI
>>>> frameworks (i.e. Bootstrap), or ones built specifically for Angular.
>>>> None
>>>> of these are part of the core Angular framework.
>>>> 
>>>> I do think that for FlexJS to be successful, we would need some kind of
>>>> public catalog of external modules (components) similar to the
>>>> ngmodules
>>>> site.
>>>> 
>>>> On Jul 9, 2014, at 8:11 PM, Harbs <ha...@gmail.com> wrote:
>>>> 
>>>>> Angular is not really components. It’s more the glue that holds the
>>>>> components together.
>>>>> 
>>>>> Basically, the selling point of Angular is how it binds javascript to
>>>>> HTML. Building custom Angular components is the hardest part of using
>>>>> the framework (and for the most part is not part of the framework
>>>>> itself). They call them “directives” and they have very unintuitive
>>>>> json
>>>>> markup that goes with the js code.
>>>>> 
>>>>> Angular pretty strongly prescribes how the app is put together and
>>>>> it’s
>>>>> comprised of HTML template and directive files which comprise the
>>>>> view,
>>>>> and controller/factory/service files which comprise the model and
>>>>> controller.
>>>>> 
>>>>> 
>>>>> On Jul 9, 2014, at 7:44 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 7/9/14 9:16 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>> 
>>>>>>> I wouldn¹t call myself an expert on the subject, but I have had the
>>>>>>> opportunity to familiarize myself with both Angular and Create.js
>>>>>>> the
>>>>>>> past half year.
>>>>>>> 
>>>>>>> Create.js makes sense to integrate into FlexJS. I¹m not sure I
>>>>>>> understand
>>>>>>> how Angular would/could be integrated. It seems to me that Angular
>>>>>>> is
>>>>>>> a
>>>>>>> competing framework and I don¹t understand how the two could work
>>>>>>> together.
>>>>>> IMO, most JS frameworks offer a set of components that you glue
>>>>>> together
>>>>>> with JS.  I'm not an expert on these frameworks, but I think Angular
>>>>>> is
>>>>>> one of them.  Assuming the JS framework is not buggy, I think there
>>>>>> is
>>>>>> a
>>>>>> lot of pain in writing and debugging the JS code that glues the
>>>>>> components
>>>>>> together (the rest of the pain is probably in browser-specific
>>>>>> issues).
>>>>>> TypeScript seems to have reached the same conclusion and offers a new
>>>>>> language to do the gluing.  I'd say Dart and GWT also have the same
>>>>>> thoughts.
>>>>>> 
>>>>>> FlexJS has the potential to be on-par or better as a way to do the
>>>>>> gluing.
>>>>>> We have IDEs, we have runtime verification, and we have declarative
>>>>>> markup in MXML.
>>>>>> 
>>>>>> Think of it this way.  If IKEA or other assemble-it-yourself
>>>>>> furniture
>>>>>> makers shipped you a box of pieces cut to size and then just nails
>>>>>> and
>>>>>> screws and pre-drilled holes, you'd make a lot of mistakes building
>>>>>> the
>>>>>> furniture.  Instead, these manufacturers use special connectors
>>>>>> making
>>>>>> it
>>>>>> much more clear what goes where and making it impossible to make
>>>>>> certain
>>>>>> kinds of errors.
>>>>>> 
>>>>>> IMO, classes are those special connectors.  JS is just nails and
>>>>>> screws.
>>>>>> In JS, you can attach anything to anything and won't find out until
>>>>>> much
>>>>>> later.  In FlexJS, we can offer both better connectors and a
>>>>>> schematic
>>>>>> diagram (MXML).
>>>>>> 
>>>>>> -Alex
>>>>>> 
>>>>>>> 
>>>>>>> On Jul 9, 2014, at 5:28 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>>>> 
>>>>>>>> I hope to attract Jquery, Angular,
>>>>>>>> CreateJS experts and fans to build out these frameworks and making
>>>>>>>> them
>>>>>>>> wade through the current SDK would probably be an inhibitor to
>>>>>>>> them.
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

Re: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

Well, like I said, I'm not an expert on this stuff.  My brief look at
Angular gave me the impression that it was about declarative markup for an
extensible component model.  I think that's what we have too.

The key point that I'm not sure is sticking with folks is that FlexJS may
have a default framework, but I really want it to be framework-agnostic.
A framework developer can implement, mimic or mock the JS components from
some JS framework in an AS SWC to enable the application developer to glue
their favorite JS components together with AS.  Then the final
cross-compiled output has a much better chance of working correctly, and
the net should be better developer productivity.

-Alex

On 7/9/14 11:13 AM, "Harbs" <ha...@gmail.com> wrote:

>Hmm.
>
>I might have been misunderstanding you.
>
>I thought you were discussing getting FlexJS with mxml markup, data
>binding and everything else to work with Angular. That’s what I don’t see
>as a fit.
>
>If you mean to simply write Angular applications in AS instead of JS and
>cross-compile using FalconJX, then yes, that should (probably) work.
>Besides TypeScript, you can also use CoffeeScript as well as Angular Dart.
>
>I can see an argument to write Angular in AS, but that is just utilizing
>the compiler, rather than the FlexJS framework as a whole. I also don’t
>think that it makes sense to create an ActionScript compile target for
>Angular apps.
>
>Harbs
>
>On Jul 9, 2014, at 8:48 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> OK, I'll try to find time to read up on Angular.  It does appear that
>> TypeScript works with Angular.  My rudimentary understanding of this
>>stuff
>> says that if you can use TS you should be able to use AS as well, but I
>> could certainly be wrong.
>> 
>> -Alex
>> 
>> On 7/9/14 10:43 AM, "Harbs" <ha...@gmail.com> wrote:
>> 
>>> FWIW, here’s some Angular-compatible components:
>>> http://angular-ui.github.io/
>>> http://angular-ui.github.io/bootstrap/
>>> http://angular-ui.github.io/ng-grid/
>>> 
>>> and a whole site dedicated to cataloging Angular modules (some of it
>>>UI,
>>> and some of it business logic):
>>> http://ngmodules.org/
>>> 
>>> As you can see, except for the basic HTML elements, any UI that is used
>>> with Angular is going to be external modules from either existing UI
>>> frameworks (i.e. Bootstrap), or ones built specifically for Angular.
>>>None
>>> of these are part of the core Angular framework.
>>> 
>>> I do think that for FlexJS to be successful, we would need some kind of
>>> public catalog of external modules (components) similar to the
>>>ngmodules
>>> site.
>>> 
>>> On Jul 9, 2014, at 8:11 PM, Harbs <ha...@gmail.com> wrote:
>>> 
>>>> Angular is not really components. It’s more the glue that holds the
>>>> components together.
>>>> 
>>>> Basically, the selling point of Angular is how it binds javascript to
>>>> HTML. Building custom Angular components is the hardest part of using
>>>> the framework (and for the most part is not part of the framework
>>>> itself). They call them “directives” and they have very unintuitive
>>>>json
>>>> markup that goes with the js code.
>>>> 
>>>> Angular pretty strongly prescribes how the app is put together and
>>>>it’s
>>>> comprised of HTML template and directive files which comprise the
>>>>view,
>>>> and controller/factory/service files which comprise the model and
>>>> controller.
>>>> 
>>>> 
>>>> On Jul 9, 2014, at 7:44 PM, Alex Harui <ah...@adobe.com> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On 7/9/14 9:16 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>> 
>>>>>> I wouldn¹t call myself an expert on the subject, but I have had the
>>>>>> opportunity to familiarize myself with both Angular and Create.js
>>>>>>the
>>>>>> past half year.
>>>>>> 
>>>>>> Create.js makes sense to integrate into FlexJS. I¹m not sure I
>>>>>> understand
>>>>>> how Angular would/could be integrated. It seems to me that Angular
>>>>>>is
>>>>>> a
>>>>>> competing framework and I don¹t understand how the two could work
>>>>>> together.
>>>>> IMO, most JS frameworks offer a set of components that you glue
>>>>> together
>>>>> with JS.  I'm not an expert on these frameworks, but I think Angular
>>>>>is
>>>>> one of them.  Assuming the JS framework is not buggy, I think there
>>>>>is
>>>>> a
>>>>> lot of pain in writing and debugging the JS code that glues the
>>>>> components
>>>>> together (the rest of the pain is probably in browser-specific
>>>>>issues).
>>>>> TypeScript seems to have reached the same conclusion and offers a new
>>>>> language to do the gluing.  I'd say Dart and GWT also have the same
>>>>> thoughts.
>>>>> 
>>>>> FlexJS has the potential to be on-par or better as a way to do the
>>>>> gluing.
>>>>> We have IDEs, we have runtime verification, and we have declarative
>>>>> markup in MXML.
>>>>> 
>>>>> Think of it this way.  If IKEA or other assemble-it-yourself
>>>>>furniture
>>>>> makers shipped you a box of pieces cut to size and then just nails
>>>>>and
>>>>> screws and pre-drilled holes, you'd make a lot of mistakes building
>>>>>the
>>>>> furniture.  Instead, these manufacturers use special connectors
>>>>>making
>>>>> it
>>>>> much more clear what goes where and making it impossible to make
>>>>> certain
>>>>> kinds of errors.
>>>>> 
>>>>> IMO, classes are those special connectors.  JS is just nails and
>>>>> screws.
>>>>> In JS, you can attach anything to anything and won't find out until
>>>>> much
>>>>> later.  In FlexJS, we can offer both better connectors and a
>>>>>schematic
>>>>> diagram (MXML).
>>>>> 
>>>>> -Alex
>>>>> 
>>>>>> 
>>>>>> On Jul 9, 2014, at 5:28 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>>> 
>>>>>>> I hope to attract Jquery, Angular,
>>>>>>> CreateJS experts and fans to build out these frameworks and making
>>>>>>> them
>>>>>>> wade through the current SDK would probably be an inhibitor to
>>>>>>>them.
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>

Re: New Flex to JS project

[Harbs <ha...@gmail.com>]

Hmm.

I might have been misunderstanding you.

I thought you were discussing getting FlexJS with mxml markup, data binding and everything else to work with Angular. That’s what I don’t see as a fit.

If you mean to simply write Angular applications in AS instead of JS and cross-compile using FalconJX, then yes, that should (probably) work. Besides TypeScript, you can also use CoffeeScript as well as Angular Dart.

I can see an argument to write Angular in AS, but that is just utilizing the compiler, rather than the FlexJS framework as a whole. I also don’t think that it makes sense to create an ActionScript compile target for Angular apps.

Harbs

On Jul 9, 2014, at 8:48 PM, Alex Harui <ah...@adobe.com> wrote:

> OK, I'll try to find time to read up on Angular.  It does appear that
> TypeScript works with Angular.  My rudimentary understanding of this stuff
> says that if you can use TS you should be able to use AS as well, but I
> could certainly be wrong.
> 
> -Alex
> 
> On 7/9/14 10:43 AM, "Harbs" <ha...@gmail.com> wrote:
> 
>> FWIW, here’s some Angular-compatible components:
>> http://angular-ui.github.io/
>> http://angular-ui.github.io/bootstrap/
>> http://angular-ui.github.io/ng-grid/
>> 
>> and a whole site dedicated to cataloging Angular modules (some of it UI,
>> and some of it business logic):
>> http://ngmodules.org/
>> 
>> As you can see, except for the basic HTML elements, any UI that is used
>> with Angular is going to be external modules from either existing UI
>> frameworks (i.e. Bootstrap), or ones built specifically for Angular. None
>> of these are part of the core Angular framework.
>> 
>> I do think that for FlexJS to be successful, we would need some kind of
>> public catalog of external modules (components) similar to the ngmodules
>> site.
>> 
>> On Jul 9, 2014, at 8:11 PM, Harbs <ha...@gmail.com> wrote:
>> 
>>> Angular is not really components. It’s more the glue that holds the
>>> components together.
>>> 
>>> Basically, the selling point of Angular is how it binds javascript to
>>> HTML. Building custom Angular components is the hardest part of using
>>> the framework (and for the most part is not part of the framework
>>> itself). They call them “directives” and they have very unintuitive json
>>> markup that goes with the js code.
>>> 
>>> Angular pretty strongly prescribes how the app is put together and it’s
>>> comprised of HTML template and directive files which comprise the view,
>>> and controller/factory/service files which comprise the model and
>>> controller.
>>> 
>>> 
>>> On Jul 9, 2014, at 7:44 PM, Alex Harui <ah...@adobe.com> wrote:
>>> 
>>>> 
>>>> 
>>>> On 7/9/14 9:16 AM, "Harbs" <ha...@gmail.com> wrote:
>>>> 
>>>>> I wouldn¹t call myself an expert on the subject, but I have had the
>>>>> opportunity to familiarize myself with both Angular and Create.js the
>>>>> past half year.
>>>>> 
>>>>> Create.js makes sense to integrate into FlexJS. I¹m not sure I
>>>>> understand
>>>>> how Angular would/could be integrated. It seems to me that Angular is
>>>>> a
>>>>> competing framework and I don¹t understand how the two could work
>>>>> together.
>>>> IMO, most JS frameworks offer a set of components that you glue
>>>> together
>>>> with JS.  I'm not an expert on these frameworks, but I think Angular is
>>>> one of them.  Assuming the JS framework is not buggy, I think there is
>>>> a
>>>> lot of pain in writing and debugging the JS code that glues the
>>>> components
>>>> together (the rest of the pain is probably in browser-specific issues).
>>>> TypeScript seems to have reached the same conclusion and offers a new
>>>> language to do the gluing.  I'd say Dart and GWT also have the same
>>>> thoughts.
>>>> 
>>>> FlexJS has the potential to be on-par or better as a way to do the
>>>> gluing.
>>>> We have IDEs, we have runtime verification, and we have declarative
>>>> markup in MXML.
>>>> 
>>>> Think of it this way.  If IKEA or other assemble-it-yourself furniture
>>>> makers shipped you a box of pieces cut to size and then just nails and
>>>> screws and pre-drilled holes, you'd make a lot of mistakes building the
>>>> furniture.  Instead, these manufacturers use special connectors making
>>>> it
>>>> much more clear what goes where and making it impossible to make
>>>> certain
>>>> kinds of errors.
>>>> 
>>>> IMO, classes are those special connectors.  JS is just nails and
>>>> screws.
>>>> In JS, you can attach anything to anything and won't find out until
>>>> much
>>>> later.  In FlexJS, we can offer both better connectors and a schematic
>>>> diagram (MXML).
>>>> 
>>>> -Alex
>>>> 
>>>>> 
>>>>> On Jul 9, 2014, at 5:28 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>> 
>>>>>> I hope to attract Jquery, Angular,
>>>>>> CreateJS experts and fans to build out these frameworks and making
>>>>>> them
>>>>>> wade through the current SDK would probably be an inhibitor to them.
>>>>> 
>>>> 
>>> 
>> 
> 

Re: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

OK, I'll try to find time to read up on Angular.  It does appear that
TypeScript works with Angular.  My rudimentary understanding of this stuff
says that if you can use TS you should be able to use AS as well, but I
could certainly be wrong.

-Alex

On 7/9/14 10:43 AM, "Harbs" <ha...@gmail.com> wrote:

>FWIW, here’s some Angular-compatible components:
>http://angular-ui.github.io/
>http://angular-ui.github.io/bootstrap/
>http://angular-ui.github.io/ng-grid/
>
>and a whole site dedicated to cataloging Angular modules (some of it UI,
>and some of it business logic):
>http://ngmodules.org/
>
>As you can see, except for the basic HTML elements, any UI that is used
>with Angular is going to be external modules from either existing UI
>frameworks (i.e. Bootstrap), or ones built specifically for Angular. None
>of these are part of the core Angular framework.
>
>I do think that for FlexJS to be successful, we would need some kind of
>public catalog of external modules (components) similar to the ngmodules
>site.
>
>On Jul 9, 2014, at 8:11 PM, Harbs <ha...@gmail.com> wrote:
>
>> Angular is not really components. It’s more the glue that holds the
>>components together.
>> 
>> Basically, the selling point of Angular is how it binds javascript to
>>HTML. Building custom Angular components is the hardest part of using
>>the framework (and for the most part is not part of the framework
>>itself). They call them “directives” and they have very unintuitive json
>>markup that goes with the js code.
>> 
>> Angular pretty strongly prescribes how the app is put together and it’s
>>comprised of HTML template and directive files which comprise the view,
>>and controller/factory/service files which comprise the model and
>>controller.
>> 
>> 
>> On Jul 9, 2014, at 7:44 PM, Alex Harui <ah...@adobe.com> wrote:
>> 
>>> 
>>> 
>>> On 7/9/14 9:16 AM, "Harbs" <ha...@gmail.com> wrote:
>>> 
>>>> I wouldn¹t call myself an expert on the subject, but I have had the
>>>> opportunity to familiarize myself with both Angular and Create.js the
>>>> past half year.
>>>> 
>>>> Create.js makes sense to integrate into FlexJS. I¹m not sure I
>>>>understand
>>>> how Angular would/could be integrated. It seems to me that Angular is
>>>>a
>>>> competing framework and I don¹t understand how the two could work
>>>> together.
>>> IMO, most JS frameworks offer a set of components that you glue
>>>together
>>> with JS.  I'm not an expert on these frameworks, but I think Angular is
>>> one of them.  Assuming the JS framework is not buggy, I think there is
>>>a
>>> lot of pain in writing and debugging the JS code that glues the
>>>components
>>> together (the rest of the pain is probably in browser-specific issues).
>>> TypeScript seems to have reached the same conclusion and offers a new
>>> language to do the gluing.  I'd say Dart and GWT also have the same
>>> thoughts.
>>> 
>>> FlexJS has the potential to be on-par or better as a way to do the
>>>gluing.
>>> We have IDEs, we have runtime verification, and we have declarative
>>> markup in MXML.
>>> 
>>> Think of it this way.  If IKEA or other assemble-it-yourself furniture
>>> makers shipped you a box of pieces cut to size and then just nails and
>>> screws and pre-drilled holes, you'd make a lot of mistakes building the
>>> furniture.  Instead, these manufacturers use special connectors making
>>>it
>>> much more clear what goes where and making it impossible to make
>>>certain
>>> kinds of errors.
>>> 
>>> IMO, classes are those special connectors.  JS is just nails and
>>>screws.
>>> In JS, you can attach anything to anything and won't find out until
>>>much
>>> later.  In FlexJS, we can offer both better connectors and a schematic
>>> diagram (MXML).
>>> 
>>> -Alex
>>> 
>>>> 
>>>> On Jul 9, 2014, at 5:28 PM, Alex Harui <ah...@adobe.com> wrote:
>>>> 
>>>>> I hope to attract Jquery, Angular,
>>>>> CreateJS experts and fans to build out these frameworks and making
>>>>>them
>>>>> wade through the current SDK would probably be an inhibitor to them.
>>>> 
>>> 
>> 
>

Re: New Flex to JS project

[Harbs <ha...@gmail.com>]

FWIW, here’s some Angular-compatible components:
http://angular-ui.github.io/
http://angular-ui.github.io/bootstrap/
http://angular-ui.github.io/ng-grid/

and a whole site dedicated to cataloging Angular modules (some of it UI, and some of it business logic):
http://ngmodules.org/

As you can see, except for the basic HTML elements, any UI that is used with Angular is going to be external modules from either existing UI frameworks (i.e. Bootstrap), or ones built specifically for Angular. None of these are part of the core Angular framework.

I do think that for FlexJS to be successful, we would need some kind of public catalog of external modules (components) similar to the ngmodules site.

On Jul 9, 2014, at 8:11 PM, Harbs <ha...@gmail.com> wrote:

> Angular is not really components. It’s more the glue that holds the components together.
> 
> Basically, the selling point of Angular is how it binds javascript to HTML. Building custom Angular components is the hardest part of using the framework (and for the most part is not part of the framework itself). They call them “directives” and they have very unintuitive json markup that goes with the js code.
> 
> Angular pretty strongly prescribes how the app is put together and it’s comprised of HTML template and directive files which comprise the view, and controller/factory/service files which comprise the model and controller.
> 
> 
> On Jul 9, 2014, at 7:44 PM, Alex Harui <ah...@adobe.com> wrote:
> 
>> 
>> 
>> On 7/9/14 9:16 AM, "Harbs" <ha...@gmail.com> wrote:
>> 
>>> I wouldn¹t call myself an expert on the subject, but I have had the
>>> opportunity to familiarize myself with both Angular and Create.js the
>>> past half year.
>>> 
>>> Create.js makes sense to integrate into FlexJS. I¹m not sure I understand
>>> how Angular would/could be integrated. It seems to me that Angular is a
>>> competing framework and I don¹t understand how the two could work
>>> together.
>> IMO, most JS frameworks offer a set of components that you glue together
>> with JS.  I'm not an expert on these frameworks, but I think Angular is
>> one of them.  Assuming the JS framework is not buggy, I think there is a
>> lot of pain in writing and debugging the JS code that glues the components
>> together (the rest of the pain is probably in browser-specific issues).
>> TypeScript seems to have reached the same conclusion and offers a new
>> language to do the gluing.  I'd say Dart and GWT also have the same
>> thoughts.
>> 
>> FlexJS has the potential to be on-par or better as a way to do the gluing.
>> We have IDEs, we have runtime verification, and we have declarative
>> markup in MXML.
>> 
>> Think of it this way.  If IKEA or other assemble-it-yourself furniture
>> makers shipped you a box of pieces cut to size and then just nails and
>> screws and pre-drilled holes, you'd make a lot of mistakes building the
>> furniture.  Instead, these manufacturers use special connectors making it
>> much more clear what goes where and making it impossible to make certain
>> kinds of errors.
>> 
>> IMO, classes are those special connectors.  JS is just nails and screws.
>> In JS, you can attach anything to anything and won't find out until much
>> later.  In FlexJS, we can offer both better connectors and a schematic
>> diagram (MXML).
>> 
>> -Alex
>> 
>>> 
>>> On Jul 9, 2014, at 5:28 PM, Alex Harui <ah...@adobe.com> wrote:
>>> 
>>>> I hope to attract Jquery, Angular,
>>>> CreateJS experts and fans to build out these frameworks and making them
>>>> wade through the current SDK would probably be an inhibitor to them.
>>> 
>> 
> 

Re: New Flex to JS project

[Harbs <ha...@gmail.com>]

Angular is not really components. It’s more the glue that holds the components together.

Basically, the selling point of Angular is how it binds javascript to HTML. Building custom Angular components is the hardest part of using the framework (and for the most part is not part of the framework itself). They call them “directives” and they have very unintuitive json markup that goes with the js code.

Angular pretty strongly prescribes how the app is put together and it’s comprised of HTML template and directive files which comprise the view, and controller/factory/service files which comprise the model and controller.


On Jul 9, 2014, at 7:44 PM, Alex Harui <ah...@adobe.com> wrote:

> 
> 
> On 7/9/14 9:16 AM, "Harbs" <ha...@gmail.com> wrote:
> 
>> I wouldn¹t call myself an expert on the subject, but I have had the
>> opportunity to familiarize myself with both Angular and Create.js the
>> past half year.
>> 
>> Create.js makes sense to integrate into FlexJS. I¹m not sure I understand
>> how Angular would/could be integrated. It seems to me that Angular is a
>> competing framework and I don¹t understand how the two could work
>> together.
> IMO, most JS frameworks offer a set of components that you glue together
> with JS.  I'm not an expert on these frameworks, but I think Angular is
> one of them.  Assuming the JS framework is not buggy, I think there is a
> lot of pain in writing and debugging the JS code that glues the components
> together (the rest of the pain is probably in browser-specific issues).
> TypeScript seems to have reached the same conclusion and offers a new
> language to do the gluing.  I'd say Dart and GWT also have the same
> thoughts.
> 
> FlexJS has the potential to be on-par or better as a way to do the gluing.
> We have IDEs, we have runtime verification, and we have declarative
> markup in MXML.
> 
> Think of it this way.  If IKEA or other assemble-it-yourself furniture
> makers shipped you a box of pieces cut to size and then just nails and
> screws and pre-drilled holes, you'd make a lot of mistakes building the
> furniture.  Instead, these manufacturers use special connectors making it
> much more clear what goes where and making it impossible to make certain
> kinds of errors.
> 
> IMO, classes are those special connectors.  JS is just nails and screws.
> In JS, you can attach anything to anything and won't find out until much
> later.  In FlexJS, we can offer both better connectors and a schematic
> diagram (MXML).
> 
> -Alex
> 
>> 
>> On Jul 9, 2014, at 5:28 PM, Alex Harui <ah...@adobe.com> wrote:
>> 
>>> I hope to attract Jquery, Angular,
>>> CreateJS experts and fans to build out these frameworks and making them
>>> wade through the current SDK would probably be an inhibitor to them.
>> 
> 

Re: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

On 7/9/14 9:16 AM, "Harbs" <ha...@gmail.com> wrote:

>I wouldn¹t call myself an expert on the subject, but I have had the
>opportunity to familiarize myself with both Angular and Create.js the
>past half year.
>
>Create.js makes sense to integrate into FlexJS. I¹m not sure I understand
>how Angular would/could be integrated. It seems to me that Angular is a
>competing framework and I don¹t understand how the two could work
>together.
IMO, most JS frameworks offer a set of components that you glue together
with JS.  I'm not an expert on these frameworks, but I think Angular is
one of them.  Assuming the JS framework is not buggy, I think there is a
lot of pain in writing and debugging the JS code that glues the components
together (the rest of the pain is probably in browser-specific issues).
TypeScript seems to have reached the same conclusion and offers a new
language to do the gluing.  I'd say Dart and GWT also have the same
thoughts.

FlexJS has the potential to be on-par or better as a way to do the gluing.
 We have IDEs, we have runtime verification, and we have declarative
markup in MXML.

Think of it this way.  If IKEA or other assemble-it-yourself furniture
makers shipped you a box of pieces cut to size and then just nails and
screws and pre-drilled holes, you'd make a lot of mistakes building the
furniture.  Instead, these manufacturers use special connectors making it
much more clear what goes where and making it impossible to make certain
kinds of errors.

IMO, classes are those special connectors.  JS is just nails and screws.
In JS, you can attach anything to anything and won't find out until much
later.  In FlexJS, we can offer both better connectors and a schematic
diagram (MXML).

-Alex

>
>On Jul 9, 2014, at 5:28 PM, Alex Harui <ah...@adobe.com> wrote:
>
>>  I hope to attract Jquery, Angular,
>> CreateJS experts and fans to build out these frameworks and making them
>> wade through the current SDK would probably be an inhibitor to them.
>

Re: New Flex to JS project

[Harbs <ha...@gmail.com>]

I wouldn’t call myself an expert on the subject, but I have had the opportunity to familiarize myself with both Angular and Create.js the past half year.

Create.js makes sense to integrate into FlexJS. I’m not sure I understand how Angular would/could be integrated. It seems to me that Angular is a competing framework and I don’t understand how the two could work together.

On Jul 9, 2014, at 5:28 PM, Alex Harui <ah...@adobe.com> wrote:

>  I hope to attract Jquery, Angular,
> CreateJS experts and fans to build out these frameworks and making them
> wade through the current SDK would probably be an inhibitor to them.

Re: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

On 7/9/14 2:04 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:

>Alex,
>
>Wow! Awesome email, if nothing else then only by weight of the bytes ;-)
I'll try to make this one shorter.
>
>I'm not sure you entirely get what I'm trying to do, but keeping an open
>mind I'm looking for ways to combine the two approaches. You seem to be
>suggesting that VF2JS can exist as an option in FlexJS. We need to explore
>that idea to see if we might be able to make it work.
>
>1) Currently, FlexJS has it's own AS framework, without any of the
>Spark/MX
>components. VF2JS needs those; remember, VF2JS let's users develop their
>SWF apps in the classic SDK, like they are used to. Do you suggest we
>merge
>FlexJS into the current SDK?
Again, FlexJS hopes to support multiple AS frameworks.  Eventually we'll
carve the Jquery, Cordova, and CreateJS stuff out of the current "basic"
SWC and JS folders into their own SWCs and JS folders.  There will be
separate SWCs and JS folders for Angular and whatever JS frameworks folks
want to wrap.  The compiler/namespace stuff should support this already,
just like folks can use non-Flex SWCs in AS-only projects.  I don't think
we need to merge these SWC/folder sets into the main SDK as they don't
have any reliance on the SDK code and will simplify development and
releasing by maintaining separation.  But VJS can be packaged in whatever
way makes sense.  FlexJS installs already pull in MXMLC jars from the
current SDK, the VJS SWCs can certainly rely on current Flex SDK SWCs.
All of the FlexJS SWCs rely on playerglobal.swc.  All that should matter
is what SWCs are listed in the config at compile time.

>
>2) The FlexJS JS implementation uses data arrays to represent MXML. This
>means that class member names are stored as strings. The GCC can't rename
>strings. In order to match the strings to the actual properties, the
>properties cannot be renamed either - you can't match 'myComponent.width'
>to 'a.b' ;-) This is why all public properties have the @expose
>annotation.
>But here is the kicker: using @expose prevents the GCC from doing a
>significant amount of optimisations. In VF2JS I'm planning on doing away
>with the data arrays so we get to use the full force of GCC optimisation
>and minification, and can do away with the client side dynamic object
>creation from the array.
The data array output is just a flag in Falcon
(compiler.mxml.children-as-data).  If you want it to be off for VJS
compiles that's fine.  There's probably some tweaks needed when you turn
that off.  One of the reasons I set up MXML as data is that several folks
have asked to be able to modify the MXML output and the data array was the
only way I could think of to do that without sacrificing performance.  I'm
open to other options.  Folks may ask that of VJS MXML compilation as well.

>
>3) I'm liking the idea of having FalconJX detect the namespaces it is fed
>and use that information to decide the compile path. That way if it reads
>Spark/MX, it would use the VF2JS JS framework, if it reads Basic/Core, if
>would go the FlexJS route.
I was thinking it might be not too hard to add
-namespace-override=<oldURI>$<newURI>.  I still want to do it in Falcon so
you find out early instead of at cross-compile time.  I think we probably
need a package/import override too for AS code.

>
>4) The organisation of the JS frameworks would need some rethinking.
>FlexJS
>also uses the 'flash.display' and 'mx.core'/'mx.states' namespaces. We
>don't want collisions there.
Oh yes.  A good name scrub and folder re-org is definitely needed.  I'm
not good at it and hope someone who is will step up.

>
>5) The reason I'm hiding the AS SWC because I don't want to bother the
>user
>with having to use different xmlns. It would be sweet though to have
>Falcon
>do the switching on the fly, so we get compiler feedback about portability
>during development, e.g. using a compiler argument indicating you want to
>also be able to cross compile your code to JS. That way the shim SWCs
>could
>still be that, shims, but I like the idea of adding metadata to indicate
>JS
>(un)availability.
Yeah, either metadata and/or some other data file to inform the compiler.
We probably can't modify playerglobal.swc so we might need an external
file for that.  Or we could shim playerglobal...
 
>
>6) We need to rethink the naming convention. I like FlexJS, it should stay
>for the name of the AS to JS project. But the various frameworks need
>different names. On the AS side, after we 'merge', I guess there are 4:
>Flex (the regular SDK, used by the VF2JS approach), FlexJSUI, FlexJS and
>MXMLCClasses. On the JS side, there would be lots and lots, some of them
>(possibly) colliding: see point 4). What is your view on the organisation
>of these various aspects, especially given that (see point 1) we might
>merge FlexJS into the regular SDK?
Definitely open to ideas on renaming and reorganizing.  IMO, the SWCs and
JS folders that don't have a reliance on the current SDK should probably
not be merged into the current SDK.  I hope to attract Jquery, Angular,
CreateJS experts and fans to build out these frameworks and making them
wade through the current SDK would probably be an inhibitor to them.

I'm not sure what advantages you get from merging VJS into the main SDK.
Seems like it would make the packaging of current SDK more complex and tie
you to successful releases of the current SDK and vice versa.  Wouldn't
you be more nimble just referencing the current SDK SWCs and releasing as
a separate package?  At least in the early going?  IMO, I think were
better off keeping Falcon separate from the current SDK as well, at least
for now.

Hmm, well that was shorter than the last post, I think...
-Alex

Re: New Flex to JS project

[Erik de Bruin <er...@ixsoftware.nl>]

Alex,

Wow! Awesome email, if nothing else then only by weight of the bytes ;-)

I'm not sure you entirely get what I'm trying to do, but keeping an open
mind I'm looking for ways to combine the two approaches. You seem to be
suggesting that VF2JS can exist as an option in FlexJS. We need to explore
that idea to see if we might be able to make it work.

1) Currently, FlexJS has it's own AS framework, without any of the Spark/MX
components. VF2JS needs those; remember, VF2JS let's users develop their
SWF apps in the classic SDK, like they are used to. Do you suggest we merge
FlexJS into the current SDK?

2) The FlexJS JS implementation uses data arrays to represent MXML. This
means that class member names are stored as strings. The GCC can't rename
strings. In order to match the strings to the actual properties, the
properties cannot be renamed either - you can't match 'myComponent.width'
to 'a.b' ;-) This is why all public properties have the @expose annotation.
But here is the kicker: using @expose prevents the GCC from doing a
significant amount of optimisations. In VF2JS I'm planning on doing away
with the data arrays so we get to use the full force of GCC optimisation
and minification, and can do away with the client side dynamic object
creation from the array.

3) I'm liking the idea of having FalconJX detect the namespaces it is fed
and use that information to decide the compile path. That way if it reads
Spark/MX, it would use the VF2JS JS framework, if it reads Basic/Core, if
would go the FlexJS route.

4) The organisation of the JS frameworks would need some rethinking. FlexJS
also uses the 'flash.display' and 'mx.core'/'mx.states' namespaces. We
don't want collisions there.

5) The reason I'm hiding the AS SWC because I don't want to bother the user
with having to use different xmlns. It would be sweet though to have Falcon
do the switching on the fly, so we get compiler feedback about portability
during development, e.g. using a compiler argument indicating you want to
also be able to cross compile your code to JS. That way the shim SWCs could
still be that, shims, but I like the idea of adding metadata to indicate JS
(un)availability.

6) We need to rethink the naming convention. I like FlexJS, it should stay
for the name of the AS to JS project. But the various frameworks need
different names. On the AS side, after we 'merge', I guess there are 4:
Flex (the regular SDK, used by the VF2JS approach), FlexJSUI, FlexJS and
MXMLCClasses. On the JS side, there would be lots and lots, some of them
(possibly) colliding: see point 4). What is your view on the organisation
of these various aspects, especially given that (see point 1) we might
merge FlexJS into the regular SDK?

That should be enough food for thought ;-) Let's see if we can make this
work!

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

Re: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

Hi Erik,

Thanks for the list.  I think this is a valuable discussion.  I'm going to
respond out of order: hopefully the easiest answers first.  Then at the
end is more of my continually evolving thoughts on FlexJS that may be hard
to capture from the slides.

First, keep in mind that one of the FlexJS goals is to support multiple
component sets.  Unlike current Flex's Spark or MX, the "basic" components
isn't intended to be a one-size-fits-all component set.  There are already
the beginnings of component sets for JQUery and CreateJS and Cordova.

Anyway, regarding #4 (MVC).  I originally thought that there would be some
advantage when cross-compiling to having folks separate business and
controller logic from view.  However, folks have complained about it, and
I haven't really seen any advantages so far so in FlexJS 0.0.3 or 0.0.4
I'll probably remove the MVC requirement.  Having the option of creating
single-file apps is much more friendly.

#5 (lack of direction).  I call that "exploring", but yeah, I don't have a
crystal ball to know where we need to end up.  We are changing as we
discover things and our users provide feedback.  I think that's a good
strategy and fits with the Apache Way.

#1 (Migration Path).  There is a migration path.  I think it is very
similar to what you envision for your approach.  You simply switch from a
current Flex SDK to a FlexJS SDK.  You choose between replacing all mx and
spark prefixes or replacing just the URI in the xmlns.  Could we add an
option to Falcon to override xmlns URIs?  Sure, if that's what folks want.

#2 (writing both AS and JS code).  Actually, it is turning out that we are
not writing both AS and JS as much as I thought we would.  The FlexJSJX
SWC and components like DataGrid and BarChart don't have any JS
equivalents in the repo.  The AS in that SWC is cross-compiled.  It is
looking like lots of components are "higher-level" and can be composed of
widgets from the FlexJSUI SWC.  But yes, we are writing enough AS so the
SWF version is operational.  This should provide several developer
benefits: runtime verification of your code for highly dynamic
applications, reduced testing if you can deploy SWFs on most browsers, a
way to support older browsers.

#3 (beads).  There is no requirement that the application developers have
to deal with a ton of beads.  Only component developers that want to make
general-purpose components may want to take advantage of beads.  The
"basic" components Peter and I (and hopefully others someday) are working
on are trying to leverage beads in order to make sure there is clean
separation of concerns in the framework code (vs 13,000 line base classes)
so that some of these pieces can be re-used for other component sets.
Then we're testing the waters to see whether application developers like
beads or not.  If not, we can always "bake-in" beads into higher-level
components.  But at least we'll know that if someone is desperately trying
to shave off code it is possible.

And from your other post about GCC optimization:  Maybe download size
doesn't matter and maybe GCC is so good you can add more code without any
performance and size implications, but that sort of defies logic to me.
It has been my experience that frameworks grow over time as you add
features and fix bugs.  And it has been my experience that folks will give
up on frameworks for size and performance.  That's why a significant
number of mobile AIR apps do not use Flex and are written in bare-bones
AS.  I want Apache Flex to have a next-generation framework composed of
pieces so fewer folks have to bail out.  As we add more features to
FlexJS, I hope the examples don't grow in size.  IMO, they will for your
VJS implementation because eventually, the VJS Button needs to wire in the
code for tooltips even on mobile apps that will never use them.  Or a
heavy ResourceManager implementation for apps that only need to localize
strings.  There are 120+ public APIs on Spark Button most apps only use a
small fraction.

Another thing about FlexJS that has evolved over time is that I am
thinking that the key advantage of FlexJS is simply in being the best way
to glue JS together into an application.  The "basic" components will be
useful to many, but some folks have requirements to use certain JS
frameworks.  With the SWF version checking your code at runtime, with MXML
giving you a schematic diagram, I hope to see component sets for Angular
and other JS frameworks as well as the filling out of the Jquery and
CreateJS sets, and possible different back-ends outputting to TypeScript
and/or Dart.  The beads create highly re-usable pieces for folks to build
out these component sets and the result has little overhead compared to a
manual port to that same JS framework.  I believe we will always be
compared to how fast and small a true JS application will be.

So, the way I see it based on my understanding of the VJS approach you
want to take is that you are just building another component set.  You
don't have to use beads although I hope you do find some sort of modular
approach otherwise your UIComponent.js will be 13,000 lines of JS.  My
hope was that you would build your JS Spark and MX equivalents by
compositing beads and helping create new beads that we can use in other
component sets.

Right now you want to hide your AS SWCs and switch to them under the
covers, but I was thinking you could just make them public SWCs that are
wrappers of the existing MX and Spark SWCs with some sort of metadata that
works like the [Deprecated] metadata tag.  I want to teach Falcon to warn
folks about e4x usage and other things so we both want some sort of
warning/errors for certain APIs.  But I'm hoping to move the warning phase
to the AS compile phase instead of waiting until you attempt to
cross-compile.

So, that's why I see way more similarities than differences.  I'm glad you
like the current SDK, but I think it has gotten too old, fat, and slow, so
I am embarking on a next-generation.  I say in one of my slides "if you
have 10,000 lines of MXML and 100,000 lines of AS, without FlexJS you
would have to port all of it, with FlexJS you will have to port less."  It
would be awesome to have some sort of component set where you have to port
even less.  I'm not clear you can get to zero porting because of things
like weak references or if you do implement weak references, if there will
be some cost to it that people will notice when comparing against a true
JS app.  But then folks can compare and choose. I think the basic
components will result in smaller faster apps than one that has to support
all of the ugly interdependencies in the current SDK.  But if I'm wrong,
that's ok.  We will still have built lots of re-usable pieces to be used
in the component sets for Jquery, Angular, etc.

I don't know how folks will feel about making API changes to the current
SDK to support cross-compilation.  By making a wrapper component set, I
think you won't need to make any changes.  Folks just switch to your VJS
component set and off they go.

In summary, FlexJS totally supports a component set that is tries to
emulate Spark and MX.  It just isn't the component set I'm focused on.  If
we can find common ground on how to warn folks about missing APIs and move
the warnings to the Falcon compiler, then I think we will truly be on the
same team, just working on different component sets.

-Alex

On 7/8/14 1:29 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:

>OK, here goes - why I think the FlexJS concept can be improved upon (in no
>particular order):
>
>1 - there is no migration path for existing Flex applications; this will
>make enterprise users reluctant to accept the new framework, even though
>during development FlexJS is limiting itself because it aims to please the
>enterprise user (IE 'old' support)
>2 - FlexJS requires a brand new framework on both the AS and JS side
>(apart
>from some stuff that may cross compile), effectively doubling the effort
>to
>bring it up to speed with other frameworks - including regular Flex
>3 - Strands/Beads: it forces developers to know the insides of components,
>adding a level of complexity and a steeper learning curve to the framework
>    I - by the time there are enough components/strands and beads to have
>a
>useful framework, the set of beads will be too big to easily work with
>(e.g. "org.apache.flex.html.beads.DataItemRendererFactoryForArrayData" or
>"org.apache.flex.html.beads.controllers.ListSingleSelectionMouseController
>")
>    II - making beads work on all strands makes beads complicated; making
>beads that don't work on all strands makes beads confusing for the
>developer
>4 - forced MVC: as an option it would be great, as a 'feature' not so
>much:
>it makes smaller projects unnecessarily complicated (e.g. all examples)
>5 - lack of direction: FlexJS is a collection of proofs of concept,
>created
>top down to make nice looking demos that are then abandoned or superseded
>by other proofs of concept or demos.
>
>I think we already have a pretty nice AS framework, the Flex SDK, which I
>intend to offer as-is. Rather, I plan to make the 'export to JS' feature a
>part of the regular Flex SDK. That way the user can open any Flex project,
>run the export and get a fully functional, identical looking application
>in
>JS, or, worst case, a nice list from the compiler explaining which
>components/properties don't (yet) work in JS and how to fix that.
>
>I'm interested to hear more about how you think this approach is related
>to
>FlexJS. If there is any synergy to be had, I'm all for it!
>
>EdB
>
>
>
>On Mon, Jul 7, 2014 at 6:27 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> I'm not sure what you mean by "philosophical".  I see more similarities
>> than differences between FlexJS and your approach of trying to mimic
>>more
>> of the current SDK in JS.  In fact, I still hope to convince you that
>>what
>> you want to do is within the FlexJS charter so we can work together
>> instead appearing to work on separate efforts.  And then what you are
>> working on would also be weakened by whatever it is you want to say.  If
>> you have a killer argument why folks should not be trying to compile
>>MXML
>> and AS to JS, I think the whole community will be better served by
>>finding
>> out why now.
>>
>> -Alex
>>
>> On 7/7/14 8:40 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>
>> >There are no technical issues per se that would need addressing to keep
>> >FlexJS healthy. I made sure of that.
>> >
>> >My argument is basically philosophical, and I think my ranting about
>>it in
>> >public would weaken FlexJS' case, so I won't.
>> >
>> >EdB
>> >
>> >
>> >
>> >On Thu, Jul 3, 2014 at 4:47 PM, Alex Harui <ah...@adobe.com> wrote:
>> >
>> >> I think it has to be in public.  This is open development.  I'm
>>hoping
>> >>you
>> >> will save me time by doing so.  If we are doing something we
>>shouldn't
>> >>we
>> >> should correct it now otherwise we'll waste time and energy doing
>>more
>> >> work in that direction only to find out that customers have the same
>> >> feedback.
>> >>
>> >> Not that all of your feedback is guaranteed to be addressed: there's
>> >> always a chance that what you don't like is philosophical rather than
>> >> technical.  That's why there are dozens of JS frameworks already and
>>why
>> >> you want to try a different approach.
>> >>
>> >> -Alex
>> >>
>> >> On 7/3/14 12:00 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>> >>
>> >> >You want to hear that in public, or do you want to take this off
>>list?
>> >> >
>> >> >EdB
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >On Thu, Jul 3, 2014 at 7:53 AM, Alex Harui <ah...@adobe.com> wrote:
>> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> >I've been doing that as well for the last couple of years. I
>>spent
>> >> >>most of
>> >> >> >my time getting FlexJS off the ground. But I don't agree with
>>some
>> >>of
>> >> >>the
>> >> >> >basic assumptions and choices that FlexJS has made. I said
>>little or
>> >> >> >nothing about it to give FlexJS a proper head start and to keep
>>you
>> >>and
>> >> >> >Peter going. But now that I have re-evaluated what the project
>> >>means to
>> >> >> >me,
>> >> >> >and what I would like to spend my time on when contributing, and
>>I
>> >> >>have to
>> >> >> >give my take on Flex to JS a try.
>> >> >> I'd love to hear your thoughts on what you don't agree with
>>regarding
>> >> >> FlexJS.
>> >> >>
>> >> >> -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: New Flex to JS project

[Erik de Bruin <er...@ixsoftware.nl>]

Also, between the Closure Compiler's effectiveness in optimising and
minifying code and the current state of internet speed available to users,
I think that 'application size' is not a major reason to make drastic
decisions when architecting a framework. The release version of
DatabindingTest is currently 70 kb, which basically means that is about a
10th the size of an average Facebook post. I mean, even if my approach
would double the size - doubtful given GCCs effectiveness - it would still
be something which you can download as easily as a single image from any
website.

EdB




On Tue, Jul 8, 2014 at 1:03 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:

> Peter,
>
> To be sure, I'm not criticising the work done on FlexJS - I did a fair bit
> of it myself - I'm just (after Alex's insistence) stating the reasons I've
> chosen to approach 'export to JS' from a different angle.
>
> EdB
>
>
>
>
> On Tue, Jul 8, 2014 at 12:57 PM, Peter Ent <pe...@adobe.com> wrote:
>
>> I'm sure Alex is composing a longer response, but I wanted to chime in
>> having developed a number of beads and components of FlexJS.
>>
>> FlexJS is designed to be a pay-as-go system, keeping the app size as
>> small as possible; even a small Flex app brings in a lot of code.
>>
>> I have to agree that beads should be more generic and easier to connect.
>> The reason for many beads is so you can add on just the functionality you
>> need. Perhaps having a reduced number of beads that are more generic would
>> make it easier to choose. Then, if you found yourself using the same
>> combination repeatedly, you would make this a custom component in your app.
>>
>> And yes, the examples only go so far and new things have appeared. This
>> is at alpha stage so there will be iterations. We needed to get sufficient
>> components together so we could survey how it all hangs together.
>>
>> We are hoping more people will join the project and help with the
>> direction and development.
>>
>> I think the core idea is sound and could use some tweaking.
>>
>> Peter
>>
>>
>> > On Jul 8, 2014, at 6:11 AM, "DarkStone" <da...@163.com> wrote:
>> >
>> > Hi Erik,
>> >
>> > Thank you very much for bringing this topic, it's the very topic I want
>> to share my thoughts on.
>> >
>> >> 3 - Strands/Beads: it forces developers to know the insides of
>> components,
>> >> adding a level of complexity and a steeper learning curve to the
>> framework
>> >> 4 - forced MVC: as an option it would be great, as a 'feature' not so
>> much:
>> >> it makes smaller projects unnecessarily complicated (e.g. all examples)
>> >
>> > I totally agree all the 5 points you've made, especially the 2 points
>> above, I studied FlexJS' Strands/Beads MVC concept before, it forced me to
>> do a restricted MVC application design.
>> >
>> > In most case, developers should have the abilities to design their own
>> MVC concepts, rather than having to follow a pre-designed MVC concept. That
>> is why Flex named itself "Flex", the flexibility is the soul of Flex, isn't
>> it : )
>> >
>> > I think Flex Spark's SkinnableComponent and Skin are good enough to
>> separate a component's Logic and Skin. The Logic part of the component can
>> then be divided into Model and Controller in anyway the developer want them
>> to be, that is already the case in Flex Spark architecture, developers can
>> decide how to design their own MVC concepts and apply them to their custom
>> components, it's better this way.
>> >
>> > Besides, there are already a huge amount of projects based on the
>> existing Flex Spark architecture, it will be much better if FlexJS can base
>> on the Spark architecture, and makes the existing Flex projects much easier
>> to transit to FlexJS.
>> >
>> > It took a very long time (over 10 years) to have Flex come this way, to
>> make the Flex Spark architecture popular is already hard enough, so for the
>> FlexJS, a smoother and easier transition from Flex to FlexJS is much needed!
>> >
>> > Well that is just my personal opinion, I know there are already a lot
>> of hard works were put into the current FlexJS, and I am much appreciated,
>> I will contribute what I can, when I can in the future, these months I'm
>> gonna be very busy though.
>> >
>> >
>> > DarkStone
>> > 2014-07-08
>> >
>> >
>> >
>> > At 2014-07-08 04:29:40, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>> >> OK, here goes - why I think the FlexJS concept can be improved upon
>> (in no
>> >> particular order):
>> >>
>> >> 1 - there is no migration path for existing Flex applications; this
>> will
>> >> make enterprise users reluctant to accept the new framework, even
>> though
>> >> during development FlexJS is limiting itself because it aims to please
>> the
>> >> enterprise user (IE 'old' support)
>> >> 2 - FlexJS requires a brand new framework on both the AS and JS side
>> (apart
>> >> from some stuff that may cross compile), effectively doubling the
>> effort to
>> >> bring it up to speed with other frameworks - including regular Flex
>> >> 3 - Strands/Beads: it forces developers to know the insides of
>> components,
>> >> adding a level of complexity and a steeper learning curve to the
>> framework
>> >>   I - by the time there are enough components/strands and beads to
>> have a
>> >> useful framework, the set of beads will be too big to easily work with
>> >> (e.g. "org.apache.flex.html.beads.DataItemRendererFactoryForArrayData"
>> or
>> >>
>> "org.apache.flex.html.beads.controllers.ListSingleSelectionMouseController")
>> >>   II - making beads work on all strands makes beads complicated; making
>> >> beads that don't work on all strands makes beads confusing for the
>> developer
>> >> 4 - forced MVC: as an option it would be great, as a 'feature' not so
>> much:
>> >> it makes smaller projects unnecessarily complicated (e.g. all examples)
>> >> 5 - lack of direction: FlexJS is a collection of proofs of concept,
>> created
>> >> top down to make nice looking demos that are then abandoned or
>> superseded
>> >> by other proofs of concept or demos.
>> >>
>> >> I think we already have a pretty nice AS framework, the Flex SDK,
>> which I
>> >> intend to offer as-is. Rather, I plan to make the 'export to JS'
>> feature a
>> >> part of the regular Flex SDK. That way the user can open any Flex
>> project,
>> >> run the export and get a fully functional, identical looking
>> application in
>> >> JS, or, worst case, a nice list from the compiler explaining which
>> >> components/properties don't (yet) work in JS and how to fix that.
>> >>
>> >> I'm interested to hear more about how you think this approach is
>> related to
>> >> FlexJS. If there is any synergy to be had, I'm all for it!
>> >>
>> >> EdB
>> >>
>> >>
>> >>
>> >>> On Mon, Jul 7, 2014 at 6:27 PM, Alex Harui <ah...@adobe.com> wrote:
>> >>>
>> >>> I'm not sure what you mean by "philosophical".  I see more
>> similarities
>> >>> than differences between FlexJS and your approach of trying to mimic
>> more
>> >>> of the current SDK in JS.  In fact, I still hope to convince you that
>> what
>> >>> you want to do is within the FlexJS charter so we can work together
>> >>> instead appearing to work on separate efforts.  And then what you are
>> >>> working on would also be weakened by whatever it is you want to say.
>>  If
>> >>> you have a killer argument why folks should not be trying to compile
>> MXML
>> >>> and AS to JS, I think the whole community will be better served by
>> finding
>> >>> out why now.
>> >>>
>> >>> -Alex
>> >>>
>> >>>> On 7/7/14 8:40 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>> >>>>
>> >>>> There are no technical issues per se that would need addressing to
>> keep
>> >>>> FlexJS healthy. I made sure of that.
>> >>>>
>> >>>> My argument is basically philosophical, and I think my ranting about
>> it in
>> >>>> public would weaken FlexJS' case, so I won't.
>> >>>>
>> >>>> EdB
>> >>>>
>> >>>>
>> >>>>
>> >>>>> On Thu, Jul 3, 2014 at 4:47 PM, Alex Harui <ah...@adobe.com>
>> wrote:
>> >>>>>
>> >>>>> I think it has to be in public.  This is open development.  I'm
>> hoping
>> >>>>> you
>> >>>>> will save me time by doing so.  If we are doing something we
>> shouldn't
>> >>>>> we
>> >>>>> should correct it now otherwise we'll waste time and energy doing
>> more
>> >>>>> work in that direction only to find out that customers have the same
>> >>>>> feedback.
>> >>>>>
>> >>>>> Not that all of your feedback is guaranteed to be addressed: there's
>> >>>>> always a chance that what you don't like is philosophical rather
>> than
>> >>>>> technical.  That's why there are dozens of JS frameworks already
>> and why
>> >>>>> you want to try a different approach.
>> >>>>>
>> >>>>> -Alex
>> >>>>>
>> >>>>>> On 7/3/14 12:00 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>> >>>>>>
>> >>>>>> You want to hear that in public, or do you want to take this off
>> list?
>> >>>>>>
>> >>>>>> EdB
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> On Thu, Jul 3, 2014 at 7:53 AM, Alex Harui <ah...@adobe.com>
>> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> I've been doing that as well for the last couple of years. I
>> spent
>> >>>>>>> most of
>> >>>>>>>> my time getting FlexJS off the ground. But I don't agree with
>> some
>> >>>>> of
>> >>>>>>> the
>> >>>>>>>> basic assumptions and choices that FlexJS has made. I said
>> little or
>> >>>>>>>> nothing about it to give FlexJS a proper head start and to keep
>> you
>> >>>>> and
>> >>>>>>>> Peter going. But now that I have re-evaluated what the project
>> >>>>> means to
>> >>>>>>>> me,
>> >>>>>>>> and what I would like to spend my time on when contributing, and
>> I
>> >>>>>>> have to
>> >>>>>>>> give my take on Flex to JS a try.
>> >>>>>>> I'd love to hear your thoughts on what you don't agree with
>> regarding
>> >>>>>>> FlexJS.
>> >>>>>>>
>> >>>>>>> -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
>>
>
>
>
> --
> 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: New Flex to JS project

[Erik de Bruin <er...@ixsoftware.nl>]

Peter,

To be sure, I'm not criticising the work done on FlexJS - I did a fair bit
of it myself - I'm just (after Alex's insistence) stating the reasons I've
chosen to approach 'export to JS' from a different angle.

EdB




On Tue, Jul 8, 2014 at 12:57 PM, Peter Ent <pe...@adobe.com> wrote:

> I'm sure Alex is composing a longer response, but I wanted to chime in
> having developed a number of beads and components of FlexJS.
>
> FlexJS is designed to be a pay-as-go system, keeping the app size as small
> as possible; even a small Flex app brings in a lot of code.
>
> I have to agree that beads should be more generic and easier to connect.
> The reason for many beads is so you can add on just the functionality you
> need. Perhaps having a reduced number of beads that are more generic would
> make it easier to choose. Then, if you found yourself using the same
> combination repeatedly, you would make this a custom component in your app.
>
> And yes, the examples only go so far and new things have appeared. This is
> at alpha stage so there will be iterations. We needed to get sufficient
> components together so we could survey how it all hangs together.
>
> We are hoping more people will join the project and help with the
> direction and development.
>
> I think the core idea is sound and could use some tweaking.
>
> Peter
>
>
> > On Jul 8, 2014, at 6:11 AM, "DarkStone" <da...@163.com> wrote:
> >
> > Hi Erik,
> >
> > Thank you very much for bringing this topic, it's the very topic I want
> to share my thoughts on.
> >
> >> 3 - Strands/Beads: it forces developers to know the insides of
> components,
> >> adding a level of complexity and a steeper learning curve to the
> framework
> >> 4 - forced MVC: as an option it would be great, as a 'feature' not so
> much:
> >> it makes smaller projects unnecessarily complicated (e.g. all examples)
> >
> > I totally agree all the 5 points you've made, especially the 2 points
> above, I studied FlexJS' Strands/Beads MVC concept before, it forced me to
> do a restricted MVC application design.
> >
> > In most case, developers should have the abilities to design their own
> MVC concepts, rather than having to follow a pre-designed MVC concept. That
> is why Flex named itself "Flex", the flexibility is the soul of Flex, isn't
> it : )
> >
> > I think Flex Spark's SkinnableComponent and Skin are good enough to
> separate a component's Logic and Skin. The Logic part of the component can
> then be divided into Model and Controller in anyway the developer want them
> to be, that is already the case in Flex Spark architecture, developers can
> decide how to design their own MVC concepts and apply them to their custom
> components, it's better this way.
> >
> > Besides, there are already a huge amount of projects based on the
> existing Flex Spark architecture, it will be much better if FlexJS can base
> on the Spark architecture, and makes the existing Flex projects much easier
> to transit to FlexJS.
> >
> > It took a very long time (over 10 years) to have Flex come this way, to
> make the Flex Spark architecture popular is already hard enough, so for the
> FlexJS, a smoother and easier transition from Flex to FlexJS is much needed!
> >
> > Well that is just my personal opinion, I know there are already a lot of
> hard works were put into the current FlexJS, and I am much appreciated, I
> will contribute what I can, when I can in the future, these months I'm
> gonna be very busy though.
> >
> >
> > DarkStone
> > 2014-07-08
> >
> >
> >
> > At 2014-07-08 04:29:40, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> >> OK, here goes - why I think the FlexJS concept can be improved upon (in
> no
> >> particular order):
> >>
> >> 1 - there is no migration path for existing Flex applications; this will
> >> make enterprise users reluctant to accept the new framework, even though
> >> during development FlexJS is limiting itself because it aims to please
> the
> >> enterprise user (IE 'old' support)
> >> 2 - FlexJS requires a brand new framework on both the AS and JS side
> (apart
> >> from some stuff that may cross compile), effectively doubling the
> effort to
> >> bring it up to speed with other frameworks - including regular Flex
> >> 3 - Strands/Beads: it forces developers to know the insides of
> components,
> >> adding a level of complexity and a steeper learning curve to the
> framework
> >>   I - by the time there are enough components/strands and beads to have
> a
> >> useful framework, the set of beads will be too big to easily work with
> >> (e.g. "org.apache.flex.html.beads.DataItemRendererFactoryForArrayData"
> or
> >>
> "org.apache.flex.html.beads.controllers.ListSingleSelectionMouseController")
> >>   II - making beads work on all strands makes beads complicated; making
> >> beads that don't work on all strands makes beads confusing for the
> developer
> >> 4 - forced MVC: as an option it would be great, as a 'feature' not so
> much:
> >> it makes smaller projects unnecessarily complicated (e.g. all examples)
> >> 5 - lack of direction: FlexJS is a collection of proofs of concept,
> created
> >> top down to make nice looking demos that are then abandoned or
> superseded
> >> by other proofs of concept or demos.
> >>
> >> I think we already have a pretty nice AS framework, the Flex SDK, which
> I
> >> intend to offer as-is. Rather, I plan to make the 'export to JS'
> feature a
> >> part of the regular Flex SDK. That way the user can open any Flex
> project,
> >> run the export and get a fully functional, identical looking
> application in
> >> JS, or, worst case, a nice list from the compiler explaining which
> >> components/properties don't (yet) work in JS and how to fix that.
> >>
> >> I'm interested to hear more about how you think this approach is
> related to
> >> FlexJS. If there is any synergy to be had, I'm all for it!
> >>
> >> EdB
> >>
> >>
> >>
> >>> On Mon, Jul 7, 2014 at 6:27 PM, Alex Harui <ah...@adobe.com> wrote:
> >>>
> >>> I'm not sure what you mean by "philosophical".  I see more similarities
> >>> than differences between FlexJS and your approach of trying to mimic
> more
> >>> of the current SDK in JS.  In fact, I still hope to convince you that
> what
> >>> you want to do is within the FlexJS charter so we can work together
> >>> instead appearing to work on separate efforts.  And then what you are
> >>> working on would also be weakened by whatever it is you want to say.
>  If
> >>> you have a killer argument why folks should not be trying to compile
> MXML
> >>> and AS to JS, I think the whole community will be better served by
> finding
> >>> out why now.
> >>>
> >>> -Alex
> >>>
> >>>> On 7/7/14 8:40 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> >>>>
> >>>> There are no technical issues per se that would need addressing to
> keep
> >>>> FlexJS healthy. I made sure of that.
> >>>>
> >>>> My argument is basically philosophical, and I think my ranting about
> it in
> >>>> public would weaken FlexJS' case, so I won't.
> >>>>
> >>>> EdB
> >>>>
> >>>>
> >>>>
> >>>>> On Thu, Jul 3, 2014 at 4:47 PM, Alex Harui <ah...@adobe.com> wrote:
> >>>>>
> >>>>> I think it has to be in public.  This is open development.  I'm
> hoping
> >>>>> you
> >>>>> will save me time by doing so.  If we are doing something we
> shouldn't
> >>>>> we
> >>>>> should correct it now otherwise we'll waste time and energy doing
> more
> >>>>> work in that direction only to find out that customers have the same
> >>>>> feedback.
> >>>>>
> >>>>> Not that all of your feedback is guaranteed to be addressed: there's
> >>>>> always a chance that what you don't like is philosophical rather than
> >>>>> technical.  That's why there are dozens of JS frameworks already and
> why
> >>>>> you want to try a different approach.
> >>>>>
> >>>>> -Alex
> >>>>>
> >>>>>> On 7/3/14 12:00 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> >>>>>>
> >>>>>> You want to hear that in public, or do you want to take this off
> list?
> >>>>>>
> >>>>>> EdB
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> On Thu, Jul 3, 2014 at 7:53 AM, Alex Harui <ah...@adobe.com>
> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> I've been doing that as well for the last couple of years. I spent
> >>>>>>> most of
> >>>>>>>> my time getting FlexJS off the ground. But I don't agree with some
> >>>>> of
> >>>>>>> the
> >>>>>>>> basic assumptions and choices that FlexJS has made. I said little
> or
> >>>>>>>> nothing about it to give FlexJS a proper head start and to keep
> you
> >>>>> and
> >>>>>>>> Peter going. But now that I have re-evaluated what the project
> >>>>> means to
> >>>>>>>> me,
> >>>>>>>> and what I would like to spend my time on when contributing, and I
> >>>>>>> have to
> >>>>>>>> give my take on Flex to JS a try.
> >>>>>>> I'd love to hear your thoughts on what you don't agree with
> regarding
> >>>>>>> FlexJS.
> >>>>>>>
> >>>>>>> -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
>



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

Re: New Flex to JS project

[Peter Ent <pe...@adobe.com>]

I'm sure Alex is composing a longer response, but I wanted to chime in having developed a number of beads and components of FlexJS. 

FlexJS is designed to be a pay-as-go system, keeping the app size as small as possible; even a small Flex app brings in a lot of code. 

I have to agree that beads should be more generic and easier to connect. The reason for many beads is so you can add on just the functionality you need. Perhaps having a reduced number of beads that are more generic would make it easier to choose. Then, if you found yourself using the same combination repeatedly, you would make this a custom component in your app. 

And yes, the examples only go so far and new things have appeared. This is at alpha stage so there will be iterations. We needed to get sufficient components together so we could survey how it all hangs together. 

We are hoping more people will join the project and help with the direction and development. 

I think the core idea is sound and could use some tweaking.

Peter 


> On Jul 8, 2014, at 6:11 AM, "DarkStone" <da...@163.com> wrote:
> 
> Hi Erik,
> 
> Thank you very much for bringing this topic, it's the very topic I want to share my thoughts on.
> 
>> 3 - Strands/Beads: it forces developers to know the insides of components,
>> adding a level of complexity and a steeper learning curve to the framework
>> 4 - forced MVC: as an option it would be great, as a 'feature' not so much:
>> it makes smaller projects unnecessarily complicated (e.g. all examples)
> 
> I totally agree all the 5 points you've made, especially the 2 points above, I studied FlexJS' Strands/Beads MVC concept before, it forced me to do a restricted MVC application design.
> 
> In most case, developers should have the abilities to design their own MVC concepts, rather than having to follow a pre-designed MVC concept. That is why Flex named itself "Flex", the flexibility is the soul of Flex, isn't it : )
> 
> I think Flex Spark's SkinnableComponent and Skin are good enough to separate a component's Logic and Skin. The Logic part of the component can then be divided into Model and Controller in anyway the developer want them to be, that is already the case in Flex Spark architecture, developers can decide how to design their own MVC concepts and apply them to their custom components, it's better this way.
> 
> Besides, there are already a huge amount of projects based on the existing Flex Spark architecture, it will be much better if FlexJS can base on the Spark architecture, and makes the existing Flex projects much easier to transit to FlexJS.
> 
> It took a very long time (over 10 years) to have Flex come this way, to make the Flex Spark architecture popular is already hard enough, so for the FlexJS, a smoother and easier transition from Flex to FlexJS is much needed!
> 
> Well that is just my personal opinion, I know there are already a lot of hard works were put into the current FlexJS, and I am much appreciated, I will contribute what I can, when I can in the future, these months I'm gonna be very busy though.
> 
> 
> DarkStone
> 2014-07-08
> 
> 
> 
> At 2014-07-08 04:29:40, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>> OK, here goes - why I think the FlexJS concept can be improved upon (in no
>> particular order):
>> 
>> 1 - there is no migration path for existing Flex applications; this will
>> make enterprise users reluctant to accept the new framework, even though
>> during development FlexJS is limiting itself because it aims to please the
>> enterprise user (IE 'old' support)
>> 2 - FlexJS requires a brand new framework on both the AS and JS side (apart
>> from some stuff that may cross compile), effectively doubling the effort to
>> bring it up to speed with other frameworks - including regular Flex
>> 3 - Strands/Beads: it forces developers to know the insides of components,
>> adding a level of complexity and a steeper learning curve to the framework
>>   I - by the time there are enough components/strands and beads to have a
>> useful framework, the set of beads will be too big to easily work with
>> (e.g. "org.apache.flex.html.beads.DataItemRendererFactoryForArrayData" or
>> "org.apache.flex.html.beads.controllers.ListSingleSelectionMouseController")
>>   II - making beads work on all strands makes beads complicated; making
>> beads that don't work on all strands makes beads confusing for the developer
>> 4 - forced MVC: as an option it would be great, as a 'feature' not so much:
>> it makes smaller projects unnecessarily complicated (e.g. all examples)
>> 5 - lack of direction: FlexJS is a collection of proofs of concept, created
>> top down to make nice looking demos that are then abandoned or superseded
>> by other proofs of concept or demos.
>> 
>> I think we already have a pretty nice AS framework, the Flex SDK, which I
>> intend to offer as-is. Rather, I plan to make the 'export to JS' feature a
>> part of the regular Flex SDK. That way the user can open any Flex project,
>> run the export and get a fully functional, identical looking application in
>> JS, or, worst case, a nice list from the compiler explaining which
>> components/properties don't (yet) work in JS and how to fix that.
>> 
>> I'm interested to hear more about how you think this approach is related to
>> FlexJS. If there is any synergy to be had, I'm all for it!
>> 
>> EdB
>> 
>> 
>> 
>>> On Mon, Jul 7, 2014 at 6:27 PM, Alex Harui <ah...@adobe.com> wrote:
>>> 
>>> I'm not sure what you mean by "philosophical".  I see more similarities
>>> than differences between FlexJS and your approach of trying to mimic more
>>> of the current SDK in JS.  In fact, I still hope to convince you that what
>>> you want to do is within the FlexJS charter so we can work together
>>> instead appearing to work on separate efforts.  And then what you are
>>> working on would also be weakened by whatever it is you want to say.  If
>>> you have a killer argument why folks should not be trying to compile MXML
>>> and AS to JS, I think the whole community will be better served by finding
>>> out why now.
>>> 
>>> -Alex
>>> 
>>>> On 7/7/14 8:40 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>> 
>>>> There are no technical issues per se that would need addressing to keep
>>>> FlexJS healthy. I made sure of that.
>>>> 
>>>> My argument is basically philosophical, and I think my ranting about it in
>>>> public would weaken FlexJS' case, so I won't.
>>>> 
>>>> EdB
>>>> 
>>>> 
>>>> 
>>>>> On Thu, Jul 3, 2014 at 4:47 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>> 
>>>>> I think it has to be in public.  This is open development.  I'm hoping
>>>>> you
>>>>> will save me time by doing so.  If we are doing something we shouldn't
>>>>> we
>>>>> should correct it now otherwise we'll waste time and energy doing more
>>>>> work in that direction only to find out that customers have the same
>>>>> feedback.
>>>>> 
>>>>> Not that all of your feedback is guaranteed to be addressed: there's
>>>>> always a chance that what you don't like is philosophical rather than
>>>>> technical.  That's why there are dozens of JS frameworks already and why
>>>>> you want to try a different approach.
>>>>> 
>>>>> -Alex
>>>>> 
>>>>>> On 7/3/14 12:00 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>>>> 
>>>>>> You want to hear that in public, or do you want to take this off list?
>>>>>> 
>>>>>> EdB
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Thu, Jul 3, 2014 at 7:53 AM, Alex Harui <ah...@adobe.com> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> I've been doing that as well for the last couple of years. I spent
>>>>>>> most of
>>>>>>>> my time getting FlexJS off the ground. But I don't agree with some
>>>>> of
>>>>>>> the
>>>>>>>> basic assumptions and choices that FlexJS has made. I said little or
>>>>>>>> nothing about it to give FlexJS a proper head start and to keep you
>>>>> and
>>>>>>>> Peter going. But now that I have re-evaluated what the project
>>>>> means to
>>>>>>>> me,
>>>>>>>> and what I would like to spend my time on when contributing, and I
>>>>>>> have to
>>>>>>>> give my take on Flex to JS a try.
>>>>>>> I'd love to hear your thoughts on what you don't agree with regarding
>>>>>>> FlexJS.
>>>>>>> 
>>>>>>> -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:Re: New Flex to JS project

[DarkStone <da...@163.com>]

Hi Erik,

Thank you very much for bringing this topic, it's the very topic I want to share my thoughts on.

>3 - Strands/Beads: it forces developers to know the insides of components,
>adding a level of complexity and a steeper learning curve to the framework
>4 - forced MVC: as an option it would be great, as a 'feature' not so much:
>it makes smaller projects unnecessarily complicated (e.g. all examples)

I totally agree all the 5 points you've made, especially the 2 points above, I studied FlexJS' Strands/Beads MVC concept before, it forced me to do a restricted MVC application design.

In most case, developers should have the abilities to design their own MVC concepts, rather than having to follow a pre-designed MVC concept. That is why Flex named itself "Flex", the flexibility is the soul of Flex, isn't it : )

I think Flex Spark's SkinnableComponent and Skin are good enough to separate a component's Logic and Skin. The Logic part of the component can then be divided into Model and Controller in anyway the developer want them to be, that is already the case in Flex Spark architecture, developers can decide how to design their own MVC concepts and apply them to their custom components, it's better this way.

Besides, there are already a huge amount of projects based on the existing Flex Spark architecture, it will be much better if FlexJS can base on the Spark architecture, and makes the existing Flex projects much easier to transit to FlexJS.

It took a very long time (over 10 years) to have Flex come this way, to make the Flex Spark architecture popular is already hard enough, so for the FlexJS, a smoother and easier transition from Flex to FlexJS is much needed!

Well that is just my personal opinion, I know there are already a lot of hard works were put into the current FlexJS, and I am much appreciated, I will contribute what I can, when I can in the future, these months I'm gonna be very busy though.


DarkStone
2014-07-08



At 2014-07-08 04:29:40, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>OK, here goes - why I think the FlexJS concept can be improved upon (in no
>particular order):
>
>1 - there is no migration path for existing Flex applications; this will
>make enterprise users reluctant to accept the new framework, even though
>during development FlexJS is limiting itself because it aims to please the
>enterprise user (IE 'old' support)
>2 - FlexJS requires a brand new framework on both the AS and JS side (apart
>from some stuff that may cross compile), effectively doubling the effort to
>bring it up to speed with other frameworks - including regular Flex
>3 - Strands/Beads: it forces developers to know the insides of components,
>adding a level of complexity and a steeper learning curve to the framework
>    I - by the time there are enough components/strands and beads to have a
>useful framework, the set of beads will be too big to easily work with
>(e.g. "org.apache.flex.html.beads.DataItemRendererFactoryForArrayData" or
>"org.apache.flex.html.beads.controllers.ListSingleSelectionMouseController")
>    II - making beads work on all strands makes beads complicated; making
>beads that don't work on all strands makes beads confusing for the developer
>4 - forced MVC: as an option it would be great, as a 'feature' not so much:
>it makes smaller projects unnecessarily complicated (e.g. all examples)
>5 - lack of direction: FlexJS is a collection of proofs of concept, created
>top down to make nice looking demos that are then abandoned or superseded
>by other proofs of concept or demos.
>
>I think we already have a pretty nice AS framework, the Flex SDK, which I
>intend to offer as-is. Rather, I plan to make the 'export to JS' feature a
>part of the regular Flex SDK. That way the user can open any Flex project,
>run the export and get a fully functional, identical looking application in
>JS, or, worst case, a nice list from the compiler explaining which
>components/properties don't (yet) work in JS and how to fix that.
>
>I'm interested to hear more about how you think this approach is related to
>FlexJS. If there is any synergy to be had, I'm all for it!
>
>EdB
>
>
>
>On Mon, Jul 7, 2014 at 6:27 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> I'm not sure what you mean by "philosophical".  I see more similarities
>> than differences between FlexJS and your approach of trying to mimic more
>> of the current SDK in JS.  In fact, I still hope to convince you that what
>> you want to do is within the FlexJS charter so we can work together
>> instead appearing to work on separate efforts.  And then what you are
>> working on would also be weakened by whatever it is you want to say.  If
>> you have a killer argument why folks should not be trying to compile MXML
>> and AS to JS, I think the whole community will be better served by finding
>> out why now.
>>
>> -Alex
>>
>> On 7/7/14 8:40 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>
>> >There are no technical issues per se that would need addressing to keep
>> >FlexJS healthy. I made sure of that.
>> >
>> >My argument is basically philosophical, and I think my ranting about it in
>> >public would weaken FlexJS' case, so I won't.
>> >
>> >EdB
>> >
>> >
>> >
>> >On Thu, Jul 3, 2014 at 4:47 PM, Alex Harui <ah...@adobe.com> wrote:
>> >
>> >> I think it has to be in public.  This is open development.  I'm hoping
>> >>you
>> >> will save me time by doing so.  If we are doing something we shouldn't
>> >>we
>> >> should correct it now otherwise we'll waste time and energy doing more
>> >> work in that direction only to find out that customers have the same
>> >> feedback.
>> >>
>> >> Not that all of your feedback is guaranteed to be addressed: there's
>> >> always a chance that what you don't like is philosophical rather than
>> >> technical.  That's why there are dozens of JS frameworks already and why
>> >> you want to try a different approach.
>> >>
>> >> -Alex
>> >>
>> >> On 7/3/14 12:00 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>> >>
>> >> >You want to hear that in public, or do you want to take this off list?
>> >> >
>> >> >EdB
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >On Thu, Jul 3, 2014 at 7:53 AM, Alex Harui <ah...@adobe.com> wrote:
>> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> >I've been doing that as well for the last couple of years. I spent
>> >> >>most of
>> >> >> >my time getting FlexJS off the ground. But I don't agree with some
>> >>of
>> >> >>the
>> >> >> >basic assumptions and choices that FlexJS has made. I said little or
>> >> >> >nothing about it to give FlexJS a proper head start and to keep you
>> >>and
>> >> >> >Peter going. But now that I have re-evaluated what the project
>> >>means to
>> >> >> >me,
>> >> >> >and what I would like to spend my time on when contributing, and I
>> >> >>have to
>> >> >> >give my take on Flex to JS a try.
>> >> >> I'd love to hear your thoughts on what you don't agree with regarding
>> >> >> FlexJS.
>> >> >>
>> >> >> -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: New Flex to JS project

[Erik de Bruin <er...@ixsoftware.nl>]

OK, here goes - why I think the FlexJS concept can be improved upon (in no
particular order):

1 - there is no migration path for existing Flex applications; this will
make enterprise users reluctant to accept the new framework, even though
during development FlexJS is limiting itself because it aims to please the
enterprise user (IE 'old' support)
2 - FlexJS requires a brand new framework on both the AS and JS side (apart
from some stuff that may cross compile), effectively doubling the effort to
bring it up to speed with other frameworks - including regular Flex
3 - Strands/Beads: it forces developers to know the insides of components,
adding a level of complexity and a steeper learning curve to the framework
    I - by the time there are enough components/strands and beads to have a
useful framework, the set of beads will be too big to easily work with
(e.g. "org.apache.flex.html.beads.DataItemRendererFactoryForArrayData" or
"org.apache.flex.html.beads.controllers.ListSingleSelectionMouseController")
    II - making beads work on all strands makes beads complicated; making
beads that don't work on all strands makes beads confusing for the developer
4 - forced MVC: as an option it would be great, as a 'feature' not so much:
it makes smaller projects unnecessarily complicated (e.g. all examples)
5 - lack of direction: FlexJS is a collection of proofs of concept, created
top down to make nice looking demos that are then abandoned or superseded
by other proofs of concept or demos.

I think we already have a pretty nice AS framework, the Flex SDK, which I
intend to offer as-is. Rather, I plan to make the 'export to JS' feature a
part of the regular Flex SDK. That way the user can open any Flex project,
run the export and get a fully functional, identical looking application in
JS, or, worst case, a nice list from the compiler explaining which
components/properties don't (yet) work in JS and how to fix that.

I'm interested to hear more about how you think this approach is related to
FlexJS. If there is any synergy to be had, I'm all for it!

EdB



On Mon, Jul 7, 2014 at 6:27 PM, Alex Harui <ah...@adobe.com> wrote:

> I'm not sure what you mean by "philosophical".  I see more similarities
> than differences between FlexJS and your approach of trying to mimic more
> of the current SDK in JS.  In fact, I still hope to convince you that what
> you want to do is within the FlexJS charter so we can work together
> instead appearing to work on separate efforts.  And then what you are
> working on would also be weakened by whatever it is you want to say.  If
> you have a killer argument why folks should not be trying to compile MXML
> and AS to JS, I think the whole community will be better served by finding
> out why now.
>
> -Alex
>
> On 7/7/14 8:40 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
> >There are no technical issues per se that would need addressing to keep
> >FlexJS healthy. I made sure of that.
> >
> >My argument is basically philosophical, and I think my ranting about it in
> >public would weaken FlexJS' case, so I won't.
> >
> >EdB
> >
> >
> >
> >On Thu, Jul 3, 2014 at 4:47 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> I think it has to be in public.  This is open development.  I'm hoping
> >>you
> >> will save me time by doing so.  If we are doing something we shouldn't
> >>we
> >> should correct it now otherwise we'll waste time and energy doing more
> >> work in that direction only to find out that customers have the same
> >> feedback.
> >>
> >> Not that all of your feedback is guaranteed to be addressed: there's
> >> always a chance that what you don't like is philosophical rather than
> >> technical.  That's why there are dozens of JS frameworks already and why
> >> you want to try a different approach.
> >>
> >> -Alex
> >>
> >> On 7/3/14 12:00 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> >>
> >> >You want to hear that in public, or do you want to take this off list?
> >> >
> >> >EdB
> >> >
> >> >
> >> >
> >> >
> >> >On Thu, Jul 3, 2014 at 7:53 AM, Alex Harui <ah...@adobe.com> wrote:
> >> >
> >> >>
> >> >>
> >> >>
> >> >> >I've been doing that as well for the last couple of years. I spent
> >> >>most of
> >> >> >my time getting FlexJS off the ground. But I don't agree with some
> >>of
> >> >>the
> >> >> >basic assumptions and choices that FlexJS has made. I said little or
> >> >> >nothing about it to give FlexJS a proper head start and to keep you
> >>and
> >> >> >Peter going. But now that I have re-evaluated what the project
> >>means to
> >> >> >me,
> >> >> >and what I would like to spend my time on when contributing, and I
> >> >>have to
> >> >> >give my take on Flex to JS a try.
> >> >> I'd love to hear your thoughts on what you don't agree with regarding
> >> >> FlexJS.
> >> >>
> >> >> -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: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

I'm not sure what you mean by "philosophical".  I see more similarities
than differences between FlexJS and your approach of trying to mimic more
of the current SDK in JS.  In fact, I still hope to convince you that what
you want to do is within the FlexJS charter so we can work together
instead appearing to work on separate efforts.  And then what you are
working on would also be weakened by whatever it is you want to say.  If
you have a killer argument why folks should not be trying to compile MXML
and AS to JS, I think the whole community will be better served by finding
out why now.

-Alex

On 7/7/14 8:40 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:

>There are no technical issues per se that would need addressing to keep
>FlexJS healthy. I made sure of that.
>
>My argument is basically philosophical, and I think my ranting about it in
>public would weaken FlexJS' case, so I won't.
>
>EdB
>
>
>
>On Thu, Jul 3, 2014 at 4:47 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> I think it has to be in public.  This is open development.  I'm hoping
>>you
>> will save me time by doing so.  If we are doing something we shouldn't
>>we
>> should correct it now otherwise we'll waste time and energy doing more
>> work in that direction only to find out that customers have the same
>> feedback.
>>
>> Not that all of your feedback is guaranteed to be addressed: there's
>> always a chance that what you don't like is philosophical rather than
>> technical.  That's why there are dozens of JS frameworks already and why
>> you want to try a different approach.
>>
>> -Alex
>>
>> On 7/3/14 12:00 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>
>> >You want to hear that in public, or do you want to take this off list?
>> >
>> >EdB
>> >
>> >
>> >
>> >
>> >On Thu, Jul 3, 2014 at 7:53 AM, Alex Harui <ah...@adobe.com> wrote:
>> >
>> >>
>> >>
>> >>
>> >> >I've been doing that as well for the last couple of years. I spent
>> >>most of
>> >> >my time getting FlexJS off the ground. But I don't agree with some
>>of
>> >>the
>> >> >basic assumptions and choices that FlexJS has made. I said little or
>> >> >nothing about it to give FlexJS a proper head start and to keep you
>>and
>> >> >Peter going. But now that I have re-evaluated what the project
>>means to
>> >> >me,
>> >> >and what I would like to spend my time on when contributing, and I
>> >>have to
>> >> >give my take on Flex to JS a try.
>> >> I'd love to hear your thoughts on what you don't agree with regarding
>> >> FlexJS.
>> >>
>> >> -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: New Flex to JS project

[Erik de Bruin <er...@ixsoftware.nl>]

There are no technical issues per se that would need addressing to keep
FlexJS healthy. I made sure of that.

My argument is basically philosophical, and I think my ranting about it in
public would weaken FlexJS' case, so I won't.

EdB



On Thu, Jul 3, 2014 at 4:47 PM, Alex Harui <ah...@adobe.com> wrote:

> I think it has to be in public.  This is open development.  I'm hoping you
> will save me time by doing so.  If we are doing something we shouldn't we
> should correct it now otherwise we'll waste time and energy doing more
> work in that direction only to find out that customers have the same
> feedback.
>
> Not that all of your feedback is guaranteed to be addressed: there's
> always a chance that what you don't like is philosophical rather than
> technical.  That's why there are dozens of JS frameworks already and why
> you want to try a different approach.
>
> -Alex
>
> On 7/3/14 12:00 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
> >You want to hear that in public, or do you want to take this off list?
> >
> >EdB
> >
> >
> >
> >
> >On Thu, Jul 3, 2014 at 7:53 AM, Alex Harui <ah...@adobe.com> wrote:
> >
> >>
> >>
> >>
> >> >I've been doing that as well for the last couple of years. I spent
> >>most of
> >> >my time getting FlexJS off the ground. But I don't agree with some of
> >>the
> >> >basic assumptions and choices that FlexJS has made. I said little or
> >> >nothing about it to give FlexJS a proper head start and to keep you and
> >> >Peter going. But now that I have re-evaluated what the project means to
> >> >me,
> >> >and what I would like to spend my time on when contributing, and I
> >>have to
> >> >give my take on Flex to JS a try.
> >> I'd love to hear your thoughts on what you don't agree with regarding
> >> FlexJS.
> >>
> >> -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: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

I think it has to be in public.  This is open development.  I'm hoping you
will save me time by doing so.  If we are doing something we shouldn't we
should correct it now otherwise we'll waste time and energy doing more
work in that direction only to find out that customers have the same
feedback.

Not that all of your feedback is guaranteed to be addressed: there's
always a chance that what you don't like is philosophical rather than
technical.  That's why there are dozens of JS frameworks already and why
you want to try a different approach.

-Alex

On 7/3/14 12:00 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:

>You want to hear that in public, or do you want to take this off list?
>
>EdB
>
>
>
>
>On Thu, Jul 3, 2014 at 7:53 AM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>>
>> >I've been doing that as well for the last couple of years. I spent
>>most of
>> >my time getting FlexJS off the ground. But I don't agree with some of
>>the
>> >basic assumptions and choices that FlexJS has made. I said little or
>> >nothing about it to give FlexJS a proper head start and to keep you and
>> >Peter going. But now that I have re-evaluated what the project means to
>> >me,
>> >and what I would like to spend my time on when contributing, and I
>>have to
>> >give my take on Flex to JS a try.
>> I'd love to hear your thoughts on what you don't agree with regarding
>> FlexJS.
>>
>> -Alex
>>
>>
>
>
>-- 
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl

Re: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

On 7/3/14 6:10 AM, "Igor Costa" <ig...@gmail.com> wrote:

>@Alex
>
>I will push to my white_board for sure it's already in Apache license.
>The
>good thing about polymer it's event handling that got my attention and
>'design in mind' like we had with Flex Spark components.
>
>That's very cool about cordova, jquery and createJS. It's available
>anywhere?
It is in the releases and examples.  This is all early alpha stuff so feel
free to add your polymer stuff in the same way.  Grepping for Cordove,
jquery or createJS should show you the examples and files that go in the
SWC although soon we will break them out into their own swcs.


-Alex

Re: New Flex to JS project

[Igor Costa <ig...@gmail.com>]

@Alex

I will push to my white_board for sure it's already in Apache license.  The
good thing about polymer it's event handling that got my attention and
'design in mind' like we had with Flex Spark components.

That's very cool about cordova, jquery and createJS. It's available
anywhere?


Best

----------------------------
Igor Costa
www.igorcosta.com
www.igorcosta.org


On Thu, Jul 3, 2014 at 4:00 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:

> You want to hear that in public, or do you want to take this off list?
>
> EdB
>
>
>
>
> On Thu, Jul 3, 2014 at 7:53 AM, Alex Harui <ah...@adobe.com> wrote:
>
> >
> >
> >
> > >I've been doing that as well for the last couple of years. I spent most
> of
> > >my time getting FlexJS off the ground. But I don't agree with some of
> the
> > >basic assumptions and choices that FlexJS has made. I said little or
> > >nothing about it to give FlexJS a proper head start and to keep you and
> > >Peter going. But now that I have re-evaluated what the project means to
> > >me,
> > >and what I would like to spend my time on when contributing, and I have
> to
> > >give my take on Flex to JS a try.
> > I'd love to hear your thoughts on what you don't agree with regarding
> > FlexJS.
> >
> > -Alex
> >
> >
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>

Re: New Flex to JS project

[Erik de Bruin <er...@ixsoftware.nl>]

You want to hear that in public, or do you want to take this off list?

EdB




On Thu, Jul 3, 2014 at 7:53 AM, Alex Harui <ah...@adobe.com> wrote:

>
>
>
> >I've been doing that as well for the last couple of years. I spent most of
> >my time getting FlexJS off the ground. But I don't agree with some of the
> >basic assumptions and choices that FlexJS has made. I said little or
> >nothing about it to give FlexJS a proper head start and to keep you and
> >Peter going. But now that I have re-evaluated what the project means to
> >me,
> >and what I would like to spend my time on when contributing, and I have to
> >give my take on Flex to JS a try.
> I'd love to hear your thoughts on what you don't agree with regarding
> FlexJS.
>
> -Alex
>
>


-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

Re: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

>I've been doing that as well for the last couple of years. I spent most of
>my time getting FlexJS off the ground. But I don't agree with some of the
>basic assumptions and choices that FlexJS has made. I said little or
>nothing about it to give FlexJS a proper head start and to keep you and
>Peter going. But now that I have re-evaluated what the project means to
>me,
>and what I would like to spend my time on when contributing, and I have to
>give my take on Flex to JS a try.
I'd love to hear your thoughts on what you don't agree with regarding
FlexJS.

-Alex

Re: New Flex to JS project

[Erik de Bruin <er...@ixsoftware.nl>]

>
> The namespace and MVC in in the new AS/JS framework but I don't think
> there is anything in the current FlexJS setup what would block you from
> swapping in a set of SWCs that use the mx and/or spark NS.
>

No, I'm actually swapping OUT the mx and/or Spark NS from the regular SDK.
VF2JS projects are regular Flex projects, using the 4.13.0 SDK or whatever
is current at the time. User code normally, with the regular Flex
namespaces. They use the normal workflow to debug and publish their
projects to SWF. Only when the chose to publish to JS the fun starts. I
create a copy of their regular MX/Spark project, swap out the 's' and 'mx'
namespaces for the new ones I created and feed that temporary copy to
FalconJX. Since it uses the new namespaces, the compiler will compile
against the shim components I created in the accompanying projects. That
way if there are APIs used in the regular Flex project that are not
supported in the JavaScript framework - and therefor not present in the
shims- the compiler will warn the user and ignore that API.

>On the JS side,
> >no MXML as data, just objects/components and much more integration with
> >the
> >GC Library (createDom, enterDocument and Dispose for life cycle of any
> >component; event handling through current API instead of deprecated stuff;
> >ES5 and 6 etc.).
> Other than MXML as data, I don't think there is anything about current
> FlexJS that would prevent you from building out a JS library that uses
> more of GC as you want.  I hope there will be libraries that live on top
> of Jquery, Angular, etc
>

Trust me, I build a lot of the FalconJX code that translates AS/MXML to JS,
as well as some of the core functionality of the JS framework and there is
a lot of room for improvement in there.


> I'm just looking for ways to avoid us doing some things twice.
>

I've been doing that as well for the last couple of years. I spent most of
my time getting FlexJS off the ground. But I don't agree with some of the
basic assumptions and choices that FlexJS has made. I said little or
nothing about it to give FlexJS a proper head start and to keep you and
Peter going. But now that I have re-evaluated what the project means to me,
and what I would like to spend my time on when contributing, and I have to
give my take on Flex to JS a try.

I will keep supporting FlexJS where it concerns changes/enhancements that
need to be made to FalconJX, of course.

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

Re: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

On 7/2/14 10:05 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:

>>
>> I'm still trying to figure out why your Vanilla implementation, given it
>> is going to have custom swcs, isn't just another FlexJS library.  I
>>think
>> the main difference is in the reporting of missing mx/spark APIs.  Is
>> there more?
>
>
>No, there is less. No special namespaces or MVC for the Flex side, just
>the
>SDK as we know and love it, unchanged as far as the user is concerned -
>any
>project that uses MX and/or Spark will cross compile to JS.
The namespace and MVC in in the new AS/JS framework but I don't think
there is anything in the current FlexJS setup what would block you from
swapping in a set of SWCs that use the mx and/or spark NS.

>On the JS side,
>no MXML as data, just objects/components and much more integration with
>the
>GC Library (createDom, enterDocument and Dispose for life cycle of any
>component; event handling through current API instead of deprecated stuff;
>ES5 and 6 etc.).
Other than MXML as data, I don't think there is anything about current
FlexJS that would prevent you from building out a JS library that uses
more of GC as you want.  I hope there will be libraries that live on top
of Jquery, Angular, etc.

I'm just looking for ways to avoid us doing some things twice.

-Alex

Re: New Flex to JS project

[Erik de Bruin <er...@ixsoftware.nl>]

>
> I'm still trying to figure out why your Vanilla implementation, given it
> is going to have custom swcs, isn't just another FlexJS library.  I think
> the main difference is in the reporting of missing mx/spark APIs.  Is
> there more?


No, there is less. No special namespaces or MVC for the Flex side, just the
SDK as we know and love it, unchanged as far as the user is concerned - any
project that uses MX and/or Spark will cross compile to JS. On the JS side,
no MXML as data, just objects/components and much more integration with the
GC Library (createDom, enterDocument and Dispose for life cycle of any
component; event handling through current API instead of deprecated stuff;
ES5 and 6 etc.).

EdB




> -Alex
>
> On 7/2/14 8:42 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
> >>
> >> Sounds interesting.  Is there any way to get more information on what
> >> kinds of changes are going to be made?  More comments in-line.
> >>
> >
> >I'm basically making this up as I go along, but... The workflow for
> >producing SWFs doesn't change at all. Hence 'Vanilla Flex'. If someone
> >wants to publish his normal Flex project to JavaScript, he uses an
> >External
> >Tool to launch FalconJX with the vanilla Flex project as input. In order
> >to
> >give the user feedback on which components and properties on components
> >are
> >supported by the JS framework, the Flex SDK gets two new namespaces with
> >accompanying shim components. The shims will contain only the public APIs
> >supported by the JS framework. These namespaces will be 'swapped in' by
> >FalconJX during a publish to JS. I plan to have the compiler produce a
> >nice
> >full AST or give the user feedback about stuff it cannot 'translate'
> >because the shim components don't allow complete compilation due to the
> >use
> >of unsupported properties. From the AST, I plan to use all I learned
> >writing FalconJX for FlexJS and using the GC Tools daily for over a year
> >now, and produce very GCC friendly JavaScript.
> >
> >>1) two new namespaces and accompanying projects in the main Flex SDK:
> >> >vf2js_mx and vf2js_s. These namespaces will contain shim objects for
> >>(you
> >> >guessed it) MX and Spark components.
> >> Just wondering after seeing all the branch/merge discussion: are you
> >>sure
> >> you can't auto-generate the shims via a custom back-end for FalconJX?
> >>It
> >> could suck in your JS files as well if that helps to compute the shim.
> >> Then you may not need to branch/merge at all and just be a separate swc
> >> project or two (or three).
> >>
> >
> >I have two new projects in 'sdk/frameworks/projects', and I've changed the
> >supporting files to build them with the SDK. There are relatively few
> >changes in the SDK, apart from those new swc projects. I was told to
> >branch, and I did because I'm not sure if the changes I made to the
> >supporting config files are correct. When I have a working prototype, and
> >my branched SDK passes all Mustella tests, I'll start asking permission to
> >merge it back into 'develop'. The new stuff doesn't touch any of the
> >existing stuff, so I'm not expecting any problems on that front.
> >
> >>2) two new code paths in FalconJX: one for AS and one for MXML
> >> If the changes going in here are not going to interfere with FlexJS, I
> >> don't see why you need to branch now.  FlexJS is in alpha, so having
> >>other
> >> alpha/prototype code in its release shouldn't be a killer.
> >
> >
> >I decided to branch this project because I expect not to be able to leave
> >the FalconJX in a functioning state after each and every commit. I don't
> >want to bother anyone with my half backed experiments, let alone break the
> >nightly builds.
> >
> >
> >> >B - In order for this to work, FalconJX needs to be part of the regular
> >> >SDK
> >> >distribution. Folks who did this on the FlexJS overlay: what does it
> >>take
> >> >to make FalconJX part of the SDK?
> >>
> >> I'm not quite sure what this means.  Why can't it be an overlay?  If
> >>Chris
> >> is right and you want FB integration such that building the FB project
> >> runs FalconJX, that part is in the flex-oem-compiler project.  You
> >>should
> >> be able to follow what I did in git history and get an idea of what you
> >> need to change, but there is one possible gotcha:  FB runs in Java 6
> >>and I
> >> believe GCC required Java 7.  I'm not sure if there is a way to have
> >>FB's
> >> Java 6 call into GCC without recompiling GCC to Java 6 (which is an
> >>option
> >> I think).
> >>
> >
> >The idea is to change nothing to the FB workflow, just add an External
> >Tool
> >option to publish an existing project to JavaScript. I hope, since the aim
> >is to have 'vanilla' SWF development, that we can make this project part
> >of
> >the regular SDK, not a separate release. Also, I figure that another
> >subproject that needs a release cycle etc. might very well break Apache
> >Flex due to release overload.
> >
> >But we're not there yet, so, first things first: a nice proof of concept
> >and some thinking on how we can best make this work from a user's point of
> >view.
> >
> >Thanks,
> >
> >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: New Flex to JS project

[Mark Kessler <ke...@gmail.com>]

I use tons of dot path references for xml/e4x.  And much less frequently
the inline filtering.

-Mark


On Fri, Jul 4, 2014 at 3:21 AM, Alex Harui <ah...@adobe.com> wrote:

> There are functions, but I've seen significant use of XML as an "Object".
> IMO it is what makes e4x possible: the dot-path lookup as below:
>
> Var foo:XML = <this><is><a name="test" /></is></this>
>
>
> Trace(foo.is);
> Trace(foo..a(@name=="test"));
> Trace(foo..test);
>
> But I could be wrong and there is some other way to handle this.
>
> -Alex
>

Re: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

On 7/6/14 10:27 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:

>
>Things like public Atom, RSS feeds do require XML processing.
I would assume someone has successfully handles RSS in JS already,
probably by using whatever XML apis are there.  And that is always an
option, but I believe Flash and JS XML APIs are different enough to make
that a painful cross-compile.  But attempts at that are welcome as well.

>Another
>scenario is where I wanted to try out my hand at exporting an Adobe
>Illustrator file to .FXG.  Now that the Creative Cloud extensions are
>HTML(5) based, that seems like a good target for FlexJS.
Thanks for reminding me to ping the CC Extensions folks after we ship
FlexJS 0.0.2.  I talked to them a while ago and they are interested.
Harbs was the first person to pose the idea to them.

>
>>
>> For others who really truly can't port the backend, it might be worth
>>the
>> time to convert from XML to Object, similar to the way the SOAPDecoder
>>and
>> XMLDecoders work today.  XML has always been much slower and memory
>> intensive in Flash and often folks convert to classes/objects.  FlexJS
>>has
>> support for that already, although there is no generic SOAPDecoder or
>> XMLDecoder.
>>
>
>I think mx.rpc.xml.SimpleXMLDecoder should lend itself to FlexJS quite
>well. Not exactly E4X, but at least it brings makes it closer to JSON.
>What do you think?
I think it might have some ties back to RPC, but yes, I would envision a
"convert all" decoder like that, plus a "lazy" decode.  I've seen the
"convert all" freeze Flash for certain XML data sets.

-Alex

Re: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

And I've been meaning to see if anyone has invented a proxy server that
does this sort of thing.

I'm still not convinced the compiler can convert e4x to these calls.  We
can if we force folks to strongly type everything, but I'd bet a lot of
existing code is not strongly-typed enough.  For example:

Class CustomItemRenderer
{
   Public function get data():Object
   {
	Return _data;
   }
}

If the CustomItemRenderer is used for an XMLListCollection, the data will
be XML but the compiler will not know that.

But yes, you are welcome to pursue making more of folks' XML code work in
FlexJS without porting.

-Alex

On 7/6/14 10:52 PM, "Harbs" <ha...@gmail.com> wrote:

>I used the wrong link. It should have been:
>https://developer.mozilla.org/en-US/docs/JXON
>
>On Jul 7, 2014, at 8:50 AM, Harbs <ha...@gmail.com> wrote:
>
>> I was thinking of creating a class which stores the xml structure
>>internally as javascript objects using these methods [1]
>> 
>> Then we could build on top of that all the standard E4X functions for
>>accessing nodes and attributes.
>> 
>> Dot notation would be complex (or impossible) to handle natively, but I
>>imagine FlaconJS could handle E4X dot notation as special cases and call
>>.child() and .attribute() respectively.
>> 
>> This should solve the performance concerns with using XML (because it
>>would be native js objects under the hood), but allow E4X type of
>>functionality.
>> 
>> I would not have a clue of how to go about handling the dot notation in
>>FlaconJS, but the first part should be pretty straight-forward.
>> 
>> [1] 
>>https://developer.mozilla.org/en-US/docs/Web/Guide/Parsing_and_serializin
>>g_XML
>> 
>> On Jul 7, 2014, at 8:27 AM, OmPrakash Muppirala <bi...@gmail.com>
>>wrote:
>> 
>>> On Sun, Jul 6, 2014 at 10:12 PM, Alex Harui <ah...@adobe.com> wrote:
>>> 
>>>> 
>>>> 
>>>> On 7/6/14 9:54 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>>>> 
>>>>> On Sun, Jul 6, 2014 at 9:49 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>> 
>>>>>> I certainly won't stop someone from trying to implement e4x in JS.
>>>>>>I
>>>>>> think there may already be some attempts.  I think a significant
>>>>>>number
>>>>>> of
>>>>>> folks use dot-path like Mark Kessler reported and so it will still
>>>>>>be a
>>>>>> porting challenge for folks to re-code to using functions.
>>>>>> 
>>>>>> That's why it isn't on my priority list: if you're going to port
>>>>>>your
>>>>>> e4x
>>>>>> dot-path expressions, it might just be better to go to JSON instead.
>>>>> 
>>>>> 
>>>>> Switching from XML to JSON will require a server side change in most
>>>>> scenarios.  That might not be an option for folks especially servers
>>>>>that
>>>>> they don't have control over.
>>>> This is true, but one of the philosophies of FlexJS is "would you
>>>>have had
>>>> to convert anyway?".  At least a couple potential FlexJS customers
>>>>have
>>>> already built out JSON backends as they explore which JS migration
>>>> strategy to take.   It appears that, at least for those folks, the
>>>>notion
>>>> of using XML in JS is too nasty and it is worth the time to change the
>>>> backend.
>>>> 
>>> 
>>> Things like public Atom, RSS feeds do require XML processing.  Another
>>> scenario is where I wanted to try out my hand at exporting an Adobe
>>> Illustrator file to .FXG.  Now that the Creative Cloud extensions are
>>> HTML(5) based, that seems like a good target for FlexJS.  If XML is not
>>> supported, this use case is a non-starter.
>>> 
>>> 
>>>> 
>>>> For others who really truly can't port the backend, it might be worth
>>>>the
>>>> time to convert from XML to Object, similar to the way the
>>>>SOAPDecoder and
>>>> XMLDecoders work today.  XML has always been much slower and memory
>>>> intensive in Flash and often folks convert to classes/objects.
>>>>FlexJS has
>>>> support for that already, although there is no generic SOAPDecoder or
>>>> XMLDecoder.
>>>> 
>>> 
>>> I think mx.rpc.xml.SimpleXMLDecoder should lend itself to FlexJS quite
>>> well. Not exactly E4X, but at least it brings makes it closer to JSON.
>>> What do you think?
>>> 
>>> 
>>>> 
>>>> But again, anyone is welcome to take on trying to support e4x in JS.
>>>> 
>>>> -Alex
>> 
>

Re: New Flex to JS project

[Harbs <ha...@gmail.com>]

I used the wrong link. It should have been:
https://developer.mozilla.org/en-US/docs/JXON

On Jul 7, 2014, at 8:50 AM, Harbs <ha...@gmail.com> wrote:

> I was thinking of creating a class which stores the xml structure internally as javascript objects using these methods [1]
> 
> Then we could build on top of that all the standard E4X functions for accessing nodes and attributes.
> 
> Dot notation would be complex (or impossible) to handle natively, but I imagine FlaconJS could handle E4X dot notation as special cases and call .child() and .attribute() respectively.
> 
> This should solve the performance concerns with using XML (because it would be native js objects under the hood), but allow E4X type of functionality.
> 
> I would not have a clue of how to go about handling the dot notation in FlaconJS, but the first part should be pretty straight-forward.
> 
> [1] https://developer.mozilla.org/en-US/docs/Web/Guide/Parsing_and_serializing_XML
> 
> On Jul 7, 2014, at 8:27 AM, OmPrakash Muppirala <bi...@gmail.com> wrote:
> 
>> On Sun, Jul 6, 2014 at 10:12 PM, Alex Harui <ah...@adobe.com> wrote:
>> 
>>> 
>>> 
>>> On 7/6/14 9:54 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>>> 
>>>> On Sun, Jul 6, 2014 at 9:49 PM, Alex Harui <ah...@adobe.com> wrote:
>>>> 
>>>>> I certainly won't stop someone from trying to implement e4x in JS.  I
>>>>> think there may already be some attempts.  I think a significant number
>>>>> of
>>>>> folks use dot-path like Mark Kessler reported and so it will still be a
>>>>> porting challenge for folks to re-code to using functions.
>>>>> 
>>>>> That's why it isn't on my priority list: if you're going to port your
>>>>> e4x
>>>>> dot-path expressions, it might just be better to go to JSON instead.
>>>> 
>>>> 
>>>> Switching from XML to JSON will require a server side change in most
>>>> scenarios.  That might not be an option for folks especially servers that
>>>> they don't have control over.
>>> This is true, but one of the philosophies of FlexJS is "would you have had
>>> to convert anyway?".  At least a couple potential FlexJS customers have
>>> already built out JSON backends as they explore which JS migration
>>> strategy to take.   It appears that, at least for those folks, the notion
>>> of using XML in JS is too nasty and it is worth the time to change the
>>> backend.
>>> 
>> 
>> Things like public Atom, RSS feeds do require XML processing.  Another
>> scenario is where I wanted to try out my hand at exporting an Adobe
>> Illustrator file to .FXG.  Now that the Creative Cloud extensions are
>> HTML(5) based, that seems like a good target for FlexJS.  If XML is not
>> supported, this use case is a non-starter.
>> 
>> 
>>> 
>>> For others who really truly can't port the backend, it might be worth the
>>> time to convert from XML to Object, similar to the way the SOAPDecoder and
>>> XMLDecoders work today.  XML has always been much slower and memory
>>> intensive in Flash and often folks convert to classes/objects.  FlexJS has
>>> support for that already, although there is no generic SOAPDecoder or
>>> XMLDecoder.
>>> 
>> 
>> I think mx.rpc.xml.SimpleXMLDecoder should lend itself to FlexJS quite
>> well. Not exactly E4X, but at least it brings makes it closer to JSON.
>> What do you think?
>> 
>> 
>>> 
>>> But again, anyone is welcome to take on trying to support e4x in JS.
>>> 
>>> -Alex
> 

Re: New Flex to JS project

[Harbs <ha...@gmail.com>]

I was thinking of creating a class which stores the xml structure internally as javascript objects using these methods [1]

Then we could build on top of that all the standard E4X functions for accessing nodes and attributes.

Dot notation would be complex (or impossible) to handle natively, but I imagine FlaconJS could handle E4X dot notation as special cases and call .child() and .attribute() respectively.

This should solve the performance concerns with using XML (because it would be native js objects under the hood), but allow E4X type of functionality.

I would not have a clue of how to go about handling the dot notation in FlaconJS, but the first part should be pretty straight-forward.

[1] https://developer.mozilla.org/en-US/docs/Web/Guide/Parsing_and_serializing_XML

On Jul 7, 2014, at 8:27 AM, OmPrakash Muppirala <bi...@gmail.com> wrote:

> On Sun, Jul 6, 2014 at 10:12 PM, Alex Harui <ah...@adobe.com> wrote:
> 
>> 
>> 
>> On 7/6/14 9:54 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>> 
>>> On Sun, Jul 6, 2014 at 9:49 PM, Alex Harui <ah...@adobe.com> wrote:
>>> 
>>>> I certainly won't stop someone from trying to implement e4x in JS.  I
>>>> think there may already be some attempts.  I think a significant number
>>>> of
>>>> folks use dot-path like Mark Kessler reported and so it will still be a
>>>> porting challenge for folks to re-code to using functions.
>>>> 
>>>> That's why it isn't on my priority list: if you're going to port your
>>>> e4x
>>>> dot-path expressions, it might just be better to go to JSON instead.
>>> 
>>> 
>>> Switching from XML to JSON will require a server side change in most
>>> scenarios.  That might not be an option for folks especially servers that
>>> they don't have control over.
>> This is true, but one of the philosophies of FlexJS is "would you have had
>> to convert anyway?".  At least a couple potential FlexJS customers have
>> already built out JSON backends as they explore which JS migration
>> strategy to take.   It appears that, at least for those folks, the notion
>> of using XML in JS is too nasty and it is worth the time to change the
>> backend.
>> 
> 
> Things like public Atom, RSS feeds do require XML processing.  Another
> scenario is where I wanted to try out my hand at exporting an Adobe
> Illustrator file to .FXG.  Now that the Creative Cloud extensions are
> HTML(5) based, that seems like a good target for FlexJS.  If XML is not
> supported, this use case is a non-starter.
> 
> 
>> 
>> For others who really truly can't port the backend, it might be worth the
>> time to convert from XML to Object, similar to the way the SOAPDecoder and
>> XMLDecoders work today.  XML has always been much slower and memory
>> intensive in Flash and often folks convert to classes/objects.  FlexJS has
>> support for that already, although there is no generic SOAPDecoder or
>> XMLDecoder.
>> 
> 
> I think mx.rpc.xml.SimpleXMLDecoder should lend itself to FlexJS quite
> well. Not exactly E4X, but at least it brings makes it closer to JSON.
> What do you think?
> 
> 
>> 
>> But again, anyone is welcome to take on trying to support e4x in JS.
>> 
>> -Alex

Re: New Flex to JS project

[OmPrakash Muppirala <bi...@gmail.com>]

On Sun, Jul 6, 2014 at 10:12 PM, Alex Harui <ah...@adobe.com> wrote:

>
>
> On 7/6/14 9:54 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
> >On Sun, Jul 6, 2014 at 9:49 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> I certainly won't stop someone from trying to implement e4x in JS.  I
> >> think there may already be some attempts.  I think a significant number
> >>of
> >> folks use dot-path like Mark Kessler reported and so it will still be a
> >> porting challenge for folks to re-code to using functions.
> >>
> >> That's why it isn't on my priority list: if you're going to port your
> >>e4x
> >> dot-path expressions, it might just be better to go to JSON instead.
> >
> >
> >Switching from XML to JSON will require a server side change in most
> >scenarios.  That might not be an option for folks especially servers that
> >they don't have control over.
> This is true, but one of the philosophies of FlexJS is "would you have had
> to convert anyway?".  At least a couple potential FlexJS customers have
> already built out JSON backends as they explore which JS migration
> strategy to take.   It appears that, at least for those folks, the notion
> of using XML in JS is too nasty and it is worth the time to change the
> backend.
>

Things like public Atom, RSS feeds do require XML processing.  Another
scenario is where I wanted to try out my hand at exporting an Adobe
Illustrator file to .FXG.  Now that the Creative Cloud extensions are
HTML(5) based, that seems like a good target for FlexJS.  If XML is not
supported, this use case is a non-starter.


>
> For others who really truly can't port the backend, it might be worth the
> time to convert from XML to Object, similar to the way the SOAPDecoder and
> XMLDecoders work today.  XML has always been much slower and memory
> intensive in Flash and often folks convert to classes/objects.  FlexJS has
> support for that already, although there is no generic SOAPDecoder or
> XMLDecoder.
>

I think mx.rpc.xml.SimpleXMLDecoder should lend itself to FlexJS quite
well. Not exactly E4X, but at least it brings makes it closer to JSON.
What do you think?


>
> But again, anyone is welcome to take on trying to support e4x in JS.
>
> -Alex
>
>

Re: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

On 7/6/14 9:54 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:

>On Sun, Jul 6, 2014 at 9:49 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> I certainly won't stop someone from trying to implement e4x in JS.  I
>> think there may already be some attempts.  I think a significant number
>>of
>> folks use dot-path like Mark Kessler reported and so it will still be a
>> porting challenge for folks to re-code to using functions.
>>
>> That's why it isn't on my priority list: if you're going to port your
>>e4x
>> dot-path expressions, it might just be better to go to JSON instead.
>
>
>Switching from XML to JSON will require a server side change in most
>scenarios.  That might not be an option for folks especially servers that
>they don't have control over.
This is true, but one of the philosophies of FlexJS is "would you have had
to convert anyway?".  At least a couple potential FlexJS customers have
already built out JSON backends as they explore which JS migration
strategy to take.   It appears that, at least for those folks, the notion
of using XML in JS is too nasty and it is worth the time to change the
backend.

For others who really truly can't port the backend, it might be worth the
time to convert from XML to Object, similar to the way the SOAPDecoder and
XMLDecoders work today.  XML has always been much slower and memory
intensive in Flash and often folks convert to classes/objects.  FlexJS has
support for that already, although there is no generic SOAPDecoder or
XMLDecoder.

But again, anyone is welcome to take on trying to support e4x in JS.

-Alex

Re: New Flex to JS project

[OmPrakash Muppirala <bi...@gmail.com>]

On Sun, Jul 6, 2014 at 9:49 PM, Alex Harui <ah...@adobe.com> wrote:

> I certainly won't stop someone from trying to implement e4x in JS.  I
> think there may already be some attempts.  I think a significant number of
> folks use dot-path like Mark Kessler reported and so it will still be a
> porting challenge for folks to re-code to using functions.
>
> That's why it isn't on my priority list: if you're going to port your e4x
> dot-path expressions, it might just be better to go to JSON instead.


Switching from XML to JSON will require a server side change in most
scenarios.  That might not be an option for folks especially servers that
they don't have control over.

Thanks,
Om


>  I think any attempt to do e4x requires custom data objects with getters
> because there are many scenarios where it isn't clear to the compiler that
> you are compiling e4x.  For example, as the data property in an item
> renderer.
>
> -Alex
>
> On 7/5/14 11:41 PM, "Harbs" <ha...@gmail.com> wrote:
>
> >I think it is.
> >
> >Partial E4X support is better than none. We could offer support for the
> >more verbose form. I imagine it should be possible to do some conversions
> >of our own when compiling as well.
> >
> >I'm not sure how to go about handling filters though.
> >
> >On Jul 5, 2014, at 9:29 AM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> I've not looked to see if the compiler does that or the runtime.  I
> >>think
> >> it is the runtime isn't it?
> >>
> >> -Alex
> >>
> >> On 7/4/14 10:12 AM, "Gordon Smith" <gs...@hotmail.com> wrote:
> >>
> >>> I think this syntax is just sugar for more verbose function calls like
> >>>
> >>> trace(foo.children("is"))
> >>>
> >>> but the terse syntax is much nicer.
> >>>
> >>> - Gordon
> >>>
> >>> Sent from my iPad
> >>>
> >>>> On Jul 4, 2014, at 12:22 AM, "Alex Harui" <ah...@adobe.com> wrote:
> >>>>
> >>>> There are functions, but I've seen significant use of XML as an
> >>>> "Object".
> >>>> IMO it is what makes e4x possible: the dot-path lookup as below:
> >>>>
> >>>> Var foo:XML = <this><is><a name="test" /></is></this>
> >>>>
> >>>>
> >>>> Trace(foo.is);
> >>>> Trace(foo..a(@name=="test"));
> >>>> Trace(foo..test);
> >>>>
> >>>> But I could be wrong and there is some other way to handle this.
> >>>>
> >>>> -Alex
> >>>>
> >>>>> On 7/3/14 12:51 PM, "Harbs" <ha...@gmail.com> wrote:
> >>>>>
> >>>>> Why does it need setter/getter? E4X is all functions isn't it?
> >>>>>
> >>>>> Yeah. JSON is generally a better way to go, but some APIs are still
> >>>>>XML
> >>>>> and then there's manipulation of XML documents (which I tend to do a
> >>>>> lot
> >>>>> of...)
> >>>>>
> >>>>>> On Jul 3, 2014, at 7:53 PM, Alex Harui <ah...@adobe.com> wrote:
> >>>>>>
> >>>>>> I took a quick look a while back.  Required getter/setter support in
> >>>>>> the
> >>>>>> browser.  And then the remaining question: will it perform?  It is
> >>>>>> similar
> >>>>>> to the AMF question.  Doable, but may not be faster than switching
> >>>>>>to
> >>>>>> JSON.
> >>>>>>
> >>>>>> -Alex
> >>>>>>
> >>>>>>> On 7/3/14 9:48 AM, "Harbs" <ha...@gmail.com> wrote:
> >>>>>>>
> >>>>>>> Has anyone looked into writing a js library to copy the
> >>>>>>>functionality
> >>>>>>> of
> >>>>>>> E4X?
> >>>>>>>
> >>>>>>> It seems to me that at least 90% of E4X could be pretty easily
> >>>>>>> replicated
> >>>>>>> in a js libraryŠ
> >>>>>>>
> >>>>>>> Besides namespaces, the only thing that seems hard to me is complex
> >>>>>>> selectors.
> >>>>>>>
> >>>>>>>> On Jul 2, 2014, at 7:53 PM, Alex Harui <ah...@adobe.com> wrote:
> >>>>>>>>
> >>>>>>>> FWIW, FlexJS is eventually going to need to find a way to warn
> >>>>>>>>folks
> >>>>>>>> about
> >>>>>>>> use of E4X
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >
>
>

Re: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

I certainly won't stop someone from trying to implement e4x in JS.  I
think there may already be some attempts.  I think a significant number of
folks use dot-path like Mark Kessler reported and so it will still be a
porting challenge for folks to re-code to using functions.

That's why it isn't on my priority list: if you're going to port your e4x
dot-path expressions, it might just be better to go to JSON instead.  I
think any attempt to do e4x requires custom data objects with getters
because there are many scenarios where it isn't clear to the compiler that
you are compiling e4x.  For example, as the data property in an item
renderer.

-Alex

On 7/5/14 11:41 PM, "Harbs" <ha...@gmail.com> wrote:

>I think it is.
>
>Partial E4X support is better than none. We could offer support for the
>more verbose form. I imagine it should be possible to do some conversions
>of our own when compiling as well.
>
>I'm not sure how to go about handling filters though.
>
>On Jul 5, 2014, at 9:29 AM, Alex Harui <ah...@adobe.com> wrote:
>
>> I've not looked to see if the compiler does that or the runtime.  I
>>think
>> it is the runtime isn't it?
>> 
>> -Alex
>> 
>> On 7/4/14 10:12 AM, "Gordon Smith" <gs...@hotmail.com> wrote:
>> 
>>> I think this syntax is just sugar for more verbose function calls like
>>> 
>>> trace(foo.children("is"))
>>> 
>>> but the terse syntax is much nicer.
>>> 
>>> - Gordon
>>> 
>>> Sent from my iPad
>>> 
>>>> On Jul 4, 2014, at 12:22 AM, "Alex Harui" <ah...@adobe.com> wrote:
>>>> 
>>>> There are functions, but I've seen significant use of XML as an
>>>> "Object".
>>>> IMO it is what makes e4x possible: the dot-path lookup as below:
>>>> 
>>>> Var foo:XML = <this><is><a name="test" /></is></this>
>>>> 
>>>> 
>>>> Trace(foo.is);
>>>> Trace(foo..a(@name=="test"));
>>>> Trace(foo..test);
>>>> 
>>>> But I could be wrong and there is some other way to handle this.
>>>> 
>>>> -Alex
>>>> 
>>>>> On 7/3/14 12:51 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>> 
>>>>> Why does it need setter/getter? E4X is all functions isn't it?
>>>>> 
>>>>> Yeah. JSON is generally a better way to go, but some APIs are still
>>>>>XML
>>>>> and then there's manipulation of XML documents (which I tend to do a
>>>>> lot
>>>>> of...)
>>>>> 
>>>>>> On Jul 3, 2014, at 7:53 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>>> 
>>>>>> I took a quick look a while back.  Required getter/setter support in
>>>>>> the
>>>>>> browser.  And then the remaining question: will it perform?  It is
>>>>>> similar
>>>>>> to the AMF question.  Doable, but may not be faster than switching
>>>>>>to
>>>>>> JSON.
>>>>>> 
>>>>>> -Alex
>>>>>> 
>>>>>>> On 7/3/14 9:48 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>> 
>>>>>>> Has anyone looked into writing a js library to copy the
>>>>>>>functionality
>>>>>>> of
>>>>>>> E4X?
>>>>>>> 
>>>>>>> It seems to me that at least 90% of E4X could be pretty easily
>>>>>>> replicated
>>>>>>> in a js libraryŠ
>>>>>>> 
>>>>>>> Besides namespaces, the only thing that seems hard to me is complex
>>>>>>> selectors.
>>>>>>> 
>>>>>>>> On Jul 2, 2014, at 7:53 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>>>>> 
>>>>>>>> FWIW, FlexJS is eventually going to need to find a way to warn
>>>>>>>>folks
>>>>>>>> about
>>>>>>>> use of E4X
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
>

Re: New Flex to JS project

[Harbs <ha...@gmail.com>]

I think it is.

Partial E4X support is better than none. We could offer support for the more verbose form. I imagine it should be possible to do some conversions of our own when compiling as well.

I’m not sure how to go about handling filters though.

On Jul 5, 2014, at 9:29 AM, Alex Harui <ah...@adobe.com> wrote:

> I've not looked to see if the compiler does that or the runtime.  I think
> it is the runtime isn't it?
> 
> -Alex
> 
> On 7/4/14 10:12 AM, "Gordon Smith" <gs...@hotmail.com> wrote:
> 
>> I think this syntax is just sugar for more verbose function calls like
>> 
>> trace(foo.children("is"))
>> 
>> but the terse syntax is much nicer.
>> 
>> - Gordon
>> 
>> Sent from my iPad
>> 
>>> On Jul 4, 2014, at 12:22 AM, "Alex Harui" <ah...@adobe.com> wrote:
>>> 
>>> There are functions, but I've seen significant use of XML as an
>>> "Object".
>>> IMO it is what makes e4x possible: the dot-path lookup as below:
>>> 
>>> Var foo:XML = <this><is><a name="test" /></is></this>
>>> 
>>> 
>>> Trace(foo.is);
>>> Trace(foo..a(@name=="test"));
>>> Trace(foo..test);
>>> 
>>> But I could be wrong and there is some other way to handle this.
>>> 
>>> -Alex
>>> 
>>>> On 7/3/14 12:51 PM, "Harbs" <ha...@gmail.com> wrote:
>>>> 
>>>> Why does it need setter/getter? E4X is all functions isn't it?
>>>> 
>>>> Yeah. JSON is generally a better way to go, but some APIs are still XML
>>>> and then there's manipulation of XML documents (which I tend to do a
>>>> lot
>>>> of...)
>>>> 
>>>>> On Jul 3, 2014, at 7:53 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>> 
>>>>> I took a quick look a while back.  Required getter/setter support in
>>>>> the
>>>>> browser.  And then the remaining question: will it perform?  It is
>>>>> similar
>>>>> to the AMF question.  Doable, but may not be faster than switching to
>>>>> JSON.
>>>>> 
>>>>> -Alex
>>>>> 
>>>>>> On 7/3/14 9:48 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>> 
>>>>>> Has anyone looked into writing a js library to copy the functionality
>>>>>> of
>>>>>> E4X?
>>>>>> 
>>>>>> It seems to me that at least 90% of E4X could be pretty easily
>>>>>> replicated
>>>>>> in a js libraryŠ
>>>>>> 
>>>>>> Besides namespaces, the only thing that seems hard to me is complex
>>>>>> selectors.
>>>>>> 
>>>>>>> On Jul 2, 2014, at 7:53 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>>>> 
>>>>>>> FWIW, FlexJS is eventually going to need to find a way to warn folks
>>>>>>> about
>>>>>>> use of E4X
>>>>>> 
>>>>> 
>>>> 
>>> 
> 

Re: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

I've not looked to see if the compiler does that or the runtime.  I think
it is the runtime isn't it?

-Alex

On 7/4/14 10:12 AM, "Gordon Smith" <gs...@hotmail.com> wrote:

>I think this syntax is just sugar for more verbose function calls like
>
>trace(foo.children("is"))
>
>but the terse syntax is much nicer.
>
>- Gordon
>
>Sent from my iPad
>
>> On Jul 4, 2014, at 12:22 AM, "Alex Harui" <ah...@adobe.com> wrote:
>> 
>> There are functions, but I've seen significant use of XML as an
>>"Object".
>> IMO it is what makes e4x possible: the dot-path lookup as below:
>> 
>> Var foo:XML = <this><is><a name="test" /></is></this>
>> 
>> 
>> Trace(foo.is);
>> Trace(foo..a(@name=="test"));
>> Trace(foo..test);
>> 
>> But I could be wrong and there is some other way to handle this.
>> 
>> -Alex
>> 
>>> On 7/3/14 12:51 PM, "Harbs" <ha...@gmail.com> wrote:
>>> 
>>> Why does it need setter/getter? E4X is all functions isn't it?
>>> 
>>> Yeah. JSON is generally a better way to go, but some APIs are still XML
>>> and then there's manipulation of XML documents (which I tend to do a
>>>lot
>>> of...)
>>> 
>>>> On Jul 3, 2014, at 7:53 PM, Alex Harui <ah...@adobe.com> wrote:
>>>> 
>>>> I took a quick look a while back.  Required getter/setter support in
>>>>the
>>>> browser.  And then the remaining question: will it perform?  It is
>>>> similar
>>>> to the AMF question.  Doable, but may not be faster than switching to
>>>> JSON.
>>>> 
>>>> -Alex
>>>> 
>>>>> On 7/3/14 9:48 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>> 
>>>>> Has anyone looked into writing a js library to copy the functionality
>>>>> of
>>>>> E4X?
>>>>> 
>>>>> It seems to me that at least 90% of E4X could be pretty easily
>>>>> replicated
>>>>> in a js libraryŠ
>>>>> 
>>>>> Besides namespaces, the only thing that seems hard to me is complex
>>>>> selectors.
>>>>> 
>>>>>> On Jul 2, 2014, at 7:53 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>>> 
>>>>>> FWIW, FlexJS is eventually going to need to find a way to warn folks
>>>>>> about
>>>>>> use of E4X
>>>>> 
>>>> 
>>> 
>> 

Re: New Flex to JS project

[Gordon Smith <gs...@hotmail.com>]

I think this syntax is just sugar for more verbose function calls like

trace(foo.children("is"))

but the terse syntax is much nicer.

- Gordon

Sent from my iPad

> On Jul 4, 2014, at 12:22 AM, "Alex Harui" <ah...@adobe.com> wrote:
> 
> There are functions, but I've seen significant use of XML as an "Object".
> IMO it is what makes e4x possible: the dot-path lookup as below:
> 
> Var foo:XML = <this><is><a name="test" /></is></this>
> 
> 
> Trace(foo.is);
> Trace(foo..a(@name=="test"));
> Trace(foo..test);
> 
> But I could be wrong and there is some other way to handle this.
> 
> -Alex
> 
>> On 7/3/14 12:51 PM, "Harbs" <ha...@gmail.com> wrote:
>> 
>> Why does it need setter/getter? E4X is all functions isn't it?
>> 
>> Yeah. JSON is generally a better way to go, but some APIs are still XML
>> and then there's manipulation of XML documents (which I tend to do a lot
>> of...)
>> 
>>> On Jul 3, 2014, at 7:53 PM, Alex Harui <ah...@adobe.com> wrote:
>>> 
>>> I took a quick look a while back.  Required getter/setter support in the
>>> browser.  And then the remaining question: will it perform?  It is
>>> similar
>>> to the AMF question.  Doable, but may not be faster than switching to
>>> JSON.
>>> 
>>> -Alex
>>> 
>>>> On 7/3/14 9:48 AM, "Harbs" <ha...@gmail.com> wrote:
>>>> 
>>>> Has anyone looked into writing a js library to copy the functionality
>>>> of
>>>> E4X?
>>>> 
>>>> It seems to me that at least 90% of E4X could be pretty easily
>>>> replicated
>>>> in a js libraryŠ
>>>> 
>>>> Besides namespaces, the only thing that seems hard to me is complex
>>>> selectors.
>>>> 
>>>>> On Jul 2, 2014, at 7:53 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>> 
>>>>> FWIW, FlexJS is eventually going to need to find a way to warn folks
>>>>> about
>>>>> use of E4X
>>>> 
>>> 
>> 
> 

Re: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

There are functions, but I've seen significant use of XML as an "Object".
IMO it is what makes e4x possible: the dot-path lookup as below:

Var foo:XML = <this><is><a name="test" /></is></this>


Trace(foo.is);
Trace(foo..a(@name=="test"));
Trace(foo..test);

But I could be wrong and there is some other way to handle this.

-Alex

On 7/3/14 12:51 PM, "Harbs" <ha...@gmail.com> wrote:

>Why does it need setter/getter? E4X is all functions isn't it?
>
>Yeah. JSON is generally a better way to go, but some APIs are still XML
>and then there's manipulation of XML documents (which I tend to do a lot
>of...)
>
>On Jul 3, 2014, at 7:53 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> I took a quick look a while back.  Required getter/setter support in the
>> browser.  And then the remaining question: will it perform?  It is
>>similar
>> to the AMF question.  Doable, but may not be faster than switching to
>>JSON.
>> 
>> -Alex
>> 
>> On 7/3/14 9:48 AM, "Harbs" <ha...@gmail.com> wrote:
>> 
>>> Has anyone looked into writing a js library to copy the functionality
>>>of
>>> E4X?
>>> 
>>> It seems to me that at least 90% of E4X could be pretty easily
>>>replicated
>>> in a js libraryŠ
>>> 
>>> Besides namespaces, the only thing that seems hard to me is complex
>>> selectors.
>>> 
>>> On Jul 2, 2014, at 7:53 PM, Alex Harui <ah...@adobe.com> wrote:
>>> 
>>>> FWIW, FlexJS is eventually going to need to find a way to warn folks
>>>> about
>>>> use of E4X
>>> 
>> 
>

Re: New Flex to JS project

[Harbs <ha...@gmail.com>]

Why does it need setter/getter? E4X is all functions isn’t it?

Yeah. JSON is generally a better way to go, but some APIs are still XML and then there’s manipulation of XML documents (which I tend to do a lot of…)

On Jul 3, 2014, at 7:53 PM, Alex Harui <ah...@adobe.com> wrote:

> I took a quick look a while back.  Required getter/setter support in the
> browser.  And then the remaining question: will it perform?  It is similar
> to the AMF question.  Doable, but may not be faster than switching to JSON.
> 
> -Alex
> 
> On 7/3/14 9:48 AM, "Harbs" <ha...@gmail.com> wrote:
> 
>> Has anyone looked into writing a js library to copy the functionality of
>> E4X?
>> 
>> It seems to me that at least 90% of E4X could be pretty easily replicated
>> in a js libraryŠ
>> 
>> Besides namespaces, the only thing that seems hard to me is complex
>> selectors.
>> 
>> On Jul 2, 2014, at 7:53 PM, Alex Harui <ah...@adobe.com> wrote:
>> 
>>> FWIW, FlexJS is eventually going to need to find a way to warn folks
>>> about
>>> use of E4X
>> 
> 

Re: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

I took a quick look a while back.  Required getter/setter support in the
browser.  And then the remaining question: will it perform?  It is similar
to the AMF question.  Doable, but may not be faster than switching to JSON.

-Alex

On 7/3/14 9:48 AM, "Harbs" <ha...@gmail.com> wrote:

>Has anyone looked into writing a js library to copy the functionality of
>E4X?
>
>It seems to me that at least 90% of E4X could be pretty easily replicated
>in a js libraryŠ
>
>Besides namespaces, the only thing that seems hard to me is complex
>selectors.
>
>On Jul 2, 2014, at 7:53 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> FWIW, FlexJS is eventually going to need to find a way to warn folks
>>about
>> use of E4X
>

Re: New Flex to JS project

[Harbs <ha...@gmail.com>]

Has anyone looked into writing a js library to copy the functionality of E4X?

It seems to me that at least 90% of E4X could be pretty easily replicated in a js library…

Besides namespaces, the only thing that seems hard to me is complex selectors.

On Jul 2, 2014, at 7:53 PM, Alex Harui <ah...@adobe.com> wrote:

> FWIW, FlexJS is eventually going to need to find a way to warn folks about
> use of E4X

Re: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

That's kind of what I would've guessed.  Still makes me wonder about auto
generating the shims from your JS source.

FWIW, FlexJS is eventually going to need to find a way to warn folks about
use of E4X and a few other things in a FlexJS app.  I was going to try to
inject that intelligence into Falcon since in FlexJS that's where the
initial compilation runs.  Hopefully we can use the same implementation
for that.  It might be better to warn folks while they are
editing/compiling vs when they run the external tool.

I'm still trying to figure out why your Vanilla implementation, given it
is going to have custom swcs, isn't just another FlexJS library.  I think
the main difference is in the reporting of missing mx/spark APIs.  Is
there more?

-Alex

On 7/2/14 8:42 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:

>>
>> Sounds interesting.  Is there any way to get more information on what
>> kinds of changes are going to be made?  More comments in-line.
>>
>
>I'm basically making this up as I go along, but... The workflow for
>producing SWFs doesn't change at all. Hence 'Vanilla Flex'. If someone
>wants to publish his normal Flex project to JavaScript, he uses an
>External
>Tool to launch FalconJX with the vanilla Flex project as input. In order
>to
>give the user feedback on which components and properties on components
>are
>supported by the JS framework, the Flex SDK gets two new namespaces with
>accompanying shim components. The shims will contain only the public APIs
>supported by the JS framework. These namespaces will be 'swapped in' by
>FalconJX during a publish to JS. I plan to have the compiler produce a
>nice
>full AST or give the user feedback about stuff it cannot 'translate'
>because the shim components don't allow complete compilation due to the
>use
>of unsupported properties. From the AST, I plan to use all I learned
>writing FalconJX for FlexJS and using the GC Tools daily for over a year
>now, and produce very GCC friendly JavaScript.
>
>>1) two new namespaces and accompanying projects in the main Flex SDK:
>> >vf2js_mx and vf2js_s. These namespaces will contain shim objects for
>>(you
>> >guessed it) MX and Spark components.
>> Just wondering after seeing all the branch/merge discussion: are you
>>sure
>> you can't auto-generate the shims via a custom back-end for FalconJX?
>>It
>> could suck in your JS files as well if that helps to compute the shim.
>> Then you may not need to branch/merge at all and just be a separate swc
>> project or two (or three).
>>
>
>I have two new projects in 'sdk/frameworks/projects', and I've changed the
>supporting files to build them with the SDK. There are relatively few
>changes in the SDK, apart from those new swc projects. I was told to
>branch, and I did because I'm not sure if the changes I made to the
>supporting config files are correct. When I have a working prototype, and
>my branched SDK passes all Mustella tests, I'll start asking permission to
>merge it back into 'develop'. The new stuff doesn't touch any of the
>existing stuff, so I'm not expecting any problems on that front.
>
>>2) two new code paths in FalconJX: one for AS and one for MXML
>> If the changes going in here are not going to interfere with FlexJS, I
>> don't see why you need to branch now.  FlexJS is in alpha, so having
>>other
>> alpha/prototype code in its release shouldn't be a killer.
>
>
>I decided to branch this project because I expect not to be able to leave
>the FalconJX in a functioning state after each and every commit. I don't
>want to bother anyone with my half backed experiments, let alone break the
>nightly builds.
>
>
>> >B - In order for this to work, FalconJX needs to be part of the regular
>> >SDK
>> >distribution. Folks who did this on the FlexJS overlay: what does it
>>take
>> >to make FalconJX part of the SDK?
>>
>> I'm not quite sure what this means.  Why can't it be an overlay?  If
>>Chris
>> is right and you want FB integration such that building the FB project
>> runs FalconJX, that part is in the flex-oem-compiler project.  You
>>should
>> be able to follow what I did in git history and get an idea of what you
>> need to change, but there is one possible gotcha:  FB runs in Java 6
>>and I
>> believe GCC required Java 7.  I'm not sure if there is a way to have
>>FB's
>> Java 6 call into GCC without recompiling GCC to Java 6 (which is an
>>option
>> I think).
>>
>
>The idea is to change nothing to the FB workflow, just add an External
>Tool
>option to publish an existing project to JavaScript. I hope, since the aim
>is to have 'vanilla' SWF development, that we can make this project part
>of
>the regular SDK, not a separate release. Also, I figure that another
>subproject that needs a release cycle etc. might very well break Apache
>Flex due to release overload.
>
>But we're not there yet, so, first things first: a nice proof of concept
>and some thinking on how we can best make this work from a user's point of
>view.
>
>Thanks,
>
>EdB
>
>
>
>-- 
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl

Re: New Flex to JS project

[Erik de Bruin <er...@ixsoftware.nl>]

>
> Sounds interesting.  Is there any way to get more information on what
> kinds of changes are going to be made?  More comments in-line.
>

I'm basically making this up as I go along, but... The workflow for
producing SWFs doesn't change at all. Hence 'Vanilla Flex'. If someone
wants to publish his normal Flex project to JavaScript, he uses an External
Tool to launch FalconJX with the vanilla Flex project as input. In order to
give the user feedback on which components and properties on components are
supported by the JS framework, the Flex SDK gets two new namespaces with
accompanying shim components. The shims will contain only the public APIs
supported by the JS framework. These namespaces will be 'swapped in' by
FalconJX during a publish to JS. I plan to have the compiler produce a nice
full AST or give the user feedback about stuff it cannot 'translate'
because the shim components don't allow complete compilation due to the use
of unsupported properties. From the AST, I plan to use all I learned
writing FalconJX for FlexJS and using the GC Tools daily for over a year
now, and produce very GCC friendly JavaScript.

>1) two new namespaces and accompanying projects in the main Flex SDK:
> >vf2js_mx and vf2js_s. These namespaces will contain shim objects for (you
> >guessed it) MX and Spark components.
> Just wondering after seeing all the branch/merge discussion: are you sure
> you can't auto-generate the shims via a custom back-end for FalconJX?  It
> could suck in your JS files as well if that helps to compute the shim.
> Then you may not need to branch/merge at all and just be a separate swc
> project or two (or three).
>

I have two new projects in 'sdk/frameworks/projects', and I've changed the
supporting files to build them with the SDK. There are relatively few
changes in the SDK, apart from those new swc projects. I was told to
branch, and I did because I'm not sure if the changes I made to the
supporting config files are correct. When I have a working prototype, and
my branched SDK passes all Mustella tests, I'll start asking permission to
merge it back into 'develop'. The new stuff doesn't touch any of the
existing stuff, so I'm not expecting any problems on that front.

>2) two new code paths in FalconJX: one for AS and one for MXML
> If the changes going in here are not going to interfere with FlexJS, I
> don't see why you need to branch now.  FlexJS is in alpha, so having other
> alpha/prototype code in its release shouldn't be a killer.


I decided to branch this project because I expect not to be able to leave
the FalconJX in a functioning state after each and every commit. I don't
want to bother anyone with my half backed experiments, let alone break the
nightly builds.


> >B - In order for this to work, FalconJX needs to be part of the regular
> >SDK
> >distribution. Folks who did this on the FlexJS overlay: what does it take
> >to make FalconJX part of the SDK?
>
> I'm not quite sure what this means.  Why can't it be an overlay?  If Chris
> is right and you want FB integration such that building the FB project
> runs FalconJX, that part is in the flex-oem-compiler project.  You should
> be able to follow what I did in git history and get an idea of what you
> need to change, but there is one possible gotcha:  FB runs in Java 6 and I
> believe GCC required Java 7.  I'm not sure if there is a way to have FB's
> Java 6 call into GCC without recompiling GCC to Java 6 (which is an option
> I think).
>

The idea is to change nothing to the FB workflow, just add an External Tool
option to publish an existing project to JavaScript. I hope, since the aim
is to have 'vanilla' SWF development, that we can make this project part of
the regular SDK, not a separate release. Also, I figure that another
subproject that needs a release cycle etc. might very well break Apache
Flex due to release overload.

But we're not there yet, so, first things first: a nice proof of concept
and some thinking on how we can best make this work from a user's point of
view.

Thanks,

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

Re: New Flex to JS project

[Alex Harui <ah...@adobe.com>]

Sounds interesting.  Is there any way to get more information on what
kinds of changes are going to be made?  More comments in-line.

On 7/2/14 12:33 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:

>Hi,
>
>I'm working on creating a way to publish vanilla Flex SDK projects to
>JavaScript on latest gen browsers. This project consists of several sub
>projects, and I'm wondering what is the best way forward with regard to
>contributing them:
>
>1) two new namespaces and accompanying projects in the main Flex SDK:
>vf2js_mx and vf2js_s. These namespaces will contain shim objects for (you
>guessed it) MX and Spark components.
Just wondering after seeing all the branch/merge discussion: are you sure
you can't auto-generate the shims via a custom back-end for FalconJX?  It
could suck in your JS files as well if that helps to compute the shim.
Then you may not need to branch/merge at all and just be a separate swc
project or two (or three).

>
>2) two new code paths in FalconJX: one for AS and one for MXML
If the changes going in here are not going to interfere with FlexJS, I
don't see why you need to branch now.  FlexJS is in alpha, so having other
alpha/prototype code in its release shouldn't be a killer.

>
>3) a new JavaScript library for the components and shims for AS classes
>
>4) a testing framework for the JS components, loosely based on Marmotinni
>
>Questions:
>
>A - I would very much like to work in the 'develop' branches of the
>projects involved, but especially on the part of '1)' I'm not sure if I
>did
>it right. All tests I can think of seem to pass, but maybe someone has the
>time to do a code review on a branch that I can publish?
>
>B - In order for this to work, FalconJX needs to be part of the regular
>SDK
>distribution. Folks who did this on the FlexJS overlay: what does it take
>to make FalconJX part of the SDK?

I'm not quite sure what this means.  Why can't it be an overlay?  If Chris
is right and you want FB integration such that building the FB project
runs FalconJX, that part is in the flex-oem-compiler project.  You should
be able to follow what I did in git history and get an idea of what you
need to change, but there is one possible gotcha:  FB runs in Java 6 and I
believe GCC required Java 7.  I'm not sure if there is a way to have FB's
Java 6 call into GCC without recompiling GCC to Java 6 (which is an option
I think).

HTH,
-Alex