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&data=02%7C01%7Caharui%40adobe.com%7C91b9c474703f4878a7b408d6cf18e064%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924103085455525&sdata=J8d1PlqvyFfdIqVdpH0y%2FaXV%2BZzoYxm3w6Q9eo%2BIH7c%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 <[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&data=02%7C01%7Caharui%40adobe.com%7C91b9c474703f4878a7b408d6cf18e064%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924103085455525&sdata=OsyQPnn3ssPp8pErMDXuknTLLiy0HOaMolUbNiOh8Cw%3D&reserved=0
>     >> >
>     >>
>     >
>     >
>     > --
>     > Carlos Rovira
>     > 
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C91b9c474703f4878a7b408d6cf18e064%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924103085455525&sdata=OsyQPnn3ssPp8pErMDXuknTLLiy0HOaMolUbNiOh8Cw%3D&reserved=0
>     >
>     >
>     
>     -- 
>     Carlos Rovira
>     
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C91b9c474703f4878a7b408d6cf18e064%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924103085455525&sdata=OsyQPnn3ssPp8pErMDXuknTLLiy0HOaMolUbNiOh8Cw%3D&reserved=0
>     
> 
> 

Reply via email to