On Jan 5, 2016 3:03 AM, "Harbs" <harbs.li...@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 <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
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
