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 > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >> > >> >