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

Reply via email to