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" <bigosma...@gmail.com> wrote:
> On Mon, Jan 4, 2016 at 8:49 PM, Alex Harui <aha...@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" <joshtynj...@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 <joshtynj...@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
> > >><bigosma...@gmail.com>
> > >> wrote:
> > >>
> > >>> On Mon, Jan 4, 2016 at 4:47 PM, Alex Harui <aha...@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, "omup...@gmail.com on behalf of OmPrakash
> > >>> Muppirala"
> > >>> > <omup...@gmail.com on behalf of bigosma...@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 <aha...@adobe.com>
> > wrote:
> > >>> > >
> > >>> > >>
> > >>> > >>
> > >>> > >> On 1/4/16, 4:09 PM, "omup...@gmail.com on behalf of OmPrakash
> > >>> > Muppirala"
> > >>> > >> <omup...@gmail.com on behalf of bigosma...@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
> > >>> > >>
> > >>> > >>
> > >>> >
> > >>> >
> > >>>
> > >>
> > >>
> >
> >
>
