flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OmPrakash Muppirala <bigosma...@gmail.com>
Subject Re: Bug in mxmlc script
Date Tue, 05 Jan 2016 21:06:22 GMT
On Jan 5, 2016 9:36 AM, "Josh Tynjala" <joshtynjala@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" <bigosmallm@gmail.com>
wrote:
>
> > On Mon, Jan 4, 2016 at 8:49 PM, Alex Harui <aharui@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" <joshtynjala@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
> > > >><bigosmallm@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> On Mon, Jan 4, 2016 at 4:47 PM, Alex Harui <aharui@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 <aharui@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
> > > >>> > >>
> > > >>> > >>
> > > >>> >
> > > >>> >
> > > >>>
> > > >>
> > > >>
> > >
> > >
> >

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message