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" <[email protected]> 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&amp;data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550849329&amp;sdata=Ly6nMG8kCFvf2Dl4PCohbV8T9MPU%2F7OV2CaYrQNFXnY%3D&amp;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&amp;data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550849329&amp;sdata=C512YPiiwRTU909ZEV5dOT94FELRDVSqm4mNYt58fLY%3D&amp;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 (<[email protected]>)
    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 (<[email protected]>)
    > 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" <[email protected]> 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 <[email protected]>
    >> 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&amp;data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550849329&amp;sdata=E%2BzcgdC3TLRNC%2FL8IfXSeXQZslQJP7pEMcL5z%2FpcV3g%3D&amp;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 <[email protected]>
    >> 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 <[email protected]>
    >> 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" <[email protected]>
    >> 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 (<
    >> [email protected]>)
    >>     >>>    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 (<
    >> [email protected]>)
    >>     >>>> 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&amp;data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550849329&amp;sdata=hyGPtFg919vlEreGs9E7OqkqRcSHImOIGt8Mt5FNfaI%3D&amp;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 <[email protected]>
    >> 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&amp;data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550849329&amp;sdata=Y4KEWA%2BiX8w0X8ERfqU5%2FzVlAoEIm8XeEkCowIeRC4Y%3D&amp;reserved=0
    >>     >>>>>>
    >>     >>>>>
    >>     >>>>
    >>     >>>>
    >>     >>>> --
    >>     >>>> Carlos Rovira
    >>     >>>>
    >> 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550859338&amp;sdata=0jc3vowPhWNFT3kVOO40WG55yfBxqosrg10bfeckpDE%3D&amp;reserved=0
    >>     >>>>
    >>     >>>>
    >>     >>>
    >>     >>>    --
    >>     >>>    Carlos Rovira
    >>     >>>
    >> 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550859338&amp;sdata=0jc3vowPhWNFT3kVOO40WG55yfBxqosrg10bfeckpDE%3D&amp;reserved=0
    >>     >>>
    >>     >>>
    >>     >>>
    >>     >>
    >>
    >>
    >>
    >>
    >
    > --
    > Carlos Rovira
    > 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550859338&amp;sdata=0jc3vowPhWNFT3kVOO40WG55yfBxqosrg10bfeckpDE%3D&amp;reserved=0
    >
    >
    
    -- 
    Carlos Rovira
    
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550859338&amp;sdata=0jc3vowPhWNFT3kVOO40WG55yfBxqosrg10bfeckpDE%3D&amp;reserved=0
    

Reply via email to