'I'm pretty sure externs are not scanned for inject_html. Volunteers are
welcome to teach the compiler to do so.'
I am happy to look into this sometime in the next few days. Just trying to
finish up something else first...
On Sat, May 4, 2019 at 8:54 AM Alex Harui <aha...@adobe.com.invalid> wrote:
> Hi Carlos,
>
> I'm pretty sure externs are not scanned for inject_html. Volunteers are
> welcome to teach the compiler to do so.
>
> -Alex
>
> On 5/3/19, 1:50 PM, "Carlos Rovira" <carlosrov...@apache.org> wrote:
>
> Hi,
>
> while putting the pieces together for the blog example I'm finding the
> following.
>
> For classes that wraps a js code that is an intrinsic file needed to
> make
> the code function I think inject_html should work but I'm trying it and
> seems this is not working. The code is like this:
>
> package
> {
> /**
> * @externs
> */
> public class hljs
> {
> /**
> * <inject_html>
> * <script src="
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcdnjs.cloudflare.com%2Fajax%2Flibs%2Fhighlight.js%2F9.12.0%2Fhighlight.min.js&data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550849329&sdata=Ly6nMG8kCFvf2Dl4PCohbV8T9MPU%2F7OV2CaYrQNFXnY%3D&reserved=0
> "></script>
> * <link rel="stylesheet" title="Atom One Dark" href="
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcdnjs.cloudflare.com%2Fajax%2Flibs%2Fhighlight.js%2F9.12.0%2Fstyles%2Fatom-one-dark.min.css&data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550849329&sdata=C512YPiiwRTU909ZEV5dOT94FELRDVSqm4mNYt58fLY%3D&reserved=0
> ">
> * </inject_html>
> */
> public function hljs()
> {
> }
>
> public static function highlightBlock(block:Element):void {}
> }
> }
>
> So instead of add the inject_html in the code that calls the methods in
> this step, I think it should be here
>
> Make this sense?
>
>
>
> El vie., 3 may. 2019 a las 9:38, Carlos Rovira (<
> carlosrov...@apache.org>)
> escribió:
>
> > Hi Alex,
> >
> > for me is difficult right now think about what would be better for
> > TypeScript. I think all will depend on how people interact in the
> following
> > months/years to show us what't the best for Royale in the long term.
> > I think bringing TS to Royale as a first citizen language will make
> us
> > more accesible and people will considere us more since TS is the
> language
> > people choose over AS3 (although I for example like AS3 more and if
> we get
> > few things like generics we'll be great to compete with TS), but
> this is a
> > very complex task, so I know this hardly be done unless someone
> comes with
> > time and knowledge to make it happen. And if we think about things
> that are
> > complex and hard to add and see the importance/value it will bring to
> > Royale I think a WebAssembly target will be over TS since it clearly
> > enhance the Roayle purpose of generate multiple sources.
> >
> > In the other hand, make TS just to do TypeDefs, again maybe users
> should
> > express here if it could be needed, I can't say right now how much
> this
> > could be important for Royale, so maybe time and users will let us
> know
> > what to do.
> >
> >
> >
> > El jue., 2 may. 2019 a las 22:44, Alex Harui
> (<aha...@adobe.com.invalid>)
> > escribió:
> >
> >> The word "package" has many meanings. In AS3 it is a way of
> avoiding API
> >> name collisions. AIUI, an AS3 package in SWF code has no object or
> >> function representation. It effectively just creates a longer
> "qualified
> >> name". IOW, in a SWF, if there is a class "mx.core.UIComponent",
> there is
> >> no "mx.core" object you can iterate to see all of the classes.
> >>
> >> For Royale's JS output, an AS3 package has an object representation
> in
> >> debug mode because we use the same pattern as Google Closure. So
> there
> >> really would be an "mx" Object with a "core" property object with a
> >> UIComponent function that serves as the constructor. However, in
> >> production, these package objects are often collapsed, so it is
> best to not
> >> assume the objects exist.
> >>
> >> Then there are Node/NPM packages and modules and other sorts of
> >> "packaging". But in this thread I was only referencing AS3
> Packages.
> >>
> >> Also in this thread I mentioned TypeScript. While Royale could
> support
> >> TypeScript as Carlos mentioned, as an alternative to writing AS3, I
> only
> >> mentioned it because the existence of a TypeScript definition for a
> library
> >> indicates that the library can have a strongly-typed API surface
> which
> >> means it is highly likely you can create Royale typedefs for that
> library,
> >> and because I thought that Josh's converter was still working.
> Supporting
> >> TypeScript as an alternative programming language in Royale is a
> >> significant chunk of work and is not something I plan to work on at
> this
> >> time. But I was only mentioning using TypeScript to generate
> typedefs,
> >> which is a different effort and could be a smaller effort and give
> us
> >> access to a huge set of typedefs. I have no plans to work on that
> at this
> >> time either, but I could imagine myself working on that if there
> was enough
> >> demand for it.
> >>
> >> HTH,
> >> -Alex
> >>
> >> On 5/2/19, 11:24 AM, "Dany Dhondt" <archeme...@mac.com.INVALID>
> wrote:
> >>
> >> Hi Josh,
> >>
> >> Aren’t most of the packages just functions?
> >> In ES6, you’d import packages as
> >> Import { myFunct, myVar } from ‘my-package’
> >> In older javascript you’d:
> >> const myPackagePointer = require(‘my-package’)
> >>
> >> So your ‘fun’ example sounds like heaven to me! This is exactly
> what
> >> we need.
> >>
> >> About Typescript: do we need that at all? I think, but maybe
> this
> >> goes beyond my technical knowledge, all node packages are compiled
> into
> >> plain old javascript functions. Typescript is only needed for
> authoring the
> >> packages. Once compiled there’s no trace of Typescript at all. If
> this is
> >> indeed true, then we shouldn’t bother about Typescript at all, and
> just
> >> concentrate on incorporating the pure javascript libs.
> >>
> >> Dany
> >>
> >> > Op 2 mei 2019, om 19:57 heeft Josh Tynjala <
> joshtynj...@apache.org>
> >> het volgende geschreven:
> >> >
> >> > Just for fun, here's another way that you could create a
> typedef
> >> for hljs so that the highlightBlock() function is directly in a
> package
> >> (similar to flash.net.navigateToURL), instead of as a static method
> on a
> >> class:
> >> >
> >> >
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FkhVI&data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550849329&sdata=E%2BzcgdC3TLRNC%2FL8IfXSeXQZslQJP7pEMcL5z%2FpcV3g%3D&reserved=0
> >> >
> >> > If you did it this way, you'd need to import it before you
> can call
> >> the function, like this:
> >> >
> >> > import hljs.highlightBlock;
> >> >
> >> > Or this should work too, if you prefer:
> >> >
> >> > import hljs.*;
> >> >
> >> > And then you can call the function directly (without the hljs.
> >> prefix):
> >> >
> >> > highlightBlock(block);
> >> >
> >> > As you can see, the way that you choose to expose a JS
> library to
> >> ActionScript is pretty flexible. Some JavaScript libraries are just
> a
> >> function, and some have APIs that work more like classes. Depending
> on the
> >> library, one way may work better than the other.
> >> >
> >> > - Josh
> >> >
> >> > On 2019/05/02 17:48:49, Josh Tynjala <joshtynj...@apache.org>
> >> wrote:
> >> >> Exactly right. When you create a typedef class, you're
> trying to
> >> simulate how you would access the API as if you were writing in
> plain
> >> JavaScript. You call hljs.highlightBlock() in JavaScript, so you
> need a
> >> class that works the same way in ActionScript.
> >> >>
> >> >> Another option for organization would be to keep all of your
> >> typedefs in a separate folder from your app's source files, and
> reference
> >> the typedefs folder using the source-path compiler option.
> >> >>
> >> >> - Josh
> >> >>
> >> >> On 2019/05/02 16:23:45, Alex Harui <aha...@adobe.com.INVALID
> >
> >> wrote:
> >> >>> Hi Carlos,
> >> >>>
> >> >>> I don’t think hljs is in a package called "externs". In
> Josh's
> >> example, hljs was in the top-level package. And that's because
> hljs is
> >> found at runtime off of the global window object, not some
> sub-object
> >> called "externs". So, the hljs.as file containing the externs has
> to go
> >> in the root of a source-path, not in some folder called "externs"
> (which is
> >> why some folks will take the time to create a separate typedefs SWC
> so as
> >> not to clutter the root of their application's source directory).
> >> >>>
> >> >>> Then instead of "import externs.hljs", it should be "import
> hljs"
> >> (or shouldn’t be needed at all).
> >> >>>
> >> >>> HTH,
> >> >>> -Alex
> >> >>>
> >> >>> On 5/2/19, 9:11 AM, "Carlos Rovira" <
> carlosrov...@apache.org>
> >> wrote:
> >> >>>
> >> >>> Hi,
> >> >>>
> >> >>> in my latest commit I added hljs extern class like Josh
> show
> >> in package
> >> >>> externs in TDJ
> >> >>>
> >> >>> Then I didn't commit the following since is not working
> for me:
> >> >>>
> >> >>> 1.- In HighlightCode class (in utils package TDJ)
> >> >>>
> >> >>> added:
> >> >>>
> >> >>> import externs.hljs;
> >> >>>
> >> >>> changed the method highlightBlock to:
> >> >>>
> >> >>> COMPILE::JS
> >> >>> /**
> >> >>> * block is the element (WrappedHTMLElement) inside the
> >> component (the
> >> >>> <code> tag)
> >> >>> */
> >> >>> public function
> highlightBlock(block:Element):void
> >> >>> {
> >> >>> hljs.highlightBlock(block);
> >> >>> }
> >> >>>
> >> >>> and running it I get:
> >> >>>
> >> >>> Uncaught ReferenceError: externs is not defined
> >> >>> at utils.HighlightCode.highlightBlock
> (HighlightCode.as:53)
> >> >>> at
> >> >>>
> >>
> WelcomeSection.components.ExampleAndSourceCodeTabbedSectionContent.dataReadyHandler
> >> >>> (ExampleAndSourceCodeTabbedSectionContent.as:138)
> >> >>> at
> >> services.GitHubService.goog.events.EventTarget.fireListeners
> >> >>> (eventtarget.js:284)
> >> >>> at
> Function.goog.events.EventTarget.dispatchEventInternal_
> >> >>> (eventtarget.js:381)
> >> >>> at
> >> services.GitHubService.goog.events.EventTarget.dispatchEvent
> >> >>> (eventtarget.js:196)
> >> >>> at
> >> >>> services.GitHubService.org
> >> .apache.royale.events.EventDispatcher.dispatchEvent
> >> >>> (EventDispatcher.js:71)
> >> >>> at
> >> services.GitHubService.services_GitHubService_completeHandler
> >> >>> (GitHubService.as:54)
> >> >>> at
> >> >>> org.apache.royale.net
> >> .HTTPService.goog.events.EventTarget.fireListeners
> >> >>> (eventtarget.js:284)
> >> >>> at
> Function.goog.events.EventTarget.dispatchEventInternal_
> >> >>> (eventtarget.js:381)
> >> >>> at
> >> >>> org.apache.royale.net
> >> .HTTPService.goog.events.EventTarget.dispatchEvent
> >> >>> (eventtarget.js:196)
> >> >>>
> >> >>> What I'm doing wrong?
> >> >>>
> >> >>> thanks!
> >> >>>
> >> >>>
> >> >>> El jue., 2 may. 2019 a las 18:02, Carlos Rovira (<
> >> carlosrov...@apache.org>)
> >> >>> escribió:
> >> >>>
> >> >>>> Hi Josh,
> >> >>>>
> >> >>>> I think this piece of knowledge you just exposed here is
> key for
> >> the
> >> >>>> success of Royale.
> >> >>>>
> >> >>>> I'll try to use this in TDJ to experiment with it and will
> use
> >> in the blog
> >> >>>> example I plan to do.
> >> >>>>
> >> >>>> thanks!
> >> >>>>
> >> >>>>
> >> >>>> El jue., 2 may. 2019 a las 16:36, Josh Tynjala (<
> >> joshtynj...@apache.org>)
> >> >>>> escribió:
> >> >>>>
> >> >>>>>> Users can't do this, they required that Royale framework
> devs
> >> add
> >> >>>>> typedefs to the typedefs repo and wait to next SDK
> release.
> >> What does not
> >> >>>>> seems very useful.
> >> >>>>>
> >> >>>>> Users can create their own typedefs from scratch.
> >> >>>>>
> >> >>>>> I just created a quick example for hljs, that exposes the
> >> >>>>> highlightBlock() function:
> >> >>>>>
> >> >>>>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FdIq0&data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550849329&sdata=hyGPtFg919vlEreGs9E7OqkqRcSHImOIGt8Mt5FNfaI%3D&reserved=0
> >> >>>>>
> >> >>>>> Basically, the class needs an asdoc comment with the
> @externs
> >> tag (this
> >> >>>>> is something that comes from Google Closure compiler,
> which we
> >> use to
> >> >>>>> create release builds) and the compiler should handle the
> rest.
> >> >>>>>
> >> >>>>> As I understand it, you don't even need to create a SWC
> library
> >> for
> >> >>>>> custom typedefs. Recently, Alex mentioned that the mxmlc
> >> compiler is smart
> >> >>>>> enough to handle a source file as long as it has the
> @externs
> >> tag.
> >> >>>>>
> >> >>>>> - Josh
> >> >>>>>
> >> >>>>> On 2019/05/02 09:34:37, Carlos Rovira <
> carlosrov...@apache.org>
> >> wrote:
> >> >>>>>> Hi,
> >> >>>>>>
> >> >>>>>> to sumarize (let me know if I'm wrong), the current ways
> to
> >> integrate an
> >> >>>>>> existing library are 3:
> >> >>>>>>
> >> >>>>>> 1.- access vía brackets notation: This is the most easy
> and
> >> direct, an
> >> >>>>>> example is TourDeJewel in class utils.HighlightCode
> >> >>>>>>
> >> >>>>>> var hljs:Object = window["hljs"];
> >> >>>>>> hljs["highlightBlock"](block);
> >> >>>>>>
> >> >>>>>> but this one is not what we really want since we are
> going
> >> with Roayle
> >> >>>>> and
> >> >>>>>> AS3 to get type checking and strong typing. So this,
> although
> >> useful is
> >> >>>>> not
> >> >>>>>> what we really want to use in out Apps, but since we
> want to
> >> maintain
> >> >>>>> the
> >> >>>>>> dynamic aspect of the language it could be very useful
> >> sometimes
> >> >>>>>>
> >> >>>>>> 2.- using typedefs
> >> >>>>>>
> >> >>>>>> This will be the next step to use a real type and dot
> >> notation, but
> >> >>>>> seems
> >> >>>>>> not easy or direct.
> >> >>>>>> Users can't do this, they required that Royale framework
> devs
> >> add
> >> >>>>> typedefs
> >> >>>>>> to the typedefs repo and wait to next SDK release. What
> does
> >> not seems
> >> >>>>> very
> >> >>>>>> useful.
> >> >>>>>>
> >> >>>>>> In the other hand we'll need to know how to extend
> current
> >> typedefs
> >> >>>>> since
> >> >>>>>> don't know if we have docs about this. Until now I added
> to
> >> "missing.js"
> >> >>>>>> file fo now, but this doesn't seems a valid path since
> it lacks
> >> >>>>>> organization, separation, and a way for all people
> >> contributing to know
> >> >>>>> wha
> >> >>>>>> we have, what can be added and where, if not we'll find
> in
> >> time lots of
> >> >>>>>> code very difficult to maintain.
> >> >>>>>>
> >> >>>>>> Yishay and Josh talked about to use TypeScript, but
> seems that
> >> is
> >> >>>>> already
> >> >>>>>> explored by Josh but not a valid path since will be very
> >> difficult to
> >> >>>>>> maintain.
> >> >>>>>>
> >> >>>>>> 3.- wrapping libraries
> >> >>>>>>
> >> >>>>>> This is how we did with MDL. This will be recommended
> when we
> >> want to
> >> >>>>>> integrate existing libraries with Royale to make it work
> with
> >> our APIs
> >> >>>>> in a
> >> >>>>>> more seamless way. But the problems is that this is very
> >> laborious. Can
> >> >>>>> be
> >> >>>>>> useful for some concrete libraries and we should do when
> >> needed (the
> >> >>>>> case
> >> >>>>>> is MDL). But the problem is that this not solve the
> problem of
> >> our users
> >> >>>>>> that need to integrate a existing library themselves in a
> >> quick way.
> >> >>>>>>
> >> >>>>>> Let me know if you know other way.
> >> >>>>>>
> >> >>>>>> For me method 1, is ok to do the work, but doesn't make
> us
> >> justice.
> >> >>>>>> method 2 should be the main one if there's a fast and
> easy
> >> way... I'm
> >> >>>>>> missing something here? Can users create typedefs
> themselves?
> >> >>>>>> method 3 can be useful for us or for users (doing their
> own
> >> libs, and
> >> >>>>>> eventually can share with us to add to official royale
> repo
> >> and sdk)
> >> >>>>>> but is something not fast at all and not as convenient
> and
> >> direct as
> >> >>>>> method
> >> >>>>>> 2, and will require maintenance as libs change.
> >> >>>>>>
> >> >>>>>> Could we agree that this is the currently available ways
> in
> >> Royale now
> >> >>>>> to
> >> >>>>>> use external JS libs?
> >> >>>>>>
> >> >>>>>> thanks
> >> >>>>>>
> >> >>>>>> --
> >> >>>>>> Carlos Rovira
> >> >>>>>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550849329&sdata=Y4KEWA%2BiX8w0X8ERfqU5%2FzVlAoEIm8XeEkCowIeRC4Y%3D&reserved=0
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>>> --
> >> >>>> Carlos Rovira
> >> >>>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550859338&sdata=0jc3vowPhWNFT3kVOO40WG55yfBxqosrg10bfeckpDE%3D&reserved=0
> >> >>>>
> >> >>>>
> >> >>>
> >> >>> --
> >> >>> Carlos Rovira
> >> >>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550859338&sdata=0jc3vowPhWNFT3kVOO40WG55yfBxqosrg10bfeckpDE%3D&reserved=0
> >> >>>
> >> >>>
> >> >>>
> >> >>
> >>
> >>
> >>
> >>
> >
> > --
> > Carlos Rovira
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550859338&sdata=0jc3vowPhWNFT3kVOO40WG55yfBxqosrg10bfeckpDE%3D&reserved=0
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550859338&sdata=0jc3vowPhWNFT3kVOO40WG55yfBxqosrg10bfeckpDE%3D&reserved=0
>
>
>
