Thanks Alex and Josh,
that worked! :)
I'll be explaining that in blog example so people is aware they can't use
package in this case :)
thanks!

El jue., 2 may. 2019 a las 19:57, Josh Tynjala (<[email protected]>)
escribió:

> 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://paste.apache.org/khVI
>
> 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&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
> > >
> > >
> > >
> >
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Reply via email to