You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@flex.apache.org by OmPrakash Muppirala <bi...@gmail.com> on 2016/01/05 01:09:44 UTC

Bug in mxmlc script

In the flexjs/js/bin/mxmlc script, I see that we are referencing the '
*/frameworks/js/FlexJS/src*' folder.

java $VMARGS $D32 $SETUP_SH_VMARGS -Dflexcompiler="$FALCON_HOME"
-Dflexlib="$FLEX_HOME/frameworks" -jar "$SCRIPT_HOME/../lib/mxmlc.jar"
+flexlib="$FLEX_HOME/frameworks" -js-output-type=FLEXJS*
-sdk-js-lib="$FLEX_HOME/frameworks/js/FlexJS/src"* "$@"

 But this folder does not come with the release build of FlexJS.  This is
causing the build using mxmlc to fail.

I was able to fix it by doing what asjsc does, i.e. adding '
*-external-library-path="$SCRIPT_HOME/../libs/js.swc"*'.  This seems to fix
the build issue with mxmlc.

So, is it okay to change the script to look like this?

java $VMARGS $D32 $SETUP_SH_VMARGS -Dflexcompiler="$FALCON_HOME"
-Dflexlib="$FLEX_HOME/frameworks" -jar "$SCRIPT_HOME/../lib/mxmlc.jar"
+flexlib="$FLEX_HOME/frameworks" -js-output-type=FLEXJS
-sdk-js-lib="$FLEX_HOME/frameworks/js/FlexJS/src"
*-external-library-path="$SCRIPT_HOME/../libs/js.swc"
*"$@"

Thanks,
Om

Re: Bug in mxmlc script

Posted by Alex Harui <ah...@adobe.com>.

On 1/4/16, 5:14 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
<omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:

>On Mon, Jan 4, 2016 at 4:47 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> If you diff asjsc vs mxmlc you'll see the difference.
>>
>
>This is the difference I see:
>
>asjsc:   -js-output-type=jsc
>-external-library-path="$SCRIPT_HOME/../libs/js.swc"
>mxmlc: -js-output-type=FLEXJS
>-sdk-js-lib="$FLEX_HOME/frameworks/js/FlexJS/src"
>
>
>So, -js-output-type=FLEXJS instead of jsc should do the trick of creating
>the index.html file?
>

Yes.

>
>> IMO, I wouldn't call a new script mxmlcnpm because others may want an
>>auto
>> generated hmtl as well.  Give it a more generic name.
>>
>
>Here are the current use cases:
>
>1.  Convert AS3 (targeting HTML DOM) to JS -> use asjsc
>2.  Convert AS3 + MXML (targeting FlexJS) to JS + HTML > use mxmlc
>
>The use case we need to add is
>Convert AS3 (targeting HTML DOM) to JS + HTML
>
>Something like asjshtmlc?  In that case, shouldn't mxmlc be renamed to
>mxmlcjshtmlc as well, for the sake of consistency?
>
>Or am I overthinking this?  What would you suggest?

Another option is to add a flag to asjsc script to dictate whether to
generate the HTML or not.

Yet another option is to set up different -config.xml files and have folks
specify that somehow.

Keep in mind that folks wanting to target Jquery or CreateJS need to use
those SWCs as external libraries as well.  It might be better to just
document how to pass in the SWCs

I don't have a great idea for this problem.

-Alex

Re: Bug in mxmlc script

Posted by jude <fl...@gmail.com>.

I use FB for browser based apps but I dislike how it overwrites the
template when switching SDK versions. IIRC FB hard codes the template to
"index.template.html". So it always gets overwritten. I think it should
come with a default template file but let you specify your own template
through a compiler argument.



On Mon, Jan 4, 2016 at 8:49 PM, Alex Harui <ah...@adobe.com> wrote:

> Well, the compiler could be upgraded to process a template like Flash
> Builder currently does.  I'm curious to know how many folks use Flash
> Builder and/or Ant tasks to process the html templates for SWFs vs
> plugging in some custom thing in their workflow.
>
> But IMO, the main reason to have an option is so folks can save a step in
> getting the SDK and trying it out.
>
> -Alex
>
> On 1/4/16, 7:56 PM, "Josh Tynjala" <jo...@gmail.com> wrote:
>
> >I should add that I'm not opposed to adding some kind of optional flag to
> >asjsc that tells it to generate an HTML file similar to how mxmlc does it.
> >That HTML file just doesn't seem especially useful to me, as I consider
> >what it would be like to use asjsc in a real-world project. So I'm trying
> >to get a better understanding of your perspective.
> >
> >- Josh
> >
> >On Mon, Jan 4, 2016 at 7:49 PM, Josh Tynjala <jo...@gmail.com>
> >wrote:
> >
> >> Is it actually necessary for the compiler to create some kind of
> >> boilerplate HTML for you? It may be a little useful for quick demos,
> >>I'll
> >> concede, but many real world projects will need highly customized HTML
> >> files. Many need things like analytics, CSS, and other static HTML
> >>content
> >> that isn't purely generated by JavaScript (for SEO and things).
> >>
> >> In fact, the compiler isn't really set up for customizing the HTML that
> >>it
> >> currently generates with mxmlc. You can see it is mostly hard-coded in
> >> JSGoogPublisher.java. It's actually very simple markup. Probably too
> >>simple
> >> to use in production for most people, especially if they want to use
> >>asjsc
> >> and integrate it into the rest of their web development workflow.
> >>
> >> - Josh
> >>
> >> On Mon, Jan 4, 2016 at 5:14 PM, OmPrakash Muppirala
> >><bi...@gmail.com>
> >> wrote:
> >>
> >>> On Mon, Jan 4, 2016 at 4:47 PM, Alex Harui <ah...@adobe.com> wrote:
> >>>
> >>> > If you diff asjsc vs mxmlc you'll see the difference.
> >>> >
> >>>
> >>> This is the difference I see:
> >>>
> >>> asjsc:   -js-output-type=jsc
> >>> -external-library-path="$SCRIPT_HOME/../libs/js.swc"
> >>> mxmlc: -js-output-type=FLEXJS
> >>> -sdk-js-lib="$FLEX_HOME/frameworks/js/FlexJS/src"
> >>>
> >>>
> >>> So, -js-output-type=FLEXJS instead of jsc should do the trick of
> >>>creating
> >>> the index.html file?
> >>>
> >>>
> >>> > IMO, I wouldn't call a new script mxmlcnpm because others may want an
> >>> auto
> >>> > generated hmtl as well.  Give it a more generic name.
> >>> >
> >>>
> >>> Here are the current use cases:
> >>>
> >>> 1.  Convert AS3 (targeting HTML DOM) to JS -> use asjsc
> >>> 2.  Convert AS3 + MXML (targeting FlexJS) to JS + HTML > use mxmlc
> >>>
> >>> The use case we need to add is
> >>> Convert AS3 (targeting HTML DOM) to JS + HTML
> >>>
> >>> Something like asjshtmlc?  In that case, shouldn't mxmlc be renamed to
> >>> mxmlcjshtmlc as well, for the sake of consistency?
> >>>
> >>> Or am I overthinking this?  What would you suggest?
> >>>
> >>> Thanks,
> >>> Om
> >>>
> >>>
> >>> >
> >>> > -Alex
> >>> >
> >>> > On 1/4/16, 4:28 PM, "omuppi1@gmail.com on behalf of OmPrakash
> >>> Muppirala"
> >>> > <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
> >>> >
> >>> > >I think I get it.
> >>> > >
> >>> > >I thought that the source code for js.swc was in
> >>> > >$FLEX_HOME/frameworks/js/FlexJS/src.
> >>> > >I guess that is not true?
> >>> > >
> >>> > >The original problem was that asjsc does not create the index.html
> >>> file.
> >>> > >I
> >>> > >was asked to use mxmlc for that.  (Refer to the npm install flexjs
> >>> thread)
> >>> > >
> >>> > >When I used the script in {installed_flexjs}/js/bin/mxmlc, it blew
> >>>up
> >>> > >because it could not find the definitions for HTMLElement,
> >>>SVGElement
> >>> etc.
> >>> > >because they are in js.swc.  I don't think it blew up because of the
> >>> > >missing /frameworks/js/FlexJS/src folder.  Adding the external
> >>>library
> >>> > >path
> >>> > >to js.swc fixed this issue.
> >>> > >
> >>> > >The way I did this was to create a new mxmlcnpm script and add this
> >>> js.swc
> >>> > >library path in that.  Is that okay?
> >>> > >
> >>> > >I guess another question is: what would be the best way to add
> >>>ability
> >>> to
> >>> > >create index.html capability to asjsc?
> >>> > >
> >>> > >Thanks,
> >>> > >Om
> >>> > >
> >>> > >
> >>> > >On Mon, Jan 4, 2016 at 4:16 PM, Alex Harui <ah...@adobe.com>
> wrote:
> >>> > >
> >>> > >>
> >>> > >>
> >>> > >> On 1/4/16, 4:09 PM, "omuppi1@gmail.com on behalf of OmPrakash
> >>> > Muppirala"
> >>> > >> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
> >>> > >>
> >>> > >> >In the flexjs/js/bin/mxmlc script, I see that we are referencing
> >>> the '
> >>> > >> >*/frameworks/js/FlexJS/src*' folder.
> >>> > >>
> >>> > >> This folder is intended as the place for folks to put
> >>>monkey-patched
> >>> JS
> >>> > >> files so they can override the JS in the SWCs if they need to
> >>> > >>workaround a
> >>> > >> bug.
> >>> > >>
> >>> > >> What code blew up?  Maybe we should create an empty folder there
> >>>or
> >>> make
> >>> > >> the compiler tolerant of it not being there.
> >>> > >>
> >>> > >> Trying to use js.swc with MXMLC is not currently the common
> >>> > >>configuration
> >>> > >> for FlexJS.  Most folks who are using MXML and AS to build a
> >>>FlexJS
> >>> app
> >>> > >> shouldn't need to write directly the the JS API especially if they
> >>> want
> >>> > >>to
> >>> > >> use a SWF version for testing and/or deployment.
> >>> > >>
> >>> > >> If you want to build out a different script for folks to use to
> >>>build
> >>> > >> native apps, feel free to do that.
> >>> > >>
> >>> > >> -Aleex
> >>> > >>
> >>> > >>
> >>> >
> >>> >
> >>>
> >>
> >>
>
>

Re: Bug in mxmlc script

Posted by OmPrakash Muppirala <bi...@gmail.com>.

Ah, I see what's happening.  If I change the SDK by selecting 'Use a
specific SDK', it warns me about overwriting the html-template files.  But,
if I keep the 'Use default SDK' but change the default SDK in the
'Configurie Flex SDK's screen, then there is no such warnings.  The new
default SDK is immediately applied to all the projects in my workspace.
Everything else is intact.

Thanks,
Om

On Mon, Jan 11, 2016 at 11:52 PM, OmPrakash Muppirala <bi...@gmail.com>
wrote:

> On Mon, Jan 11, 2016 at 11:11 PM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>> On 1/5/16, 1:07 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
>> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>>
>> >On Tue, Jan 5, 2016 at 10:12 AM, Alex Harui <ah...@adobe.com> wrote:
>> >>
>> >> IIRC, if you change SDKs, it will copy the index.template.html file
>> from
>> >> the SDK folder.
>> >>
>> >
>> >I don't think so.  I've changed SDKs for a project several times; I never
>> >had to redo the customizations I had done on index.html.template.  At
>> >least
>> >FlashBuilder behaves this way.
>>
>> I was just switching FlexJS SDKs for a project in FB (on Mac).  (Project
>> menu, Properties, Flex Compiler, "Use a specific SDK").  Upon hitting OK,
>> I get the following alert "Warning. Because you have changed the options
>> for the HTML wrapper or the SDK version, all files in the "html-template"
>> folder of your project will be overwritten and/or deleted."
>>
>> Does this not happen to you?
>>
>>
> No, I don't recall seeing that message for a while.  What version of FB
> are you using?
>
> Thanks,
> Om
>
>
>> Thanks,
>> -Alex
>>
>>
>

Re: Bug in mxmlc script

Posted by OmPrakash Muppirala <bi...@gmail.com>.

On Mon, Jan 11, 2016 at 11:11 PM, Alex Harui <ah...@adobe.com> wrote:

>
>
> On 1/5/16, 1:07 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>
> >On Tue, Jan 5, 2016 at 10:12 AM, Alex Harui <ah...@adobe.com> wrote:
> >>
> >> IIRC, if you change SDKs, it will copy the index.template.html file from
> >> the SDK folder.
> >>
> >
> >I don't think so.  I've changed SDKs for a project several times; I never
> >had to redo the customizations I had done on index.html.template.  At
> >least
> >FlashBuilder behaves this way.
>
> I was just switching FlexJS SDKs for a project in FB (on Mac).  (Project
> menu, Properties, Flex Compiler, "Use a specific SDK").  Upon hitting OK,
> I get the following alert "Warning. Because you have changed the options
> for the HTML wrapper or the SDK version, all files in the "html-template"
> folder of your project will be overwritten and/or deleted."
>
> Does this not happen to you?
>
>
No, I don't recall seeing that message for a while.  What version of FB are
you using?

Thanks,
Om


> Thanks,
> -Alex
>
>

Re: Bug in mxmlc script

Posted by Alex Harui <ah...@adobe.com>.

On 1/5/16, 1:07 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
<omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:

>On Tue, Jan 5, 2016 at 10:12 AM, Alex Harui <ah...@adobe.com> wrote:
>>
>> IIRC, if you change SDKs, it will copy the index.template.html file from
>> the SDK folder.
>>
>
>I don't think so.  I've changed SDKs for a project several times; I never
>had to redo the customizations I had done on index.html.template.  At
>least
>FlashBuilder behaves this way.

I was just switching FlexJS SDKs for a project in FB (on Mac).  (Project
menu, Properties, Flex Compiler, "Use a specific SDK").  Upon hitting OK,
I get the following alert "Warning. Because you have changed the options
for the HTML wrapper or the SDK version, all files in the "html-template"
folder of your project will be overwritten and/or deleted."

Does this not happen to you?

Thanks,
-Alex

Re: Bug in mxmlc script

Posted by OmPrakash Muppirala <bi...@gmail.com>.

On Tue, Jan 5, 2016 at 10:12 AM, Alex Harui <ah...@adobe.com> wrote:

>
>
> On 1/5/16, 9:49 AM, "Harbs" <ha...@gmail.com> wrote:
>
> >
> >On Jan 5, 2016, at 7:05 PM, OmPrakash Muppirala <bi...@gmail.com>
> >wrote:
> >
> >>
> >> I don't understand.   If you customize your index.html.template, how
> >>does
> >> it matter if the app.html file gets destroyed and recreated each time?
> >> This is how I have it setup.
> >
> >I don’t remember. Possibly I did things wrong in the past. I have never
> >spent a lot of time on the template files because the standard one
> >usually was enough for my testing purposes and I never push up the
> >generated HTML file to the server.
>
> IIRC, if you change SDKs, it will copy the index.template.html file from
> the SDK folder.
>

I don't think so.  I've changed SDKs for a project several times; I never
had to redo the customizations I had done on index.html.template.  At least
FlashBuilder behaves this way.


>
> -Alex
>
>

Re: Bug in mxmlc script

Posted by Alex Harui <ah...@adobe.com>.


On 1/5/16, 9:49 AM, "Harbs" <ha...@gmail.com> wrote:

>
>On Jan 5, 2016, at 7:05 PM, OmPrakash Muppirala <bi...@gmail.com>
>wrote:
>
>> 
>> I don't understand.   If you customize your index.html.template, how
>>does
>> it matter if the app.html file gets destroyed and recreated each time?
>> This is how I have it setup.
>
>I don’t remember. Possibly I did things wrong in the past. I have never
>spent a lot of time on the template files because the standard one
>usually was enough for my testing purposes and I never push up the
>generated HTML file to the server.

IIRC, if you change SDKs, it will copy the index.template.html file from
the SDK folder.

-Alex

Re: Bug in mxmlc script

Posted by Harbs <ha...@gmail.com>.

On Jan 5, 2016, at 7:05 PM, OmPrakash Muppirala <bi...@gmail.com> wrote:

> 
> I don't understand.   If you customize your index.html.template, how does
> it matter if the app.html file gets destroyed and recreated each time?
> This is how I have it setup.

I don’t remember. Possibly I did things wrong in the past. I have never spent a lot of time on the template files because the standard one usually was enough for my testing purposes and I never push up the generated HTML file to the server.

> I think a template is better for this purpose.

That’ll work too.

Re: Bug in mxmlc script

Posted by OmPrakash Muppirala <bi...@gmail.com>.

On Jan 5, 2016 3:03 AM, "Harbs" <ha...@gmail.com> wrote:
>
> It’s not just for instant gratification. (and I do agree that first
impressions are really important)
>
> In the ideal world, the template HTML file can be modified. The primary
reason I have not historically modified the HTML template file is because
cleaning a project (which I do regularly in Flash Builder) destroys the
HTML file and rebuilds it.

I don't understand.   If you customize your index.html.template, how does
it matter if the app.html file gets destroyed and recreated each time?
This is how I have it setup.

>
> Besides for first impressions, the HTML file is important for one-click
testing of the functionality. Yeah. For production, you’re going to have a
custom HTML file around it, but a default one is generally useful for
testing.
>
> Ideally, if there is no HTML file, one will be created, but if the HTML
file already exists, it will not be overwritten.

I think a template is better for this purpose.

Thanks,
Om

>
> On Jan 5, 2016, at 11:15 AM, OmPrakash Muppirala <bi...@gmail.com>
wrote:
>
> > On Mon, Jan 4, 2016 at 8:49 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> Well, the compiler could be upgraded to process a template like Flash
> >> Builder currently does.  I'm curious to know how many folks use Flash
> >> Builder and/or Ant tasks to process the html templates for SWFs vs
> >> plugging in some custom thing in their workflow.
> >>
> >
> > I remember in Flex 2 days where it was very cool to quickly write some
code
> > and hit the run button and see the browser pop-up with the app.  That
made
> > for a very good first impression.  If we don't have a quick way to
visually
> > see the JS code that got generated, there is not much of a first
> > impression, IMHO.
> >
> > Also, it is not very obvious that we need to create a html file with a
new
> > MainClass.start() on body load.  And it seems like we are
> > using goog.addDependency calls to load the required Javascript files.
Do
> > we really expect the users to handcraft this everytime?  That could be
tons
> > of JS files to be added by hand.  Kind of defeats the purpose of having
a
> > transpiler.
> >
> > That said, it will become annoying very quickly when one realizes that
the
> > index.html cannot be changed.
> >
> > I think having a very simple html file as a default template is a happy
> > medium.  It works for the instant gratification that new users would
seek
> > and more advanced users can dig in a bit deeper and swap out the default
> > with a custom template.
> >
> > Thanks,
> > Om
> >
> >
> >>
> >> But IMO, the main reason to have an option is so folks can save a step
in
> >> getting the SDK and trying it out.
> >>
> >> -Alex
> >>
> >> On 1/4/16, 7:56 PM, "Josh Tynjala" <jo...@gmail.com> wrote:
> >>
> >>> I should add that I'm not opposed to adding some kind of optional
flag to
> >>> asjsc that tells it to generate an HTML file similar to how mxmlc
does it.
> >>> That HTML file just doesn't seem especially useful to me, as I
consider
> >>> what it would be like to use asjsc in a real-world project. So I'm
trying
> >>> to get a better understanding of your perspective.
> >>>
> >>> - Josh
> >>>
> >>> On Mon, Jan 4, 2016 at 7:49 PM, Josh Tynjala <jo...@gmail.com>
> >>> wrote:
> >>>
> >>>> Is it actually necessary for the compiler to create some kind of
> >>>> boilerplate HTML for you? It may be a little useful for quick demos,
> >>>> I'll
> >>>> concede, but many real world projects will need highly customized
HTML
> >>>> files. Many need things like analytics, CSS, and other static HTML
> >>>> content
> >>>> that isn't purely generated by JavaScript (for SEO and things).
> >>>>
> >>>> In fact, the compiler isn't really set up for customizing the HTML
that
> >>>> it
> >>>> currently generates with mxmlc. You can see it is mostly hard-coded
in
> >>>> JSGoogPublisher.java. It's actually very simple markup. Probably too
> >>>> simple
> >>>> to use in production for most people, especially if they want to use
> >>>> asjsc
> >>>> and integrate it into the rest of their web development workflow.
> >>>>
> >>>> - Josh
> >>>>
> >>>> On Mon, Jan 4, 2016 at 5:14 PM, OmPrakash Muppirala
> >>>> <bi...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> On Mon, Jan 4, 2016 at 4:47 PM, Alex Harui <ah...@adobe.com> wrote:
> >>>>>
> >>>>>> If you diff asjsc vs mxmlc you'll see the difference.
> >>>>>>
> >>>>>
> >>>>> This is the difference I see:
> >>>>>
> >>>>> asjsc:   -js-output-type=jsc
> >>>>> -external-library-path="$SCRIPT_HOME/../libs/js.swc"
> >>>>> mxmlc: -js-output-type=FLEXJS
> >>>>> -sdk-js-lib="$FLEX_HOME/frameworks/js/FlexJS/src"
> >>>>>
> >>>>>
> >>>>> So, -js-output-type=FLEXJS instead of jsc should do the trick of
> >>>>> creating
> >>>>> the index.html file?
> >>>>>
> >>>>>
> >>>>>> IMO, I wouldn't call a new script mxmlcnpm because others may want
an
> >>>>> auto
> >>>>>> generated hmtl as well.  Give it a more generic name.
> >>>>>>
> >>>>>
> >>>>> Here are the current use cases:
> >>>>>
> >>>>> 1.  Convert AS3 (targeting HTML DOM) to JS -> use asjsc
> >>>>> 2.  Convert AS3 + MXML (targeting FlexJS) to JS + HTML > use mxmlc
> >>>>>
> >>>>> The use case we need to add is
> >>>>> Convert AS3 (targeting HTML DOM) to JS + HTML
> >>>>>
> >>>>> Something like asjshtmlc?  In that case, shouldn't mxmlc be renamed
to
> >>>>> mxmlcjshtmlc as well, for the sake of consistency?
> >>>>>
> >>>>> Or am I overthinking this?  What would you suggest?
> >>>>>
> >>>>> Thanks,
> >>>>> Om
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> -Alex
> >>>>>>
> >>>>>> On 1/4/16, 4:28 PM, "omuppi1@gmail.com on behalf of OmPrakash
> >>>>> Muppirala"
> >>>>>> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
> >>>>>>
> >>>>>>> I think I get it.
> >>>>>>>
> >>>>>>> I thought that the source code for js.swc was in
> >>>>>>> $FLEX_HOME/frameworks/js/FlexJS/src.
> >>>>>>> I guess that is not true?
> >>>>>>>
> >>>>>>> The original problem was that asjsc does not create the index.html
> >>>>> file.
> >>>>>>> I
> >>>>>>> was asked to use mxmlc for that.  (Refer to the npm install flexjs
> >>>>> thread)
> >>>>>>>
> >>>>>>> When I used the script in {installed_flexjs}/js/bin/mxmlc, it blew
> >>>>> up
> >>>>>>> because it could not find the definitions for HTMLElement,
> >>>>> SVGElement
> >>>>> etc.
> >>>>>>> because they are in js.swc.  I don't think it blew up because of
the
> >>>>>>> missing /frameworks/js/FlexJS/src folder.  Adding the external
> >>>>> library
> >>>>>>> path
> >>>>>>> to js.swc fixed this issue.
> >>>>>>>
> >>>>>>> The way I did this was to create a new mxmlcnpm script and add
this
> >>>>> js.swc
> >>>>>>> library path in that.  Is that okay?
> >>>>>>>
> >>>>>>> I guess another question is: what would be the best way to add
> >>>>> ability
> >>>>> to
> >>>>>>> create index.html capability to asjsc?
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Om
> >>>>>>>
> >>>>>>>
> >>>>>>> On Mon, Jan 4, 2016 at 4:16 PM, Alex Harui <ah...@adobe.com>
> >> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 1/4/16, 4:09 PM, "omuppi1@gmail.com on behalf of OmPrakash
> >>>>>> Muppirala"
> >>>>>>>> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>>> In the flexjs/js/bin/mxmlc script, I see that we are referencing
> >>>>> the '
> >>>>>>>>> */frameworks/js/FlexJS/src*' folder.
> >>>>>>>>
> >>>>>>>> This folder is intended as the place for folks to put
> >>>>> monkey-patched
> >>>>> JS
> >>>>>>>> files so they can override the JS in the SWCs if they need to
> >>>>>>>> workaround a
> >>>>>>>> bug.
> >>>>>>>>
> >>>>>>>> What code blew up?  Maybe we should create an empty folder there
> >>>>> or
> >>>>> make
> >>>>>>>> the compiler tolerant of it not being there.
> >>>>>>>>
> >>>>>>>> Trying to use js.swc with MXMLC is not currently the common
> >>>>>>>> configuration
> >>>>>>>> for FlexJS.  Most folks who are using MXML and AS to build a
> >>>>> FlexJS
> >>>>> app
> >>>>>>>> shouldn't need to write directly the the JS API especially if
they
> >>>>> want
> >>>>>>>> to
> >>>>>>>> use a SWF version for testing and/or deployment.
> >>>>>>>>
> >>>>>>>> If you want to build out a different script for folks to use to
> >>>>> build
> >>>>>>>> native apps, feel free to do that.
> >>>>>>>>
> >>>>>>>> -Aleex
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >>
>

Re: Bug in mxmlc script

Posted by Harbs <ha...@gmail.com>.

It’s not just for instant gratification. (and I do agree that first impressions are really important)

In the ideal world, the template HTML file can be modified. The primary reason I have not historically modified the HTML template file is because cleaning a project (which I do regularly in Flash Builder) destroys the HTML file and rebuilds it.

Besides for first impressions, the HTML file is important for one-click testing of the functionality. Yeah. For production, you’re going to have a custom HTML file around it, but a default one is generally useful for testing.

Ideally, if there is no HTML file, one will be created, but if the HTML file already exists, it will not be overwritten.
 
On Jan 5, 2016, at 11:15 AM, OmPrakash Muppirala <bi...@gmail.com> wrote:

> On Mon, Jan 4, 2016 at 8:49 PM, Alex Harui <ah...@adobe.com> wrote:
> 
>> Well, the compiler could be upgraded to process a template like Flash
>> Builder currently does.  I'm curious to know how many folks use Flash
>> Builder and/or Ant tasks to process the html templates for SWFs vs
>> plugging in some custom thing in their workflow.
>> 
> 
> I remember in Flex 2 days where it was very cool to quickly write some code
> and hit the run button and see the browser pop-up with the app.  That made
> for a very good first impression.  If we don't have a quick way to visually
> see the JS code that got generated, there is not much of a first
> impression, IMHO.
> 
> Also, it is not very obvious that we need to create a html file with a new
> MainClass.start() on body load.  And it seems like we are
> using goog.addDependency calls to load the required Javascript files.  Do
> we really expect the users to handcraft this everytime?  That could be tons
> of JS files to be added by hand.  Kind of defeats the purpose of having a
> transpiler.
> 
> That said, it will become annoying very quickly when one realizes that the
> index.html cannot be changed.
> 
> I think having a very simple html file as a default template is a happy
> medium.  It works for the instant gratification that new users would seek
> and more advanced users can dig in a bit deeper and swap out the default
> with a custom template.
> 
> Thanks,
> Om
> 
> 
>> 
>> But IMO, the main reason to have an option is so folks can save a step in
>> getting the SDK and trying it out.
>> 
>> -Alex
>> 
>> On 1/4/16, 7:56 PM, "Josh Tynjala" <jo...@gmail.com> wrote:
>> 
>>> I should add that I'm not opposed to adding some kind of optional flag to
>>> asjsc that tells it to generate an HTML file similar to how mxmlc does it.
>>> That HTML file just doesn't seem especially useful to me, as I consider
>>> what it would be like to use asjsc in a real-world project. So I'm trying
>>> to get a better understanding of your perspective.
>>> 
>>> - Josh
>>> 
>>> On Mon, Jan 4, 2016 at 7:49 PM, Josh Tynjala <jo...@gmail.com>
>>> wrote:
>>> 
>>>> Is it actually necessary for the compiler to create some kind of
>>>> boilerplate HTML for you? It may be a little useful for quick demos,
>>>> I'll
>>>> concede, but many real world projects will need highly customized HTML
>>>> files. Many need things like analytics, CSS, and other static HTML
>>>> content
>>>> that isn't purely generated by JavaScript (for SEO and things).
>>>> 
>>>> In fact, the compiler isn't really set up for customizing the HTML that
>>>> it
>>>> currently generates with mxmlc. You can see it is mostly hard-coded in
>>>> JSGoogPublisher.java. It's actually very simple markup. Probably too
>>>> simple
>>>> to use in production for most people, especially if they want to use
>>>> asjsc
>>>> and integrate it into the rest of their web development workflow.
>>>> 
>>>> - Josh
>>>> 
>>>> On Mon, Jan 4, 2016 at 5:14 PM, OmPrakash Muppirala
>>>> <bi...@gmail.com>
>>>> wrote:
>>>> 
>>>>> On Mon, Jan 4, 2016 at 4:47 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>> 
>>>>>> If you diff asjsc vs mxmlc you'll see the difference.
>>>>>> 
>>>>> 
>>>>> This is the difference I see:
>>>>> 
>>>>> asjsc:   -js-output-type=jsc
>>>>> -external-library-path="$SCRIPT_HOME/../libs/js.swc"
>>>>> mxmlc: -js-output-type=FLEXJS
>>>>> -sdk-js-lib="$FLEX_HOME/frameworks/js/FlexJS/src"
>>>>> 
>>>>> 
>>>>> So, -js-output-type=FLEXJS instead of jsc should do the trick of
>>>>> creating
>>>>> the index.html file?
>>>>> 
>>>>> 
>>>>>> IMO, I wouldn't call a new script mxmlcnpm because others may want an
>>>>> auto
>>>>>> generated hmtl as well.  Give it a more generic name.
>>>>>> 
>>>>> 
>>>>> Here are the current use cases:
>>>>> 
>>>>> 1.  Convert AS3 (targeting HTML DOM) to JS -> use asjsc
>>>>> 2.  Convert AS3 + MXML (targeting FlexJS) to JS + HTML > use mxmlc
>>>>> 
>>>>> The use case we need to add is
>>>>> Convert AS3 (targeting HTML DOM) to JS + HTML
>>>>> 
>>>>> Something like asjshtmlc?  In that case, shouldn't mxmlc be renamed to
>>>>> mxmlcjshtmlc as well, for the sake of consistency?
>>>>> 
>>>>> Or am I overthinking this?  What would you suggest?
>>>>> 
>>>>> Thanks,
>>>>> Om
>>>>> 
>>>>> 
>>>>>> 
>>>>>> -Alex
>>>>>> 
>>>>>> On 1/4/16, 4:28 PM, "omuppi1@gmail.com on behalf of OmPrakash
>>>>> Muppirala"
>>>>>> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>>>>>> 
>>>>>>> I think I get it.
>>>>>>> 
>>>>>>> I thought that the source code for js.swc was in
>>>>>>> $FLEX_HOME/frameworks/js/FlexJS/src.
>>>>>>> I guess that is not true?
>>>>>>> 
>>>>>>> The original problem was that asjsc does not create the index.html
>>>>> file.
>>>>>>> I
>>>>>>> was asked to use mxmlc for that.  (Refer to the npm install flexjs
>>>>> thread)
>>>>>>> 
>>>>>>> When I used the script in {installed_flexjs}/js/bin/mxmlc, it blew
>>>>> up
>>>>>>> because it could not find the definitions for HTMLElement,
>>>>> SVGElement
>>>>> etc.
>>>>>>> because they are in js.swc.  I don't think it blew up because of the
>>>>>>> missing /frameworks/js/FlexJS/src folder.  Adding the external
>>>>> library
>>>>>>> path
>>>>>>> to js.swc fixed this issue.
>>>>>>> 
>>>>>>> The way I did this was to create a new mxmlcnpm script and add this
>>>>> js.swc
>>>>>>> library path in that.  Is that okay?
>>>>>>> 
>>>>>>> I guess another question is: what would be the best way to add
>>>>> ability
>>>>> to
>>>>>>> create index.html capability to asjsc?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Om
>>>>>>> 
>>>>>>> 
>>>>>>> On Mon, Jan 4, 2016 at 4:16 PM, Alex Harui <ah...@adobe.com>
>> wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 1/4/16, 4:09 PM, "omuppi1@gmail.com on behalf of OmPrakash
>>>>>> Muppirala"
>>>>>>>> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>>>>>>>> 
>>>>>>>>> In the flexjs/js/bin/mxmlc script, I see that we are referencing
>>>>> the '
>>>>>>>>> */frameworks/js/FlexJS/src*' folder.
>>>>>>>> 
>>>>>>>> This folder is intended as the place for folks to put
>>>>> monkey-patched
>>>>> JS
>>>>>>>> files so they can override the JS in the SWCs if they need to
>>>>>>>> workaround a
>>>>>>>> bug.
>>>>>>>> 
>>>>>>>> What code blew up?  Maybe we should create an empty folder there
>>>>> or
>>>>> make
>>>>>>>> the compiler tolerant of it not being there.
>>>>>>>> 
>>>>>>>> Trying to use js.swc with MXMLC is not currently the common
>>>>>>>> configuration
>>>>>>>> for FlexJS.  Most folks who are using MXML and AS to build a
>>>>> FlexJS
>>>>> app
>>>>>>>> shouldn't need to write directly the the JS API especially if they
>>>>> want
>>>>>>>> to
>>>>>>>> use a SWF version for testing and/or deployment.
>>>>>>>> 
>>>>>>>> If you want to build out a different script for folks to use to
>>>>> build
>>>>>>>> native apps, feel free to do that.
>>>>>>>> 
>>>>>>>> -Aleex
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>> 
>>

Re: Bug in mxmlc script

Posted by Josh Tynjala <jo...@gmail.com>.

I should add that a "main" class shouldn't necessarily be required to have
a static method as its entry point. A developer might prefer to instantiate
it with the constructor instead.

A FlexJS framework app can (and should!) be opinionated, but asjsc needs to
be flexible, as a more generic transpiler.

- Josh
On Jan 5, 2016 1:15 AM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:

> On Mon, Jan 4, 2016 at 8:49 PM, Alex Harui <ah...@adobe.com> wrote:
>
> > Well, the compiler could be upgraded to process a template like Flash
> > Builder currently does.  I'm curious to know how many folks use Flash
> > Builder and/or Ant tasks to process the html templates for SWFs vs
> > plugging in some custom thing in their workflow.
> >
>
> I remember in Flex 2 days where it was very cool to quickly write some code
> and hit the run button and see the browser pop-up with the app.  That made
> for a very good first impression.  If we don't have a quick way to visually
> see the JS code that got generated, there is not much of a first
> impression, IMHO.
>
> Also, it is not very obvious that we need to create a html file with a new
> MainClass.start() on body load.  And it seems like we are
> using goog.addDependency calls to load the required Javascript files.  Do
> we really expect the users to handcraft this everytime?  That could be tons
> of JS files to be added by hand.  Kind of defeats the purpose of having a
> transpiler.
>
> That said, it will become annoying very quickly when one realizes that the
> index.html cannot be changed.
>
> I think having a very simple html file as a default template is a happy
> medium.  It works for the instant gratification that new users would seek
> and more advanced users can dig in a bit deeper and swap out the default
> with a custom template.
>
> Thanks,
> Om
>
>
> >
> > But IMO, the main reason to have an option is so folks can save a step in
> > getting the SDK and trying it out.
> >
> > -Alex
> >
> > On 1/4/16, 7:56 PM, "Josh Tynjala" <jo...@gmail.com> wrote:
> >
> > >I should add that I'm not opposed to adding some kind of optional flag
> to
> > >asjsc that tells it to generate an HTML file similar to how mxmlc does
> it.
> > >That HTML file just doesn't seem especially useful to me, as I consider
> > >what it would be like to use asjsc in a real-world project. So I'm
> trying
> > >to get a better understanding of your perspective.
> > >
> > >- Josh
> > >
> > >On Mon, Jan 4, 2016 at 7:49 PM, Josh Tynjala <jo...@gmail.com>
> > >wrote:
> > >
> > >> Is it actually necessary for the compiler to create some kind of
> > >> boilerplate HTML for you? It may be a little useful for quick demos,
> > >>I'll
> > >> concede, but many real world projects will need highly customized HTML
> > >> files. Many need things like analytics, CSS, and other static HTML
> > >>content
> > >> that isn't purely generated by JavaScript (for SEO and things).
> > >>
> > >> In fact, the compiler isn't really set up for customizing the HTML
> that
> > >>it
> > >> currently generates with mxmlc. You can see it is mostly hard-coded in
> > >> JSGoogPublisher.java. It's actually very simple markup. Probably too
> > >>simple
> > >> to use in production for most people, especially if they want to use
> > >>asjsc
> > >> and integrate it into the rest of their web development workflow.
> > >>
> > >> - Josh
> > >>
> > >> On Mon, Jan 4, 2016 at 5:14 PM, OmPrakash Muppirala
> > >><bi...@gmail.com>
> > >> wrote:
> > >>
> > >>> On Mon, Jan 4, 2016 at 4:47 PM, Alex Harui <ah...@adobe.com> wrote:
> > >>>
> > >>> > If you diff asjsc vs mxmlc you'll see the difference.
> > >>> >
> > >>>
> > >>> This is the difference I see:
> > >>>
> > >>> asjsc:   -js-output-type=jsc
> > >>> -external-library-path="$SCRIPT_HOME/../libs/js.swc"
> > >>> mxmlc: -js-output-type=FLEXJS
> > >>> -sdk-js-lib="$FLEX_HOME/frameworks/js/FlexJS/src"
> > >>>
> > >>>
> > >>> So, -js-output-type=FLEXJS instead of jsc should do the trick of
> > >>>creating
> > >>> the index.html file?
> > >>>
> > >>>
> > >>> > IMO, I wouldn't call a new script mxmlcnpm because others may want
> an
> > >>> auto
> > >>> > generated hmtl as well.  Give it a more generic name.
> > >>> >
> > >>>
> > >>> Here are the current use cases:
> > >>>
> > >>> 1.  Convert AS3 (targeting HTML DOM) to JS -> use asjsc
> > >>> 2.  Convert AS3 + MXML (targeting FlexJS) to JS + HTML > use mxmlc
> > >>>
> > >>> The use case we need to add is
> > >>> Convert AS3 (targeting HTML DOM) to JS + HTML
> > >>>
> > >>> Something like asjshtmlc?  In that case, shouldn't mxmlc be renamed
> to
> > >>> mxmlcjshtmlc as well, for the sake of consistency?
> > >>>
> > >>> Or am I overthinking this?  What would you suggest?
> > >>>
> > >>> Thanks,
> > >>> Om
> > >>>
> > >>>
> > >>> >
> > >>> > -Alex
> > >>> >
> > >>> > On 1/4/16, 4:28 PM, "omuppi1@gmail.com on behalf of OmPrakash
> > >>> Muppirala"
> > >>> > <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
> > >>> >
> > >>> > >I think I get it.
> > >>> > >
> > >>> > >I thought that the source code for js.swc was in
> > >>> > >$FLEX_HOME/frameworks/js/FlexJS/src.
> > >>> > >I guess that is not true?
> > >>> > >
> > >>> > >The original problem was that asjsc does not create the index.html
> > >>> file.
> > >>> > >I
> > >>> > >was asked to use mxmlc for that.  (Refer to the npm install flexjs
> > >>> thread)
> > >>> > >
> > >>> > >When I used the script in {installed_flexjs}/js/bin/mxmlc, it blew
> > >>>up
> > >>> > >because it could not find the definitions for HTMLElement,
> > >>>SVGElement
> > >>> etc.
> > >>> > >because they are in js.swc.  I don't think it blew up because of
> the
> > >>> > >missing /frameworks/js/FlexJS/src folder.  Adding the external
> > >>>library
> > >>> > >path
> > >>> > >to js.swc fixed this issue.
> > >>> > >
> > >>> > >The way I did this was to create a new mxmlcnpm script and add
> this
> > >>> js.swc
> > >>> > >library path in that.  Is that okay?
> > >>> > >
> > >>> > >I guess another question is: what would be the best way to add
> > >>>ability
> > >>> to
> > >>> > >create index.html capability to asjsc?
> > >>> > >
> > >>> > >Thanks,
> > >>> > >Om
> > >>> > >
> > >>> > >
> > >>> > >On Mon, Jan 4, 2016 at 4:16 PM, Alex Harui <ah...@adobe.com>
> > wrote:
> > >>> > >
> > >>> > >>
> > >>> > >>
> > >>> > >> On 1/4/16, 4:09 PM, "omuppi1@gmail.com on behalf of OmPrakash
> > >>> > Muppirala"
> > >>> > >> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
> > >>> > >>
> > >>> > >> >In the flexjs/js/bin/mxmlc script, I see that we are
> referencing
> > >>> the '
> > >>> > >> >*/frameworks/js/FlexJS/src*' folder.
> > >>> > >>
> > >>> > >> This folder is intended as the place for folks to put
> > >>>monkey-patched
> > >>> JS
> > >>> > >> files so they can override the JS in the SWCs if they need to
> > >>> > >>workaround a
> > >>> > >> bug.
> > >>> > >>
> > >>> > >> What code blew up?  Maybe we should create an empty folder there
> > >>>or
> > >>> make
> > >>> > >> the compiler tolerant of it not being there.
> > >>> > >>
> > >>> > >> Trying to use js.swc with MXMLC is not currently the common
> > >>> > >>configuration
> > >>> > >> for FlexJS.  Most folks who are using MXML and AS to build a
> > >>>FlexJS
> > >>> app
> > >>> > >> shouldn't need to write directly the the JS API especially if
> they
> > >>> want
> > >>> > >>to
> > >>> > >> use a SWF version for testing and/or deployment.
> > >>> > >>
> > >>> > >> If you want to build out a different script for folks to use to
> > >>>build
> > >>> > >> native apps, feel free to do that.
> > >>> > >>
> > >>> > >> -Aleex
> > >>> > >>
> > >>> > >>
> > >>> >
> > >>> >
> > >>>
> > >>
> > >>
> >
> >
>

Re: Bug in mxmlc script

Posted by Josh Tynjala <jo...@gmail.com>.

asjsc does not generate an index.html file, so you must be looking at the
output of mxmlc.

Today, asjsc outputs a JS file that lists the dependencies, as I described.
They're the exact same addDependency() calls that you'd see in mxmlc's
index.html.

- Josh

On Tue, Jan 5, 2016 at 1:06 PM, OmPrakash Muppirala <bi...@gmail.com>
wrote:

> On Jan 5, 2016 9:36 AM, "Josh Tynjala" <jo...@gmail.com> wrote:
> >
> > asjsc still generates all of the addDependency() calls required for a
> debug
> > build. No hand crafting needed. It generates them in a JS file named
> > ProjectName-dependencies.js. Not coincidentally, that is the only JS file
> > that you need to reference in a script tag in your HTML when running the
> > debug build.
>
> I suppose it does not work that way today?  I see all individual calls
> loading each dependency in index.html.
>
> >
> > - Josh
> > On Jan 5, 2016 1:15 AM, "OmPrakash Muppirala" <bi...@gmail.com>
> wrote:
> >
> > > On Mon, Jan 4, 2016 at 8:49 PM, Alex Harui <ah...@adobe.com> wrote:
> > >
> > > > Well, the compiler could be upgraded to process a template like Flash
> > > > Builder currently does.  I'm curious to know how many folks use Flash
> > > > Builder and/or Ant tasks to process the html templates for SWFs vs
> > > > plugging in some custom thing in their workflow.
> > > >
> > >
> > > I remember in Flex 2 days where it was very cool to quickly write some
> code
> > > and hit the run button and see the browser pop-up with the app.  That
> made
> > > for a very good first impression.  If we don't have a quick way to
> visually
> > > see the JS code that got generated, there is not much of a first
> > > impression, IMHO.
> > >
> > > Also, it is not very obvious that we need to create a html file with a
> new
> > > MainClass.start() on body load.  And it seems like we are
> > > using goog.addDependency calls to load the required Javascript files.
> Do
> > > we really expect the users to handcraft this everytime?  That could be
> tons
> > > of JS files to be added by hand.  Kind of defeats the purpose of having
> a
> > > transpiler.
> > >
> > > That said, it will become annoying very quickly when one realizes that
> the
> > > index.html cannot be changed.
> > >
> > > I think having a very simple html file as a default template is a happy
> > > medium.  It works for the instant gratification that new users would
> seek
> > > and more advanced users can dig in a bit deeper and swap out the
> default
> > > with a custom template.
> > >
> > > Thanks,
> > > Om
> > >
> > >
> > > >
> > > > But IMO, the main reason to have an option is so folks can save a
> step in
> > > > getting the SDK and trying it out.
> > > >
> > > > -Alex
> > > >
> > > > On 1/4/16, 7:56 PM, "Josh Tynjala" <jo...@gmail.com> wrote:
> > > >
> > > > >I should add that I'm not opposed to adding some kind of optional
> flag
> > > to
> > > > >asjsc that tells it to generate an HTML file similar to how mxmlc
> does
> > > it.
> > > > >That HTML file just doesn't seem especially useful to me, as I
> consider
> > > > >what it would be like to use asjsc in a real-world project. So I'm
> > > trying
> > > > >to get a better understanding of your perspective.
> > > > >
> > > > >- Josh
> > > > >
> > > > >On Mon, Jan 4, 2016 at 7:49 PM, Josh Tynjala <joshtynjala@gmail.com
> >
> > > > >wrote:
> > > > >
> > > > >> Is it actually necessary for the compiler to create some kind of
> > > > >> boilerplate HTML for you? It may be a little useful for quick
> demos,
> > > > >>I'll
> > > > >> concede, but many real world projects will need highly customized
> HTML
> > > > >> files. Many need things like analytics, CSS, and other static HTML
> > > > >>content
> > > > >> that isn't purely generated by JavaScript (for SEO and things).
> > > > >>
> > > > >> In fact, the compiler isn't really set up for customizing the HTML
> > > that
> > > > >>it
> > > > >> currently generates with mxmlc. You can see it is mostly
> hard-coded in
> > > > >> JSGoogPublisher.java. It's actually very simple markup. Probably
> too
> > > > >>simple
> > > > >> to use in production for most people, especially if they want to
> use
> > > > >>asjsc
> > > > >> and integrate it into the rest of their web development workflow.
> > > > >>
> > > > >> - Josh
> > > > >>
> > > > >> On Mon, Jan 4, 2016 at 5:14 PM, OmPrakash Muppirala
> > > > >><bi...@gmail.com>
> > > > >> wrote:
> > > > >>
> > > > >>> On Mon, Jan 4, 2016 at 4:47 PM, Alex Harui <ah...@adobe.com>
> wrote:
> > > > >>>
> > > > >>> > If you diff asjsc vs mxmlc you'll see the difference.
> > > > >>> >
> > > > >>>
> > > > >>> This is the difference I see:
> > > > >>>
> > > > >>> asjsc:   -js-output-type=jsc
> > > > >>> -external-library-path="$SCRIPT_HOME/../libs/js.swc"
> > > > >>> mxmlc: -js-output-type=FLEXJS
> > > > >>> -sdk-js-lib="$FLEX_HOME/frameworks/js/FlexJS/src"
> > > > >>>
> > > > >>>
> > > > >>> So, -js-output-type=FLEXJS instead of jsc should do the trick of
> > > > >>>creating
> > > > >>> the index.html file?
> > > > >>>
> > > > >>>
> > > > >>> > IMO, I wouldn't call a new script mxmlcnpm because others may
> want
> > > an
> > > > >>> auto
> > > > >>> > generated hmtl as well.  Give it a more generic name.
> > > > >>> >
> > > > >>>
> > > > >>> Here are the current use cases:
> > > > >>>
> > > > >>> 1.  Convert AS3 (targeting HTML DOM) to JS -> use asjsc
> > > > >>> 2.  Convert AS3 + MXML (targeting FlexJS) to JS + HTML > use
> mxmlc
> > > > >>>
> > > > >>> The use case we need to add is
> > > > >>> Convert AS3 (targeting HTML DOM) to JS + HTML
> > > > >>>
> > > > >>> Something like asjshtmlc?  In that case, shouldn't mxmlc be
> renamed
> > > to
> > > > >>> mxmlcjshtmlc as well, for the sake of consistency?
> > > > >>>
> > > > >>> Or am I overthinking this?  What would you suggest?
> > > > >>>
> > > > >>> Thanks,
> > > > >>> Om
> > > > >>>
> > > > >>>
> > > > >>> >
> > > > >>> > -Alex
> > > > >>> >
> > > > >>> > On 1/4/16, 4:28 PM, "omuppi1@gmail.com on behalf of OmPrakash
> > > > >>> Muppirala"
> > > > >>> > <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
> > > > >>> >
> > > > >>> > >I think I get it.
> > > > >>> > >
> > > > >>> > >I thought that the source code for js.swc was in
> > > > >>> > >$FLEX_HOME/frameworks/js/FlexJS/src.
> > > > >>> > >I guess that is not true?
> > > > >>> > >
> > > > >>> > >The original problem was that asjsc does not create the
> index.html
> > > > >>> file.
> > > > >>> > >I
> > > > >>> > >was asked to use mxmlc for that.  (Refer to the npm install
> flexjs
> > > > >>> thread)
> > > > >>> > >
> > > > >>> > >When I used the script in {installed_flexjs}/js/bin/mxmlc, it
> blew
> > > > >>>up
> > > > >>> > >because it could not find the definitions for HTMLElement,
> > > > >>>SVGElement
> > > > >>> etc.
> > > > >>> > >because they are in js.swc.  I don't think it blew up because
> of
> > > the
> > > > >>> > >missing /frameworks/js/FlexJS/src folder.  Adding the external
> > > > >>>library
> > > > >>> > >path
> > > > >>> > >to js.swc fixed this issue.
> > > > >>> > >
> > > > >>> > >The way I did this was to create a new mxmlcnpm script and add
> > > this
> > > > >>> js.swc
> > > > >>> > >library path in that.  Is that okay?
> > > > >>> > >
> > > > >>> > >I guess another question is: what would be the best way to add
> > > > >>>ability
> > > > >>> to
> > > > >>> > >create index.html capability to asjsc?
> > > > >>> > >
> > > > >>> > >Thanks,
> > > > >>> > >Om
> > > > >>> > >
> > > > >>> > >
> > > > >>> > >On Mon, Jan 4, 2016 at 4:16 PM, Alex Harui <ah...@adobe.com>
> > > > wrote:
> > > > >>> > >
> > > > >>> > >>
> > > > >>> > >>
> > > > >>> > >> On 1/4/16, 4:09 PM, "omuppi1@gmail.com on behalf of
> OmPrakash
> > > > >>> > Muppirala"
> > > > >>> > >> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com>
> wrote:
> > > > >>> > >>
> > > > >>> > >> >In the flexjs/js/bin/mxmlc script, I see that we are
> > > referencing
> > > > >>> the '
> > > > >>> > >> >*/frameworks/js/FlexJS/src*' folder.
> > > > >>> > >>
> > > > >>> > >> This folder is intended as the place for folks to put
> > > > >>>monkey-patched
> > > > >>> JS
> > > > >>> > >> files so they can override the JS in the SWCs if they need
> to
> > > > >>> > >>workaround a
> > > > >>> > >> bug.
> > > > >>> > >>
> > > > >>> > >> What code blew up?  Maybe we should create an empty folder
> there
> > > > >>>or
> > > > >>> make
> > > > >>> > >> the compiler tolerant of it not being there.
> > > > >>> > >>
> > > > >>> > >> Trying to use js.swc with MXMLC is not currently the common
> > > > >>> > >>configuration
> > > > >>> > >> for FlexJS.  Most folks who are using MXML and AS to build a
> > > > >>>FlexJS
> > > > >>> app
> > > > >>> > >> shouldn't need to write directly the the JS API especially
> if
> > > they
> > > > >>> want
> > > > >>> > >>to
> > > > >>> > >> use a SWF version for testing and/or deployment.
> > > > >>> > >>
> > > > >>> > >> If you want to build out a different script for folks to use
> to
> > > > >>>build
> > > > >>> > >> native apps, feel free to do that.
> > > > >>> > >>
> > > > >>> > >> -Aleex
> > > > >>> > >>
> > > > >>> > >>
> > > > >>> >
> > > > >>> >
> > > > >>>
> > > > >>
> > > > >>
> > > >
> > > >
> > >
>

Re: Bug in mxmlc script

Posted by Alex Harui <ah...@adobe.com>.

On 1/5/16, 1:06 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
<omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:

>On Jan 5, 2016 9:36 AM, "Josh Tynjala" <jo...@gmail.com> wrote:
>>
>> asjsc still generates all of the addDependency() calls required for a
>debug
>> build. No hand crafting needed. It generates them in a JS file named
>> ProjectName-dependencies.js. Not coincidentally, that is the only JS
>>file
>> that you need to reference in a script tag in your HTML when running the
>> debug build.
>
>I suppose it does not work that way today?  I see all individual calls
>loading each dependency in index.html.

Are you looking at the html at runtime?  Goog.require ends up injecting
script tags at runtime.

-Alex

Re: Bug in mxmlc script

Posted by OmPrakash Muppirala <bi...@gmail.com>.

On Jan 5, 2016 9:36 AM, "Josh Tynjala" <jo...@gmail.com> wrote:
>
> asjsc still generates all of the addDependency() calls required for a
debug
> build. No hand crafting needed. It generates them in a JS file named
> ProjectName-dependencies.js. Not coincidentally, that is the only JS file
> that you need to reference in a script tag in your HTML when running the
> debug build.

I suppose it does not work that way today?  I see all individual calls
loading each dependency in index.html.

>
> - Josh
> On Jan 5, 2016 1:15 AM, "OmPrakash Muppirala" <bi...@gmail.com>
wrote:
>
> > On Mon, Jan 4, 2016 at 8:49 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> > > Well, the compiler could be upgraded to process a template like Flash
> > > Builder currently does.  I'm curious to know how many folks use Flash
> > > Builder and/or Ant tasks to process the html templates for SWFs vs
> > > plugging in some custom thing in their workflow.
> > >
> >
> > I remember in Flex 2 days where it was very cool to quickly write some
code
> > and hit the run button and see the browser pop-up with the app.  That
made
> > for a very good first impression.  If we don't have a quick way to
visually
> > see the JS code that got generated, there is not much of a first
> > impression, IMHO.
> >
> > Also, it is not very obvious that we need to create a html file with a
new
> > MainClass.start() on body load.  And it seems like we are
> > using goog.addDependency calls to load the required Javascript files.
Do
> > we really expect the users to handcraft this everytime?  That could be
tons
> > of JS files to be added by hand.  Kind of defeats the purpose of having
a
> > transpiler.
> >
> > That said, it will become annoying very quickly when one realizes that
the
> > index.html cannot be changed.
> >
> > I think having a very simple html file as a default template is a happy
> > medium.  It works for the instant gratification that new users would
seek
> > and more advanced users can dig in a bit deeper and swap out the default
> > with a custom template.
> >
> > Thanks,
> > Om
> >
> >
> > >
> > > But IMO, the main reason to have an option is so folks can save a
step in
> > > getting the SDK and trying it out.
> > >
> > > -Alex
> > >
> > > On 1/4/16, 7:56 PM, "Josh Tynjala" <jo...@gmail.com> wrote:
> > >
> > > >I should add that I'm not opposed to adding some kind of optional
flag
> > to
> > > >asjsc that tells it to generate an HTML file similar to how mxmlc
does
> > it.
> > > >That HTML file just doesn't seem especially useful to me, as I
consider
> > > >what it would be like to use asjsc in a real-world project. So I'm
> > trying
> > > >to get a better understanding of your perspective.
> > > >
> > > >- Josh
> > > >
> > > >On Mon, Jan 4, 2016 at 7:49 PM, Josh Tynjala <jo...@gmail.com>
> > > >wrote:
> > > >
> > > >> Is it actually necessary for the compiler to create some kind of
> > > >> boilerplate HTML for you? It may be a little useful for quick
demos,
> > > >>I'll
> > > >> concede, but many real world projects will need highly customized
HTML
> > > >> files. Many need things like analytics, CSS, and other static HTML
> > > >>content
> > > >> that isn't purely generated by JavaScript (for SEO and things).
> > > >>
> > > >> In fact, the compiler isn't really set up for customizing the HTML
> > that
> > > >>it
> > > >> currently generates with mxmlc. You can see it is mostly
hard-coded in
> > > >> JSGoogPublisher.java. It's actually very simple markup. Probably
too
> > > >>simple
> > > >> to use in production for most people, especially if they want to
use
> > > >>asjsc
> > > >> and integrate it into the rest of their web development workflow.
> > > >>
> > > >> - Josh
> > > >>
> > > >> On Mon, Jan 4, 2016 at 5:14 PM, OmPrakash Muppirala
> > > >><bi...@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> On Mon, Jan 4, 2016 at 4:47 PM, Alex Harui <ah...@adobe.com>
wrote:
> > > >>>
> > > >>> > If you diff asjsc vs mxmlc you'll see the difference.
> > > >>> >
> > > >>>
> > > >>> This is the difference I see:
> > > >>>
> > > >>> asjsc:   -js-output-type=jsc
> > > >>> -external-library-path="$SCRIPT_HOME/../libs/js.swc"
> > > >>> mxmlc: -js-output-type=FLEXJS
> > > >>> -sdk-js-lib="$FLEX_HOME/frameworks/js/FlexJS/src"
> > > >>>
> > > >>>
> > > >>> So, -js-output-type=FLEXJS instead of jsc should do the trick of
> > > >>>creating
> > > >>> the index.html file?
> > > >>>
> > > >>>
> > > >>> > IMO, I wouldn't call a new script mxmlcnpm because others may
want
> > an
> > > >>> auto
> > > >>> > generated hmtl as well.  Give it a more generic name.
> > > >>> >
> > > >>>
> > > >>> Here are the current use cases:
> > > >>>
> > > >>> 1.  Convert AS3 (targeting HTML DOM) to JS -> use asjsc
> > > >>> 2.  Convert AS3 + MXML (targeting FlexJS) to JS + HTML > use mxmlc
> > > >>>
> > > >>> The use case we need to add is
> > > >>> Convert AS3 (targeting HTML DOM) to JS + HTML
> > > >>>
> > > >>> Something like asjshtmlc?  In that case, shouldn't mxmlc be
renamed
> > to
> > > >>> mxmlcjshtmlc as well, for the sake of consistency?
> > > >>>
> > > >>> Or am I overthinking this?  What would you suggest?
> > > >>>
> > > >>> Thanks,
> > > >>> Om
> > > >>>
> > > >>>
> > > >>> >
> > > >>> > -Alex
> > > >>> >
> > > >>> > On 1/4/16, 4:28 PM, "omuppi1@gmail.com on behalf of OmPrakash
> > > >>> Muppirala"
> > > >>> > <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
> > > >>> >
> > > >>> > >I think I get it.
> > > >>> > >
> > > >>> > >I thought that the source code for js.swc was in
> > > >>> > >$FLEX_HOME/frameworks/js/FlexJS/src.
> > > >>> > >I guess that is not true?
> > > >>> > >
> > > >>> > >The original problem was that asjsc does not create the
index.html
> > > >>> file.
> > > >>> > >I
> > > >>> > >was asked to use mxmlc for that.  (Refer to the npm install
flexjs
> > > >>> thread)
> > > >>> > >
> > > >>> > >When I used the script in {installed_flexjs}/js/bin/mxmlc, it
blew
> > > >>>up
> > > >>> > >because it could not find the definitions for HTMLElement,
> > > >>>SVGElement
> > > >>> etc.
> > > >>> > >because they are in js.swc.  I don't think it blew up because
of
> > the
> > > >>> > >missing /frameworks/js/FlexJS/src folder.  Adding the external
> > > >>>library
> > > >>> > >path
> > > >>> > >to js.swc fixed this issue.
> > > >>> > >
> > > >>> > >The way I did this was to create a new mxmlcnpm script and add
> > this
> > > >>> js.swc
> > > >>> > >library path in that.  Is that okay?
> > > >>> > >
> > > >>> > >I guess another question is: what would be the best way to add
> > > >>>ability
> > > >>> to
> > > >>> > >create index.html capability to asjsc?
> > > >>> > >
> > > >>> > >Thanks,
> > > >>> > >Om
> > > >>> > >
> > > >>> > >
> > > >>> > >On Mon, Jan 4, 2016 at 4:16 PM, Alex Harui <ah...@adobe.com>
> > > wrote:
> > > >>> > >
> > > >>> > >>
> > > >>> > >>
> > > >>> > >> On 1/4/16, 4:09 PM, "omuppi1@gmail.com on behalf of OmPrakash
> > > >>> > Muppirala"
> > > >>> > >> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
> > > >>> > >>
> > > >>> > >> >In the flexjs/js/bin/mxmlc script, I see that we are
> > referencing
> > > >>> the '
> > > >>> > >> >*/frameworks/js/FlexJS/src*' folder.
> > > >>> > >>
> > > >>> > >> This folder is intended as the place for folks to put
> > > >>>monkey-patched
> > > >>> JS
> > > >>> > >> files so they can override the JS in the SWCs if they need to
> > > >>> > >>workaround a
> > > >>> > >> bug.
> > > >>> > >>
> > > >>> > >> What code blew up?  Maybe we should create an empty folder
there
> > > >>>or
> > > >>> make
> > > >>> > >> the compiler tolerant of it not being there.
> > > >>> > >>
> > > >>> > >> Trying to use js.swc with MXMLC is not currently the common
> > > >>> > >>configuration
> > > >>> > >> for FlexJS.  Most folks who are using MXML and AS to build a
> > > >>>FlexJS
> > > >>> app
> > > >>> > >> shouldn't need to write directly the the JS API especially if
> > they
> > > >>> want
> > > >>> > >>to
> > > >>> > >> use a SWF version for testing and/or deployment.
> > > >>> > >>
> > > >>> > >> If you want to build out a different script for folks to use
to
> > > >>>build
> > > >>> > >> native apps, feel free to do that.
> > > >>> > >>
> > > >>> > >> -Aleex
> > > >>> > >>
> > > >>> > >>
> > > >>> >
> > > >>> >
> > > >>>
> > > >>
> > > >>
> > >
> > >
> >

Re: Bug in mxmlc script

Posted by Josh Tynjala <jo...@gmail.com>.

asjsc still generates all of the addDependency() calls required for a debug
build. No hand crafting needed. It generates them in a JS file named
ProjectName-dependencies.js. Not coincidentally, that is the only JS file
that you need to reference in a script tag in your HTML when running the
debug build.

- Josh
On Jan 5, 2016 1:15 AM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:

> On Mon, Jan 4, 2016 at 8:49 PM, Alex Harui <ah...@adobe.com> wrote:
>
> > Well, the compiler could be upgraded to process a template like Flash
> > Builder currently does.  I'm curious to know how many folks use Flash
> > Builder and/or Ant tasks to process the html templates for SWFs vs
> > plugging in some custom thing in their workflow.
> >
>
> I remember in Flex 2 days where it was very cool to quickly write some code
> and hit the run button and see the browser pop-up with the app.  That made
> for a very good first impression.  If we don't have a quick way to visually
> see the JS code that got generated, there is not much of a first
> impression, IMHO.
>
> Also, it is not very obvious that we need to create a html file with a new
> MainClass.start() on body load.  And it seems like we are
> using goog.addDependency calls to load the required Javascript files.  Do
> we really expect the users to handcraft this everytime?  That could be tons
> of JS files to be added by hand.  Kind of defeats the purpose of having a
> transpiler.
>
> That said, it will become annoying very quickly when one realizes that the
> index.html cannot be changed.
>
> I think having a very simple html file as a default template is a happy
> medium.  It works for the instant gratification that new users would seek
> and more advanced users can dig in a bit deeper and swap out the default
> with a custom template.
>
> Thanks,
> Om
>
>
> >
> > But IMO, the main reason to have an option is so folks can save a step in
> > getting the SDK and trying it out.
> >
> > -Alex
> >
> > On 1/4/16, 7:56 PM, "Josh Tynjala" <jo...@gmail.com> wrote:
> >
> > >I should add that I'm not opposed to adding some kind of optional flag
> to
> > >asjsc that tells it to generate an HTML file similar to how mxmlc does
> it.
> > >That HTML file just doesn't seem especially useful to me, as I consider
> > >what it would be like to use asjsc in a real-world project. So I'm
> trying
> > >to get a better understanding of your perspective.
> > >
> > >- Josh
> > >
> > >On Mon, Jan 4, 2016 at 7:49 PM, Josh Tynjala <jo...@gmail.com>
> > >wrote:
> > >
> > >> Is it actually necessary for the compiler to create some kind of
> > >> boilerplate HTML for you? It may be a little useful for quick demos,
> > >>I'll
> > >> concede, but many real world projects will need highly customized HTML
> > >> files. Many need things like analytics, CSS, and other static HTML
> > >>content
> > >> that isn't purely generated by JavaScript (for SEO and things).
> > >>
> > >> In fact, the compiler isn't really set up for customizing the HTML
> that
> > >>it
> > >> currently generates with mxmlc. You can see it is mostly hard-coded in
> > >> JSGoogPublisher.java. It's actually very simple markup. Probably too
> > >>simple
> > >> to use in production for most people, especially if they want to use
> > >>asjsc
> > >> and integrate it into the rest of their web development workflow.
> > >>
> > >> - Josh
> > >>
> > >> On Mon, Jan 4, 2016 at 5:14 PM, OmPrakash Muppirala
> > >><bi...@gmail.com>
> > >> wrote:
> > >>
> > >>> On Mon, Jan 4, 2016 at 4:47 PM, Alex Harui <ah...@adobe.com> wrote:
> > >>>
> > >>> > If you diff asjsc vs mxmlc you'll see the difference.
> > >>> >
> > >>>
> > >>> This is the difference I see:
> > >>>
> > >>> asjsc:   -js-output-type=jsc
> > >>> -external-library-path="$SCRIPT_HOME/../libs/js.swc"
> > >>> mxmlc: -js-output-type=FLEXJS
> > >>> -sdk-js-lib="$FLEX_HOME/frameworks/js/FlexJS/src"
> > >>>
> > >>>
> > >>> So, -js-output-type=FLEXJS instead of jsc should do the trick of
> > >>>creating
> > >>> the index.html file?
> > >>>
> > >>>
> > >>> > IMO, I wouldn't call a new script mxmlcnpm because others may want
> an
> > >>> auto
> > >>> > generated hmtl as well.  Give it a more generic name.
> > >>> >
> > >>>
> > >>> Here are the current use cases:
> > >>>
> > >>> 1.  Convert AS3 (targeting HTML DOM) to JS -> use asjsc
> > >>> 2.  Convert AS3 + MXML (targeting FlexJS) to JS + HTML > use mxmlc
> > >>>
> > >>> The use case we need to add is
> > >>> Convert AS3 (targeting HTML DOM) to JS + HTML
> > >>>
> > >>> Something like asjshtmlc?  In that case, shouldn't mxmlc be renamed
> to
> > >>> mxmlcjshtmlc as well, for the sake of consistency?
> > >>>
> > >>> Or am I overthinking this?  What would you suggest?
> > >>>
> > >>> Thanks,
> > >>> Om
> > >>>
> > >>>
> > >>> >
> > >>> > -Alex
> > >>> >
> > >>> > On 1/4/16, 4:28 PM, "omuppi1@gmail.com on behalf of OmPrakash
> > >>> Muppirala"
> > >>> > <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
> > >>> >
> > >>> > >I think I get it.
> > >>> > >
> > >>> > >I thought that the source code for js.swc was in
> > >>> > >$FLEX_HOME/frameworks/js/FlexJS/src.
> > >>> > >I guess that is not true?
> > >>> > >
> > >>> > >The original problem was that asjsc does not create the index.html
> > >>> file.
> > >>> > >I
> > >>> > >was asked to use mxmlc for that.  (Refer to the npm install flexjs
> > >>> thread)
> > >>> > >
> > >>> > >When I used the script in {installed_flexjs}/js/bin/mxmlc, it blew
> > >>>up
> > >>> > >because it could not find the definitions for HTMLElement,
> > >>>SVGElement
> > >>> etc.
> > >>> > >because they are in js.swc.  I don't think it blew up because of
> the
> > >>> > >missing /frameworks/js/FlexJS/src folder.  Adding the external
> > >>>library
> > >>> > >path
> > >>> > >to js.swc fixed this issue.
> > >>> > >
> > >>> > >The way I did this was to create a new mxmlcnpm script and add
> this
> > >>> js.swc
> > >>> > >library path in that.  Is that okay?
> > >>> > >
> > >>> > >I guess another question is: what would be the best way to add
> > >>>ability
> > >>> to
> > >>> > >create index.html capability to asjsc?
> > >>> > >
> > >>> > >Thanks,
> > >>> > >Om
> > >>> > >
> > >>> > >
> > >>> > >On Mon, Jan 4, 2016 at 4:16 PM, Alex Harui <ah...@adobe.com>
> > wrote:
> > >>> > >
> > >>> > >>
> > >>> > >>
> > >>> > >> On 1/4/16, 4:09 PM, "omuppi1@gmail.com on behalf of OmPrakash
> > >>> > Muppirala"
> > >>> > >> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
> > >>> > >>
> > >>> > >> >In the flexjs/js/bin/mxmlc script, I see that we are
> referencing
> > >>> the '
> > >>> > >> >*/frameworks/js/FlexJS/src*' folder.
> > >>> > >>
> > >>> > >> This folder is intended as the place for folks to put
> > >>>monkey-patched
> > >>> JS
> > >>> > >> files so they can override the JS in the SWCs if they need to
> > >>> > >>workaround a
> > >>> > >> bug.
> > >>> > >>
> > >>> > >> What code blew up?  Maybe we should create an empty folder there
> > >>>or
> > >>> make
> > >>> > >> the compiler tolerant of it not being there.
> > >>> > >>
> > >>> > >> Trying to use js.swc with MXMLC is not currently the common
> > >>> > >>configuration
> > >>> > >> for FlexJS.  Most folks who are using MXML and AS to build a
> > >>>FlexJS
> > >>> app
> > >>> > >> shouldn't need to write directly the the JS API especially if
> they
> > >>> want
> > >>> > >>to
> > >>> > >> use a SWF version for testing and/or deployment.
> > >>> > >>
> > >>> > >> If you want to build out a different script for folks to use to
> > >>>build
> > >>> > >> native apps, feel free to do that.
> > >>> > >>
> > >>> > >> -Aleex
> > >>> > >>
> > >>> > >>
> > >>> >
> > >>> >
> > >>>
> > >>
> > >>
> >
> >
>

Re: Bug in mxmlc script

Posted by OmPrakash Muppirala <bi...@gmail.com>.

On Mon, Jan 4, 2016 at 8:49 PM, Alex Harui <ah...@adobe.com> wrote:

> Well, the compiler could be upgraded to process a template like Flash
> Builder currently does.  I'm curious to know how many folks use Flash
> Builder and/or Ant tasks to process the html templates for SWFs vs
> plugging in some custom thing in their workflow.
>

I remember in Flex 2 days where it was very cool to quickly write some code
and hit the run button and see the browser pop-up with the app.  That made
for a very good first impression.  If we don't have a quick way to visually
see the JS code that got generated, there is not much of a first
impression, IMHO.

Also, it is not very obvious that we need to create a html file with a new
MainClass.start() on body load.  And it seems like we are
using goog.addDependency calls to load the required Javascript files.  Do
we really expect the users to handcraft this everytime?  That could be tons
of JS files to be added by hand.  Kind of defeats the purpose of having a
transpiler.

That said, it will become annoying very quickly when one realizes that the
index.html cannot be changed.

I think having a very simple html file as a default template is a happy
medium.  It works for the instant gratification that new users would seek
and more advanced users can dig in a bit deeper and swap out the default
with a custom template.

Thanks,
Om


>
> But IMO, the main reason to have an option is so folks can save a step in
> getting the SDK and trying it out.
>
> -Alex
>
> On 1/4/16, 7:56 PM, "Josh Tynjala" <jo...@gmail.com> wrote:
>
> >I should add that I'm not opposed to adding some kind of optional flag to
> >asjsc that tells it to generate an HTML file similar to how mxmlc does it.
> >That HTML file just doesn't seem especially useful to me, as I consider
> >what it would be like to use asjsc in a real-world project. So I'm trying
> >to get a better understanding of your perspective.
> >
> >- Josh
> >
> >On Mon, Jan 4, 2016 at 7:49 PM, Josh Tynjala <jo...@gmail.com>
> >wrote:
> >
> >> Is it actually necessary for the compiler to create some kind of
> >> boilerplate HTML for you? It may be a little useful for quick demos,
> >>I'll
> >> concede, but many real world projects will need highly customized HTML
> >> files. Many need things like analytics, CSS, and other static HTML
> >>content
> >> that isn't purely generated by JavaScript (for SEO and things).
> >>
> >> In fact, the compiler isn't really set up for customizing the HTML that
> >>it
> >> currently generates with mxmlc. You can see it is mostly hard-coded in
> >> JSGoogPublisher.java. It's actually very simple markup. Probably too
> >>simple
> >> to use in production for most people, especially if they want to use
> >>asjsc
> >> and integrate it into the rest of their web development workflow.
> >>
> >> - Josh
> >>
> >> On Mon, Jan 4, 2016 at 5:14 PM, OmPrakash Muppirala
> >><bi...@gmail.com>
> >> wrote:
> >>
> >>> On Mon, Jan 4, 2016 at 4:47 PM, Alex Harui <ah...@adobe.com> wrote:
> >>>
> >>> > If you diff asjsc vs mxmlc you'll see the difference.
> >>> >
> >>>
> >>> This is the difference I see:
> >>>
> >>> asjsc:   -js-output-type=jsc
> >>> -external-library-path="$SCRIPT_HOME/../libs/js.swc"
> >>> mxmlc: -js-output-type=FLEXJS
> >>> -sdk-js-lib="$FLEX_HOME/frameworks/js/FlexJS/src"
> >>>
> >>>
> >>> So, -js-output-type=FLEXJS instead of jsc should do the trick of
> >>>creating
> >>> the index.html file?
> >>>
> >>>
> >>> > IMO, I wouldn't call a new script mxmlcnpm because others may want an
> >>> auto
> >>> > generated hmtl as well.  Give it a more generic name.
> >>> >
> >>>
> >>> Here are the current use cases:
> >>>
> >>> 1.  Convert AS3 (targeting HTML DOM) to JS -> use asjsc
> >>> 2.  Convert AS3 + MXML (targeting FlexJS) to JS + HTML > use mxmlc
> >>>
> >>> The use case we need to add is
> >>> Convert AS3 (targeting HTML DOM) to JS + HTML
> >>>
> >>> Something like asjshtmlc?  In that case, shouldn't mxmlc be renamed to
> >>> mxmlcjshtmlc as well, for the sake of consistency?
> >>>
> >>> Or am I overthinking this?  What would you suggest?
> >>>
> >>> Thanks,
> >>> Om
> >>>
> >>>
> >>> >
> >>> > -Alex
> >>> >
> >>> > On 1/4/16, 4:28 PM, "omuppi1@gmail.com on behalf of OmPrakash
> >>> Muppirala"
> >>> > <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
> >>> >
> >>> > >I think I get it.
> >>> > >
> >>> > >I thought that the source code for js.swc was in
> >>> > >$FLEX_HOME/frameworks/js/FlexJS/src.
> >>> > >I guess that is not true?
> >>> > >
> >>> > >The original problem was that asjsc does not create the index.html
> >>> file.
> >>> > >I
> >>> > >was asked to use mxmlc for that.  (Refer to the npm install flexjs
> >>> thread)
> >>> > >
> >>> > >When I used the script in {installed_flexjs}/js/bin/mxmlc, it blew
> >>>up
> >>> > >because it could not find the definitions for HTMLElement,
> >>>SVGElement
> >>> etc.
> >>> > >because they are in js.swc.  I don't think it blew up because of the
> >>> > >missing /frameworks/js/FlexJS/src folder.  Adding the external
> >>>library
> >>> > >path
> >>> > >to js.swc fixed this issue.
> >>> > >
> >>> > >The way I did this was to create a new mxmlcnpm script and add this
> >>> js.swc
> >>> > >library path in that.  Is that okay?
> >>> > >
> >>> > >I guess another question is: what would be the best way to add
> >>>ability
> >>> to
> >>> > >create index.html capability to asjsc?
> >>> > >
> >>> > >Thanks,
> >>> > >Om
> >>> > >
> >>> > >
> >>> > >On Mon, Jan 4, 2016 at 4:16 PM, Alex Harui <ah...@adobe.com>
> wrote:
> >>> > >
> >>> > >>
> >>> > >>
> >>> > >> On 1/4/16, 4:09 PM, "omuppi1@gmail.com on behalf of OmPrakash
> >>> > Muppirala"
> >>> > >> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
> >>> > >>
> >>> > >> >In the flexjs/js/bin/mxmlc script, I see that we are referencing
> >>> the '
> >>> > >> >*/frameworks/js/FlexJS/src*' folder.
> >>> > >>
> >>> > >> This folder is intended as the place for folks to put
> >>>monkey-patched
> >>> JS
> >>> > >> files so they can override the JS in the SWCs if they need to
> >>> > >>workaround a
> >>> > >> bug.
> >>> > >>
> >>> > >> What code blew up?  Maybe we should create an empty folder there
> >>>or
> >>> make
> >>> > >> the compiler tolerant of it not being there.
> >>> > >>
> >>> > >> Trying to use js.swc with MXMLC is not currently the common
> >>> > >>configuration
> >>> > >> for FlexJS.  Most folks who are using MXML and AS to build a
> >>>FlexJS
> >>> app
> >>> > >> shouldn't need to write directly the the JS API especially if they
> >>> want
> >>> > >>to
> >>> > >> use a SWF version for testing and/or deployment.
> >>> > >>
> >>> > >> If you want to build out a different script for folks to use to
> >>>build
> >>> > >> native apps, feel free to do that.
> >>> > >>
> >>> > >> -Aleex
> >>> > >>
> >>> > >>
> >>> >
> >>> >
> >>>
> >>
> >>
>
>

Re: Bug in mxmlc script

Posted by Alex Harui <ah...@adobe.com>.

Well, the compiler could be upgraded to process a template like Flash
Builder currently does.  I'm curious to know how many folks use Flash
Builder and/or Ant tasks to process the html templates for SWFs vs
plugging in some custom thing in their workflow.

But IMO, the main reason to have an option is so folks can save a step in
getting the SDK and trying it out.

-Alex

On 1/4/16, 7:56 PM, "Josh Tynjala" <jo...@gmail.com> wrote:

>I should add that I'm not opposed to adding some kind of optional flag to
>asjsc that tells it to generate an HTML file similar to how mxmlc does it.
>That HTML file just doesn't seem especially useful to me, as I consider
>what it would be like to use asjsc in a real-world project. So I'm trying
>to get a better understanding of your perspective.
>
>- Josh
>
>On Mon, Jan 4, 2016 at 7:49 PM, Josh Tynjala <jo...@gmail.com>
>wrote:
>
>> Is it actually necessary for the compiler to create some kind of
>> boilerplate HTML for you? It may be a little useful for quick demos,
>>I'll
>> concede, but many real world projects will need highly customized HTML
>> files. Many need things like analytics, CSS, and other static HTML
>>content
>> that isn't purely generated by JavaScript (for SEO and things).
>>
>> In fact, the compiler isn't really set up for customizing the HTML that
>>it
>> currently generates with mxmlc. You can see it is mostly hard-coded in
>> JSGoogPublisher.java. It's actually very simple markup. Probably too
>>simple
>> to use in production for most people, especially if they want to use
>>asjsc
>> and integrate it into the rest of their web development workflow.
>>
>> - Josh
>>
>> On Mon, Jan 4, 2016 at 5:14 PM, OmPrakash Muppirala
>><bi...@gmail.com>
>> wrote:
>>
>>> On Mon, Jan 4, 2016 at 4:47 PM, Alex Harui <ah...@adobe.com> wrote:
>>>
>>> > If you diff asjsc vs mxmlc you'll see the difference.
>>> >
>>>
>>> This is the difference I see:
>>>
>>> asjsc:   -js-output-type=jsc
>>> -external-library-path="$SCRIPT_HOME/../libs/js.swc"
>>> mxmlc: -js-output-type=FLEXJS
>>> -sdk-js-lib="$FLEX_HOME/frameworks/js/FlexJS/src"
>>>
>>>
>>> So, -js-output-type=FLEXJS instead of jsc should do the trick of
>>>creating
>>> the index.html file?
>>>
>>>
>>> > IMO, I wouldn't call a new script mxmlcnpm because others may want an
>>> auto
>>> > generated hmtl as well.  Give it a more generic name.
>>> >
>>>
>>> Here are the current use cases:
>>>
>>> 1.  Convert AS3 (targeting HTML DOM) to JS -> use asjsc
>>> 2.  Convert AS3 + MXML (targeting FlexJS) to JS + HTML > use mxmlc
>>>
>>> The use case we need to add is
>>> Convert AS3 (targeting HTML DOM) to JS + HTML
>>>
>>> Something like asjshtmlc?  In that case, shouldn't mxmlc be renamed to
>>> mxmlcjshtmlc as well, for the sake of consistency?
>>>
>>> Or am I overthinking this?  What would you suggest?
>>>
>>> Thanks,
>>> Om
>>>
>>>
>>> >
>>> > -Alex
>>> >
>>> > On 1/4/16, 4:28 PM, "omuppi1@gmail.com on behalf of OmPrakash
>>> Muppirala"
>>> > <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>>> >
>>> > >I think I get it.
>>> > >
>>> > >I thought that the source code for js.swc was in
>>> > >$FLEX_HOME/frameworks/js/FlexJS/src.
>>> > >I guess that is not true?
>>> > >
>>> > >The original problem was that asjsc does not create the index.html
>>> file.
>>> > >I
>>> > >was asked to use mxmlc for that.  (Refer to the npm install flexjs
>>> thread)
>>> > >
>>> > >When I used the script in {installed_flexjs}/js/bin/mxmlc, it blew
>>>up
>>> > >because it could not find the definitions for HTMLElement,
>>>SVGElement
>>> etc.
>>> > >because they are in js.swc.  I don't think it blew up because of the
>>> > >missing /frameworks/js/FlexJS/src folder.  Adding the external
>>>library
>>> > >path
>>> > >to js.swc fixed this issue.
>>> > >
>>> > >The way I did this was to create a new mxmlcnpm script and add this
>>> js.swc
>>> > >library path in that.  Is that okay?
>>> > >
>>> > >I guess another question is: what would be the best way to add
>>>ability
>>> to
>>> > >create index.html capability to asjsc?
>>> > >
>>> > >Thanks,
>>> > >Om
>>> > >
>>> > >
>>> > >On Mon, Jan 4, 2016 at 4:16 PM, Alex Harui <ah...@adobe.com> wrote:
>>> > >
>>> > >>
>>> > >>
>>> > >> On 1/4/16, 4:09 PM, "omuppi1@gmail.com on behalf of OmPrakash
>>> > Muppirala"
>>> > >> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>>> > >>
>>> > >> >In the flexjs/js/bin/mxmlc script, I see that we are referencing
>>> the '
>>> > >> >*/frameworks/js/FlexJS/src*' folder.
>>> > >>
>>> > >> This folder is intended as the place for folks to put
>>>monkey-patched
>>> JS
>>> > >> files so they can override the JS in the SWCs if they need to
>>> > >>workaround a
>>> > >> bug.
>>> > >>
>>> > >> What code blew up?  Maybe we should create an empty folder there
>>>or
>>> make
>>> > >> the compiler tolerant of it not being there.
>>> > >>
>>> > >> Trying to use js.swc with MXMLC is not currently the common
>>> > >>configuration
>>> > >> for FlexJS.  Most folks who are using MXML and AS to build a
>>>FlexJS
>>> app
>>> > >> shouldn't need to write directly the the JS API especially if they
>>> want
>>> > >>to
>>> > >> use a SWF version for testing and/or deployment.
>>> > >>
>>> > >> If you want to build out a different script for folks to use to
>>>build
>>> > >> native apps, feel free to do that.
>>> > >>
>>> > >> -Aleex
>>> > >>
>>> > >>
>>> >
>>> >
>>>
>>
>>

Re: Bug in mxmlc script

Posted by Josh Tynjala <jo...@gmail.com>.

I should add that I'm not opposed to adding some kind of optional flag to
asjsc that tells it to generate an HTML file similar to how mxmlc does it.
That HTML file just doesn't seem especially useful to me, as I consider
what it would be like to use asjsc in a real-world project. So I'm trying
to get a better understanding of your perspective.

- Josh

On Mon, Jan 4, 2016 at 7:49 PM, Josh Tynjala <jo...@gmail.com> wrote:

> Is it actually necessary for the compiler to create some kind of
> boilerplate HTML for you? It may be a little useful for quick demos, I'll
> concede, but many real world projects will need highly customized HTML
> files. Many need things like analytics, CSS, and other static HTML content
> that isn't purely generated by JavaScript (for SEO and things).
>
> In fact, the compiler isn't really set up for customizing the HTML that it
> currently generates with mxmlc. You can see it is mostly hard-coded in
> JSGoogPublisher.java. It's actually very simple markup. Probably too simple
> to use in production for most people, especially if they want to use asjsc
> and integrate it into the rest of their web development workflow.
>
> - Josh
>
> On Mon, Jan 4, 2016 at 5:14 PM, OmPrakash Muppirala <bi...@gmail.com>
> wrote:
>
>> On Mon, Jan 4, 2016 at 4:47 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>> > If you diff asjsc vs mxmlc you'll see the difference.
>> >
>>
>> This is the difference I see:
>>
>> asjsc:   -js-output-type=jsc
>> -external-library-path="$SCRIPT_HOME/../libs/js.swc"
>> mxmlc: -js-output-type=FLEXJS
>> -sdk-js-lib="$FLEX_HOME/frameworks/js/FlexJS/src"
>>
>>
>> So, -js-output-type=FLEXJS instead of jsc should do the trick of creating
>> the index.html file?
>>
>>
>> > IMO, I wouldn't call a new script mxmlcnpm because others may want an
>> auto
>> > generated hmtl as well.  Give it a more generic name.
>> >
>>
>> Here are the current use cases:
>>
>> 1.  Convert AS3 (targeting HTML DOM) to JS -> use asjsc
>> 2.  Convert AS3 + MXML (targeting FlexJS) to JS + HTML > use mxmlc
>>
>> The use case we need to add is
>> Convert AS3 (targeting HTML DOM) to JS + HTML
>>
>> Something like asjshtmlc?  In that case, shouldn't mxmlc be renamed to
>> mxmlcjshtmlc as well, for the sake of consistency?
>>
>> Or am I overthinking this?  What would you suggest?
>>
>> Thanks,
>> Om
>>
>>
>> >
>> > -Alex
>> >
>> > On 1/4/16, 4:28 PM, "omuppi1@gmail.com on behalf of OmPrakash
>> Muppirala"
>> > <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>> >
>> > >I think I get it.
>> > >
>> > >I thought that the source code for js.swc was in
>> > >$FLEX_HOME/frameworks/js/FlexJS/src.
>> > >I guess that is not true?
>> > >
>> > >The original problem was that asjsc does not create the index.html
>> file.
>> > >I
>> > >was asked to use mxmlc for that.  (Refer to the npm install flexjs
>> thread)
>> > >
>> > >When I used the script in {installed_flexjs}/js/bin/mxmlc, it blew up
>> > >because it could not find the definitions for HTMLElement, SVGElement
>> etc.
>> > >because they are in js.swc.  I don't think it blew up because of the
>> > >missing /frameworks/js/FlexJS/src folder.  Adding the external library
>> > >path
>> > >to js.swc fixed this issue.
>> > >
>> > >The way I did this was to create a new mxmlcnpm script and add this
>> js.swc
>> > >library path in that.  Is that okay?
>> > >
>> > >I guess another question is: what would be the best way to add ability
>> to
>> > >create index.html capability to asjsc?
>> > >
>> > >Thanks,
>> > >Om
>> > >
>> > >
>> > >On Mon, Jan 4, 2016 at 4:16 PM, Alex Harui <ah...@adobe.com> wrote:
>> > >
>> > >>
>> > >>
>> > >> On 1/4/16, 4:09 PM, "omuppi1@gmail.com on behalf of OmPrakash
>> > Muppirala"
>> > >> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>> > >>
>> > >> >In the flexjs/js/bin/mxmlc script, I see that we are referencing
>> the '
>> > >> >*/frameworks/js/FlexJS/src*' folder.
>> > >>
>> > >> This folder is intended as the place for folks to put monkey-patched
>> JS
>> > >> files so they can override the JS in the SWCs if they need to
>> > >>workaround a
>> > >> bug.
>> > >>
>> > >> What code blew up?  Maybe we should create an empty folder there or
>> make
>> > >> the compiler tolerant of it not being there.
>> > >>
>> > >> Trying to use js.swc with MXMLC is not currently the common
>> > >>configuration
>> > >> for FlexJS.  Most folks who are using MXML and AS to build a FlexJS
>> app
>> > >> shouldn't need to write directly the the JS API especially if they
>> want
>> > >>to
>> > >> use a SWF version for testing and/or deployment.
>> > >>
>> > >> If you want to build out a different script for folks to use to build
>> > >> native apps, feel free to do that.
>> > >>
>> > >> -Aleex
>> > >>
>> > >>
>> >
>> >
>>
>
>

Re: Bug in mxmlc script

Posted by Josh Tynjala <jo...@gmail.com>.

Is it actually necessary for the compiler to create some kind of
boilerplate HTML for you? It may be a little useful for quick demos, I'll
concede, but many real world projects will need highly customized HTML
files. Many need things like analytics, CSS, and other static HTML content
that isn't purely generated by JavaScript (for SEO and things).

In fact, the compiler isn't really set up for customizing the HTML that it
currently generates with mxmlc. You can see it is mostly hard-coded in
JSGoogPublisher.java. It's actually very simple markup. Probably too simple
to use in production for most people, especially if they want to use asjsc
and integrate it into the rest of their web development workflow.

- Josh

On Mon, Jan 4, 2016 at 5:14 PM, OmPrakash Muppirala <bi...@gmail.com>
wrote:

> On Mon, Jan 4, 2016 at 4:47 PM, Alex Harui <ah...@adobe.com> wrote:
>
> > If you diff asjsc vs mxmlc you'll see the difference.
> >
>
> This is the difference I see:
>
> asjsc:   -js-output-type=jsc
> -external-library-path="$SCRIPT_HOME/../libs/js.swc"
> mxmlc: -js-output-type=FLEXJS
> -sdk-js-lib="$FLEX_HOME/frameworks/js/FlexJS/src"
>
>
> So, -js-output-type=FLEXJS instead of jsc should do the trick of creating
> the index.html file?
>
>
> > IMO, I wouldn't call a new script mxmlcnpm because others may want an
> auto
> > generated hmtl as well.  Give it a more generic name.
> >
>
> Here are the current use cases:
>
> 1.  Convert AS3 (targeting HTML DOM) to JS -> use asjsc
> 2.  Convert AS3 + MXML (targeting FlexJS) to JS + HTML > use mxmlc
>
> The use case we need to add is
> Convert AS3 (targeting HTML DOM) to JS + HTML
>
> Something like asjshtmlc?  In that case, shouldn't mxmlc be renamed to
> mxmlcjshtmlc as well, for the sake of consistency?
>
> Or am I overthinking this?  What would you suggest?
>
> Thanks,
> Om
>
>
> >
> > -Alex
> >
> > On 1/4/16, 4:28 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
> > <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
> >
> > >I think I get it.
> > >
> > >I thought that the source code for js.swc was in
> > >$FLEX_HOME/frameworks/js/FlexJS/src.
> > >I guess that is not true?
> > >
> > >The original problem was that asjsc does not create the index.html file.
> > >I
> > >was asked to use mxmlc for that.  (Refer to the npm install flexjs
> thread)
> > >
> > >When I used the script in {installed_flexjs}/js/bin/mxmlc, it blew up
> > >because it could not find the definitions for HTMLElement, SVGElement
> etc.
> > >because they are in js.swc.  I don't think it blew up because of the
> > >missing /frameworks/js/FlexJS/src folder.  Adding the external library
> > >path
> > >to js.swc fixed this issue.
> > >
> > >The way I did this was to create a new mxmlcnpm script and add this
> js.swc
> > >library path in that.  Is that okay?
> > >
> > >I guess another question is: what would be the best way to add ability
> to
> > >create index.html capability to asjsc?
> > >
> > >Thanks,
> > >Om
> > >
> > >
> > >On Mon, Jan 4, 2016 at 4:16 PM, Alex Harui <ah...@adobe.com> wrote:
> > >
> > >>
> > >>
> > >> On 1/4/16, 4:09 PM, "omuppi1@gmail.com on behalf of OmPrakash
> > Muppirala"
> > >> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
> > >>
> > >> >In the flexjs/js/bin/mxmlc script, I see that we are referencing the
> '
> > >> >*/frameworks/js/FlexJS/src*' folder.
> > >>
> > >> This folder is intended as the place for folks to put monkey-patched
> JS
> > >> files so they can override the JS in the SWCs if they need to
> > >>workaround a
> > >> bug.
> > >>
> > >> What code blew up?  Maybe we should create an empty folder there or
> make
> > >> the compiler tolerant of it not being there.
> > >>
> > >> Trying to use js.swc with MXMLC is not currently the common
> > >>configuration
> > >> for FlexJS.  Most folks who are using MXML and AS to build a FlexJS
> app
> > >> shouldn't need to write directly the the JS API especially if they
> want
> > >>to
> > >> use a SWF version for testing and/or deployment.
> > >>
> > >> If you want to build out a different script for folks to use to build
> > >> native apps, feel free to do that.
> > >>
> > >> -Aleex
> > >>
> > >>
> >
> >
>

Re: Bug in mxmlc script

Posted by OmPrakash Muppirala <bi...@gmail.com>.

On Mon, Jan 4, 2016 at 4:47 PM, Alex Harui <ah...@adobe.com> wrote:

> If you diff asjsc vs mxmlc you'll see the difference.
>

This is the difference I see:

asjsc:   -js-output-type=jsc
-external-library-path="$SCRIPT_HOME/../libs/js.swc"
mxmlc: -js-output-type=FLEXJS
-sdk-js-lib="$FLEX_HOME/frameworks/js/FlexJS/src"


So, -js-output-type=FLEXJS instead of jsc should do the trick of creating
the index.html file?


> IMO, I wouldn't call a new script mxmlcnpm because others may want an auto
> generated hmtl as well.  Give it a more generic name.
>

Here are the current use cases:

1.  Convert AS3 (targeting HTML DOM) to JS -> use asjsc
2.  Convert AS3 + MXML (targeting FlexJS) to JS + HTML > use mxmlc

The use case we need to add is
Convert AS3 (targeting HTML DOM) to JS + HTML

Something like asjshtmlc?  In that case, shouldn't mxmlc be renamed to
mxmlcjshtmlc as well, for the sake of consistency?

Or am I overthinking this?  What would you suggest?

Thanks,
Om


>
> -Alex
>
> On 1/4/16, 4:28 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>
> >I think I get it.
> >
> >I thought that the source code for js.swc was in
> >$FLEX_HOME/frameworks/js/FlexJS/src.
> >I guess that is not true?
> >
> >The original problem was that asjsc does not create the index.html file.
> >I
> >was asked to use mxmlc for that.  (Refer to the npm install flexjs thread)
> >
> >When I used the script in {installed_flexjs}/js/bin/mxmlc, it blew up
> >because it could not find the definitions for HTMLElement, SVGElement etc.
> >because they are in js.swc.  I don't think it blew up because of the
> >missing /frameworks/js/FlexJS/src folder.  Adding the external library
> >path
> >to js.swc fixed this issue.
> >
> >The way I did this was to create a new mxmlcnpm script and add this js.swc
> >library path in that.  Is that okay?
> >
> >I guess another question is: what would be the best way to add ability to
> >create index.html capability to asjsc?
> >
> >Thanks,
> >Om
> >
> >
> >On Mon, Jan 4, 2016 at 4:16 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >>
> >>
> >> On 1/4/16, 4:09 PM, "omuppi1@gmail.com on behalf of OmPrakash
> Muppirala"
> >> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
> >>
> >> >In the flexjs/js/bin/mxmlc script, I see that we are referencing the '
> >> >*/frameworks/js/FlexJS/src*' folder.
> >>
> >> This folder is intended as the place for folks to put monkey-patched JS
> >> files so they can override the JS in the SWCs if they need to
> >>workaround a
> >> bug.
> >>
> >> What code blew up?  Maybe we should create an empty folder there or make
> >> the compiler tolerant of it not being there.
> >>
> >> Trying to use js.swc with MXMLC is not currently the common
> >>configuration
> >> for FlexJS.  Most folks who are using MXML and AS to build a FlexJS app
> >> shouldn't need to write directly the the JS API especially if they want
> >>to
> >> use a SWF version for testing and/or deployment.
> >>
> >> If you want to build out a different script for folks to use to build
> >> native apps, feel free to do that.
> >>
> >> -Aleex
> >>
> >>
>
>

Re: Bug in mxmlc script

Posted by Alex Harui <ah...@adobe.com>.

If you diff asjsc vs mxmlc you'll see the difference.

IMO, I wouldn't call a new script mxmlcnpm because others may want an auto
generated hmtl as well.  Give it a more generic name.

-Alex

On 1/4/16, 4:28 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
<omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:

>I think I get it.
>
>I thought that the source code for js.swc was in
>$FLEX_HOME/frameworks/js/FlexJS/src.
>I guess that is not true?
>
>The original problem was that asjsc does not create the index.html file.
>I
>was asked to use mxmlc for that.  (Refer to the npm install flexjs thread)
>
>When I used the script in {installed_flexjs}/js/bin/mxmlc, it blew up
>because it could not find the definitions for HTMLElement, SVGElement etc.
>because they are in js.swc.  I don't think it blew up because of the
>missing /frameworks/js/FlexJS/src folder.  Adding the external library
>path
>to js.swc fixed this issue.
>
>The way I did this was to create a new mxmlcnpm script and add this js.swc
>library path in that.  Is that okay?
>
>I guess another question is: what would be the best way to add ability to
>create index.html capability to asjsc?
>
>Thanks,
>Om
>
>
>On Mon, Jan 4, 2016 at 4:16 PM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>> On 1/4/16, 4:09 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
>> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>>
>> >In the flexjs/js/bin/mxmlc script, I see that we are referencing the '
>> >*/frameworks/js/FlexJS/src*' folder.
>>
>> This folder is intended as the place for folks to put monkey-patched JS
>> files so they can override the JS in the SWCs if they need to
>>workaround a
>> bug.
>>
>> What code blew up?  Maybe we should create an empty folder there or make
>> the compiler tolerant of it not being there.
>>
>> Trying to use js.swc with MXMLC is not currently the common
>>configuration
>> for FlexJS.  Most folks who are using MXML and AS to build a FlexJS app
>> shouldn't need to write directly the the JS API especially if they want
>>to
>> use a SWF version for testing and/or deployment.
>>
>> If you want to build out a different script for folks to use to build
>> native apps, feel free to do that.
>>
>> -Aleex
>>
>>

Re: Bug in mxmlc script

Posted by OmPrakash Muppirala <bi...@gmail.com>.

I think I get it.

I thought that the source code for js.swc was in
$FLEX_HOME/frameworks/js/FlexJS/src.
I guess that is not true?

The original problem was that asjsc does not create the index.html file.  I
was asked to use mxmlc for that.  (Refer to the npm install flexjs thread)

When I used the script in {installed_flexjs}/js/bin/mxmlc, it blew up
because it could not find the definitions for HTMLElement, SVGElement etc.
because they are in js.swc.  I don't think it blew up because of the
missing /frameworks/js/FlexJS/src folder.  Adding the external library path
to js.swc fixed this issue.

The way I did this was to create a new mxmlcnpm script and add this js.swc
library path in that.  Is that okay?

I guess another question is: what would be the best way to add ability to
create index.html capability to asjsc?

Thanks,
Om

On Mon, Jan 4, 2016 at 4:16 PM, Alex Harui <ah...@adobe.com> wrote:

>
>
> On 1/4/16, 4:09 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>
> >In the flexjs/js/bin/mxmlc script, I see that we are referencing the '
> >*/frameworks/js/FlexJS/src*' folder.
>
> This folder is intended as the place for folks to put monkey-patched JS
> files so they can override the JS in the SWCs if they need to workaround a
> bug.
>
> What code blew up?  Maybe we should create an empty folder there or make
> the compiler tolerant of it not being there.
>
> Trying to use js.swc with MXMLC is not currently the common configuration
> for FlexJS.  Most folks who are using MXML and AS to build a FlexJS app
> shouldn't need to write directly the the JS API especially if they want to
> use a SWF version for testing and/or deployment.
>
> If you want to build out a different script for folks to use to build
> native apps, feel free to do that.
>
> -Aleex
>
>

Re: Bug in mxmlc script

Posted by Alex Harui <ah...@adobe.com>.

On 1/4/16, 4:09 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
<omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:

>In the flexjs/js/bin/mxmlc script, I see that we are referencing the '
>*/frameworks/js/FlexJS/src*' folder.

This folder is intended as the place for folks to put monkey-patched JS
files so they can override the JS in the SWCs if they need to workaround a
bug.

What code blew up?  Maybe we should create an empty folder there or make
the compiler tolerant of it not being there.

Trying to use js.swc with MXMLC is not currently the common configuration
for FlexJS.  Most folks who are using MXML and AS to build a FlexJS app
shouldn't need to write directly the the JS API especially if they want to
use a SWF version for testing and/or deployment.

If you want to build out a different script for folks to use to build
native apps, feel free to do that.

-Aleex