You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Carlos Rovira <ca...@apache.org> on 2019/05/02 16:11:19 UTC
Using @extrens ( RE: Example of access external JS using Apache Royale)
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 (<ca...@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 (<jo...@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://paste.apache.org/dIq0
>>
>> 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 <ca...@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
>> > http://about.me/carlosrovira
>> >
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
Posted by Carlos Rovira <ca...@apache.org>.
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 (<jo...@apache.org>)
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 <jo...@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 <ah...@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" <ca...@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 (<
> carlosrovira@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 (<
> joshtynjala@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%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 <ca...@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%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
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
Posted by Carlos Rovira <ca...@apache.org>.
Hi Dany,
I only see TS convenient to gain more audience making TS a first language
side to side with AS3, so people could code in TS his royale projects
and/or AS3/MXML. But adding TS to Royale will require someone to make it
happen, and the effort will be significative, so I don't expect this to
happen, at least in the near term.
For the actual discussion about trying to use it to import JS, I think if
the code people need is in TS, they can always transpile to JS and then use
the ways exposed here to use it. But I think is not interesting at least
from my point of view to make Royale deal with TS. Or at least the effort
involved seems very huge compared to what you'll get.
El jue., 2 may. 2019 a las 20:24, Dany Dhondt (<ar...@mac.com.invalid>)
escribió:
> 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 <jo...@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://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 <jo...@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 <ah...@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" <ca...@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 (<
> carlosrovira@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 (<
> joshtynjala@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%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 <ca...@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%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
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
Posted by Josh Tynjala <jo...@apache.org>.
Yes, it's possible to create for Node.js typedefs in that style. For instance, here are a couple of typedefs for Node.js modules that I needed in my asconfigc tool (which builds vscode-as3mxml projects from the command line):
https://github.com/BowlerHatLLC/asconfigc/blob/master/externs/minimist/src/minimist.as
https://github.com/BowlerHatLLC/asconfigc/blob/master/externs/mkdirp/src/mkdirp.as
These use special [JSModule] metadata that the Royale compiler understands. If a typedef with @externs also has [JSModule], the compiler will add a CommonJS require() call in the generated JavaScript:
var minimist = require("minimist");
Other JS module types could potentially be supported, but CommonJS is all that I got around to implementing.
- Josh
On 2019/05/02 18:17:49, Dany Dhondt <ar...@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 <jo...@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://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 <jo...@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 <ah...@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" <ca...@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 (<ca...@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 (<jo...@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%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 <ca...@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%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
> >>>
> >>>
> >>>
> >>
>
>
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
Posted by Kenny Lerma <ke...@kennylerma.com>.
This is something I also ran into while converting my projects.
I would be great if we had a class tag to allow generic properties and
methods as is the case with MovieClip in flash.
Currently, you can get around this by setting the -strict flag to false,
but you lose a lot of error checking from the compiler.
I'm hoping we can add something like this in the future since a lot of
flash projects often make use of the generic properties and I would like to
add this to MovieClip in SpriteFlexjs.
FYI Object(indicator_content).animate also works.
Kenny
On Fri, May 3, 2019 at 5:39 PM Josh Tynjala <jo...@apache.org> wrote:
> ActionScript does not provide a mechanism for taking an existing class and
> adding new methods or properties to it.
>
> In this case, I don't think you have any other option than to use bracket
> syntax, like indicator_content["animate"].
>
> - Josh
>
> On 2019/05/03 21:08:56, Carlos Rovira <ca...@apache.org> wrote:
> > Another more question I just found and don't know how to solve.
> >
> > if I have a polyfill like Web Animations API that adds "animate" method
> to
> > any Element object.
> > Can someone post an example of an @extern file for a case like this? I
> > don't imagine right now how can this be done, and maybe right not it
> can't
> > be done.
> >
> > Example code I'm using now with brackets notation is:
> >
> > indicator_content["animate"]({ <this is an object with animation data to
> > pass to animate method> });
> >
> > so I want royale user can do instead:
> >
> > indicator_content.animate({...});
> >
> > thanks
> >
> > El vie., 3 may. 2019 a las 23:03, Carlos Rovira (<
> carlosrovira@apache.org>)
> > escribió:
> >
> > > Hi,
> > >
> > > I now Greg is busy now with an important update
> > > I can try to do it myself if Alex point me to the code I should look,
> for
> > > me it would be part of the task to make this blog example in the best
> way
> > > possible.
> > > thanks
> > >
> > > El vie., 3 may. 2019 a las 22:58, Greg Dove (<gr...@gmail.com>)
> > > escribió:
> > >
> > >> '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 <ah...@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" <ca...@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 (<
> > >> > carlosrovira@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
> > >> > (<ah...@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"
> <ar...@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 <
> > >> > joshtynjala@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 <
> > >> joshtynjala@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
> > >> <aharui@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" <
> > >> > carlosrovira@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 (<
> > >> > >> carlosrovira@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 (<
> > >> > >> joshtynjala@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 <
> > >> > carlosrovira@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
> > >> >
> > >> >
> > >> >
> > >>
> > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> > >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
Re: Using @extrens ( RE: Example of access external JS using Apache
Royale)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi,
IMO, new "standardized" browser features will eventually show up in js.swc because they'll show up in the Google Closure's externs. We can put those in the js.swc's missing.js in the interim.
AIUI, 3rd-parties add other things to the prototypes that are not standardized. If those are not called "polyfills", fine. I would recommend those things not be added to missing.js, but as a separate typedefs SWC.
Either way, both scenarios should be presented to the app developer the same way for PAYG reasons. We should focus on PAYG and composition instead of inheritance and not lose sight of our desire to deal with other runtimes/platforms someday.
So, instead of adding an "animate" API to UIBase or IUIBase, we should have an Animate bead. The Animate bead's JS code can call element.animate if we've added it to missing.js, but I'd like us to find some other pattern for non-standardized APIs otherwise missing.js will eventually hold every 3rd-party prototype hack ever invented. I'd suggest that, like HTMLElementWrapper/element/positioner, maybe we should create an HTMLElementAnimateWrapper.
Or something like that.
My 2 cents,
-Alex
On 5/5/19, 6:53 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi,
I agree in most of the points explained here, but want to expose a point
that maybe will change this particular case.
A Polyfill for me is a JS implementation of an API that will be part of all
browsers natively, and use to be already implemented by 1 or 2 browsers,
but not for all the most important ones. So to be able to use actually
people use a JS implementation until all browsers implement it.
So the bead approach is ok to me when we implement things to be supported
cross targets, and we can create a bead for animation and in JS do
strand["animate"], but still would want JS (through Royale) could make a
dot access and not that kind of bracket access that seems to me not what
people should end to do.
In this case we are talking to a new Element API, so I was figuring is this
could be added vía prototype something like:
Element.prototype.animate
I see lots of this in typedefs
and we should not forget that animate method is coming vía Web Animations
API, so I think is something sooner or later we'll be on the HTML apis
So for me there's two separate things, one make a bead implementation to
ensure cross target consistency in APIs, and other, in this case centered
on HTML target, how to deal with a new API that will be part of all
browsers to support it sooner vía pollyfill.
(Notice that we still need to add @keyframe to CSS parsing in Royale that
is still unsupported, and this is the way to do the same as animate vía CSS)
thoughts?
El dom., 5 may. 2019 a las 14:02, Yishay Weiss (<yi...@hotmail.com>)
escribió:
>
> >if you can get yourself away from trying to access features on concrete
> instances
> (…)
>
> >var animateBead:IAnimateBead =
> indicator_content.getBeadByType(IAnimateBead);
> >animateBead.animate();
>
> Is this PAYG? getBeadByType iterates through an array.
> Also, animateBead may turn out to be null which adds a level of
> uncertainty as to whether or not this will run.
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce6ca6613bd5a4315d99108d6d16104ac%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636926611965222777&sdata=n7yCDIWT3QYtHMTHNNDoy%2FZYau5D6w3gGWJwQMAejhg%3D&reserved=0
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
Posted by Carlos Rovira <ca...@apache.org>.
Hi,
I agree in most of the points explained here, but want to expose a point
that maybe will change this particular case.
A Polyfill for me is a JS implementation of an API that will be part of all
browsers natively, and use to be already implemented by 1 or 2 browsers,
but not for all the most important ones. So to be able to use actually
people use a JS implementation until all browsers implement it.
So the bead approach is ok to me when we implement things to be supported
cross targets, and we can create a bead for animation and in JS do
strand["animate"], but still would want JS (through Royale) could make a
dot access and not that kind of bracket access that seems to me not what
people should end to do.
In this case we are talking to a new Element API, so I was figuring is this
could be added vía prototype something like:
Element.prototype.animate
I see lots of this in typedefs
and we should not forget that animate method is coming vía Web Animations
API, so I think is something sooner or later we'll be on the HTML apis
So for me there's two separate things, one make a bead implementation to
ensure cross target consistency in APIs, and other, in this case centered
on HTML target, how to deal with a new API that will be part of all
browsers to support it sooner vía pollyfill.
(Notice that we still need to add @keyframe to CSS parsing in Royale that
is still unsupported, and this is the way to do the same as animate vía CSS)
thoughts?
El dom., 5 may. 2019 a las 14:02, Yishay Weiss (<yi...@hotmail.com>)
escribió:
>
> >if you can get yourself away from trying to access features on concrete
> instances
> (…)
>
> >var animateBead:IAnimateBead =
> indicator_content.getBeadByType(IAnimateBead);
> >animateBead.animate();
>
> Is this PAYG? getBeadByType iterates through an array.
> Also, animateBead may turn out to be null which adds a level of
> uncertainty as to whether or not this will run.
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Using @extrens ( RE: Example of access external JS using Apache
Royale)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 5/7/19, 1:37 AM, "Yishay Weiss" <yi...@hotmail.com> wrote:
I still have a feeling newcomers to Royale will be asking for readymade TLCs and that it’s important to have them available. Whether or not they should be an included in the SDK I’m not sure. Different topic I suppose.
Definitely, folks will want ready-made TLCs. TLCs should be one of the easiest things to contribute as pretty much all that is inside one is proxying to beads. So the hope is that others will contribute these TLCs or post them on their own web properties and maybe even sell them for money.
Royale is less about being a particular component set and more about a tool chain for application developer productivity. Those productivity gains come from encapsulating popular JS/HTML/CSS patterns into beads and packaging popular sets of beads into TLCs.
HTH,
-Alex
RE: Using @extrens ( RE: Example of access external JS using Apache
Royale)
Posted by Yishay Weiss <yi...@hotmail.com>.
So to sum up this slightly off-topic discussion, instead of JewelGroup implementing IClassSelectorListSupport we can have a bead called ClassSelectorListSupport.
Application developers will be able to call group.getBeadByType(IClassSelectorListSupport) as IClassSelectorListSupport).addClass() or if declared with
<Group><beads><ClassSelectorListSupport id=”classSelectorSupport”/></beads></Group>, simply classSelectorSupportList.addClass().
We expect a dev team using Royale to have some knowledge about beads and strands so they can create TLCs for the application developers which will make this even simpler and more Flex/Express like.
I still have a feeling newcomers to Royale will be asking for readymade TLCs and that it’s important to have them available. Whether or not they should be an included in the SDK I’m not sure. Different topic I suppose.
________________________________
From: Alex Harui <ah...@adobe.com.INVALID>
Sent: Monday, May 6, 2019 6:48:18 PM
To: dev@royale.apache.org
Subject: Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
Hi Yishay,
IMO, there are application developers (users) and component developers. Some folks will be both. Component developers do pay for lots of things in Royale in order to make reusable components. We do want to make it easy for application developers can make "one-off" components. Component developers will have to understand composition vs inheritance, PAYG, and if we're lucky, cross-platform/runtime differences. And we want the component developers to do that to make life easier for the application developer.
The application developer should be able to call tlc.method() almost all of the time because enough people needed to call (strand.getBeadByType(Functionality) as Functionality).method() so frequently that some component developer took the time to create a TLC and proxy that call to the API surface. If you look at our TLCs today, that's pretty much all they do. Royale is essentially about finding the repeating patterns that application developers need and packaging them up in a way that improves their productivity.
The cool thing is that the application developer can re-compose the beads in a component if they need to in MXML and then access the bead directly just by giving it an id/localid. They won't really need to call getBeadByType.
<js:TLC>
<js:bead>
<js:ReplacementModel id="replacementModel" />
...
</js:TLC>
<fx:Script>
replacementModel.data = "foo";
</fx:Script>
No need to learn how to subclass or take the time to subclass something just to re-compose a single instance of something. Plug-in the replacement, give it an id and continue on. If IDE's can't code hint that today, I think they should be able to. It is pretty explicit/declarative, and we can add metadata to enhance code-assist at no cost to runtime.
I don't understand your argument about null checks. IMO, even "is" tests have to check for null. If your point is that we can use @royaleignorecoercion to skip the "is" tests, then yes, that's true. Composition does have a cost. Things composed of lots of little pieces will weigh more than the thing with everything mixed together, but you can always inline the beads to save on those costs.
As a reminder, the reason I am so picky about PAYG and composition is because I watched Flex suffer from the lack of PAYG and loose-coupling and composition and I do not want us to go down that road again.
HTH,
-Alex
On 5/5/19, 11:44 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
I understand that this is PAYG in terms of code size. My concern is that we’re paying in other ways for this composition pattern.
We’re reducing code size but increasing complexity (user needs to check for null before calling a method). Also, IDEs may have a hard time hinting for beads that may or may not exist. I agree that the performance issue can probably be mitigated with caching or something.
I’m raising this issue so we can agree on a way to write components. Should users be expected to make calls with (strand.getBeadByType(Functionality) as Functionality).method() or tlc.method(). I’m pretty sure users will prefer the latter so I guess the compromise is to create TLCs that internally load beads.
Thoughts?
________________________________
From: Alex Harui <ah...@adobe.com.INVALID>
Sent: Monday, May 6, 2019 9:02:18 AM
To: dev@royale.apache.org
Subject: Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
IMO, it is PAYG. There is no cost until you use it, since getBeadByType is part of the IStrand implementation.
In a true implementation, you would test for animateBead == null if you expect that it can be null, since that would be handling the "has not" case.
If your concern is performance, as in, how slow is it to call getBeadByType()? That's a different and legitimate question. I'm mainly trying to point out that the "has" question is possible in a composition-oriented framework and is more flexible than requiring "is" (which results in increased code size as the TLC has to implement some interface. The performance hit would depend on how many places in the code need to ask "has" and how often. It might be/should be possible to optimize IStrand if we know that getBeadByType is being called often, with the usual trade-offs on code size. All we need is some folks to try it and do some measurements.
My 2 cents,
-Alex
On 5/5/19, 5:03 AM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>if you can get yourself away from trying to access features on concrete instances
(…)
>var animateBead:IAnimateBead = indicator_content.getBeadByType(IAnimateBead);
>animateBead.animate();
Is this PAYG? getBeadByType iterates through an array.
Also, animateBead may turn out to be null which adds a level of uncertainty as to whether or not this will run.
Re: Using @extrens ( RE: Example of access external JS using Apache
Royale)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Yishay,
IMO, there are application developers (users) and component developers. Some folks will be both. Component developers do pay for lots of things in Royale in order to make reusable components. We do want to make it easy for application developers can make "one-off" components. Component developers will have to understand composition vs inheritance, PAYG, and if we're lucky, cross-platform/runtime differences. And we want the component developers to do that to make life easier for the application developer.
The application developer should be able to call tlc.method() almost all of the time because enough people needed to call (strand.getBeadByType(Functionality) as Functionality).method() so frequently that some component developer took the time to create a TLC and proxy that call to the API surface. If you look at our TLCs today, that's pretty much all they do. Royale is essentially about finding the repeating patterns that application developers need and packaging them up in a way that improves their productivity.
The cool thing is that the application developer can re-compose the beads in a component if they need to in MXML and then access the bead directly just by giving it an id/localid. They won't really need to call getBeadByType.
<js:TLC>
<js:bead>
<js:ReplacementModel id="replacementModel" />
...
</js:TLC>
<fx:Script>
replacementModel.data = "foo";
</fx:Script>
No need to learn how to subclass or take the time to subclass something just to re-compose a single instance of something. Plug-in the replacement, give it an id and continue on. If IDE's can't code hint that today, I think they should be able to. It is pretty explicit/declarative, and we can add metadata to enhance code-assist at no cost to runtime.
I don't understand your argument about null checks. IMO, even "is" tests have to check for null. If your point is that we can use @royaleignorecoercion to skip the "is" tests, then yes, that's true. Composition does have a cost. Things composed of lots of little pieces will weigh more than the thing with everything mixed together, but you can always inline the beads to save on those costs.
As a reminder, the reason I am so picky about PAYG and composition is because I watched Flex suffer from the lack of PAYG and loose-coupling and composition and I do not want us to go down that road again.
HTH,
-Alex
On 5/5/19, 11:44 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
I understand that this is PAYG in terms of code size. My concern is that we’re paying in other ways for this composition pattern.
We’re reducing code size but increasing complexity (user needs to check for null before calling a method). Also, IDEs may have a hard time hinting for beads that may or may not exist. I agree that the performance issue can probably be mitigated with caching or something.
I’m raising this issue so we can agree on a way to write components. Should users be expected to make calls with (strand.getBeadByType(Functionality) as Functionality).method() or tlc.method(). I’m pretty sure users will prefer the latter so I guess the compromise is to create TLCs that internally load beads.
Thoughts?
________________________________
From: Alex Harui <ah...@adobe.com.INVALID>
Sent: Monday, May 6, 2019 9:02:18 AM
To: dev@royale.apache.org
Subject: Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
IMO, it is PAYG. There is no cost until you use it, since getBeadByType is part of the IStrand implementation.
In a true implementation, you would test for animateBead == null if you expect that it can be null, since that would be handling the "has not" case.
If your concern is performance, as in, how slow is it to call getBeadByType()? That's a different and legitimate question. I'm mainly trying to point out that the "has" question is possible in a composition-oriented framework and is more flexible than requiring "is" (which results in increased code size as the TLC has to implement some interface. The performance hit would depend on how many places in the code need to ask "has" and how often. It might be/should be possible to optimize IStrand if we know that getBeadByType is being called often, with the usual trade-offs on code size. All we need is some folks to try it and do some measurements.
My 2 cents,
-Alex
On 5/5/19, 5:03 AM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>if you can get yourself away from trying to access features on concrete instances
(…)
>var animateBead:IAnimateBead = indicator_content.getBeadByType(IAnimateBead);
>animateBead.animate();
Is this PAYG? getBeadByType iterates through an array.
Also, animateBead may turn out to be null which adds a level of uncertainty as to whether or not this will run.
RE: Using @extrens ( RE: Example of access external JS using Apache
Royale)
Posted by Yishay Weiss <yi...@hotmail.com>.
I understand that this is PAYG in terms of code size. My concern is that we’re paying in other ways for this composition pattern.
We’re reducing code size but increasing complexity (user needs to check for null before calling a method). Also, IDEs may have a hard time hinting for beads that may or may not exist. I agree that the performance issue can probably be mitigated with caching or something.
I’m raising this issue so we can agree on a way to write components. Should users be expected to make calls with (strand.getBeadByType(Functionality) as Functionality).method() or tlc.method(). I’m pretty sure users will prefer the latter so I guess the compromise is to create TLCs that internally load beads.
Thoughts?
________________________________
From: Alex Harui <ah...@adobe.com.INVALID>
Sent: Monday, May 6, 2019 9:02:18 AM
To: dev@royale.apache.org
Subject: Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
IMO, it is PAYG. There is no cost until you use it, since getBeadByType is part of the IStrand implementation.
In a true implementation, you would test for animateBead == null if you expect that it can be null, since that would be handling the "has not" case.
If your concern is performance, as in, how slow is it to call getBeadByType()? That's a different and legitimate question. I'm mainly trying to point out that the "has" question is possible in a composition-oriented framework and is more flexible than requiring "is" (which results in increased code size as the TLC has to implement some interface. The performance hit would depend on how many places in the code need to ask "has" and how often. It might be/should be possible to optimize IStrand if we know that getBeadByType is being called often, with the usual trade-offs on code size. All we need is some folks to try it and do some measurements.
My 2 cents,
-Alex
On 5/5/19, 5:03 AM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>if you can get yourself away from trying to access features on concrete instances
(…)
>var animateBead:IAnimateBead = indicator_content.getBeadByType(IAnimateBead);
>animateBead.animate();
Is this PAYG? getBeadByType iterates through an array.
Also, animateBead may turn out to be null which adds a level of uncertainty as to whether or not this will run.
Re: Using @extrens ( RE: Example of access external JS using Apache
Royale)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
IMO, it is PAYG. There is no cost until you use it, since getBeadByType is part of the IStrand implementation.
In a true implementation, you would test for animateBead == null if you expect that it can be null, since that would be handling the "has not" case.
If your concern is performance, as in, how slow is it to call getBeadByType()? That's a different and legitimate question. I'm mainly trying to point out that the "has" question is possible in a composition-oriented framework and is more flexible than requiring "is" (which results in increased code size as the TLC has to implement some interface. The performance hit would depend on how many places in the code need to ask "has" and how often. It might be/should be possible to optimize IStrand if we know that getBeadByType is being called often, with the usual trade-offs on code size. All we need is some folks to try it and do some measurements.
My 2 cents,
-Alex
On 5/5/19, 5:03 AM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>if you can get yourself away from trying to access features on concrete instances
(…)
>var animateBead:IAnimateBead = indicator_content.getBeadByType(IAnimateBead);
>animateBead.animate();
Is this PAYG? getBeadByType iterates through an array.
Also, animateBead may turn out to be null which adds a level of uncertainty as to whether or not this will run.
RE: Using @extrens ( RE: Example of access external JS using Apache
Royale)
Posted by Yishay Weiss <yi...@hotmail.com>.
>if you can get yourself away from trying to access features on concrete instances
(…)
>var animateBead:IAnimateBead = indicator_content.getBeadByType(IAnimateBead);
>animateBead.animate();
Is this PAYG? getBeadByType iterates through an array.
Also, animateBead may turn out to be null which adds a level of uncertainty as to whether or not this will run.
Re: Using @extrens ( RE: Example of access external JS using Apache
Royale)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
FWIW, the AVM (ActionScript Virtual Machine) has sealed classes (not modifiable at runtime) on purpose: to secure your code from hacking. Polyfills are dangerous. A good one helps, but the mere fact they work means that others can inject capabilities into your classes at runtime.
Also, consider that we want to leave the door open to target other runtimes/platforms. Many will not support polyfills and other runtime class modifications (eval).
So, while it is fine to access a polyfill via bracket syntax. And I would do so if I was in a hurry, IMO, for a more future-proof support, you should consider what the polyfill does and what is its closest language construct. Polyfills sort of mimic Aspects and/or multiple inheritance. But there is no guarantee those things are supported in all runtimes/platforms.
Another thing similar to polyfills are actually beads, if you can get yourself away from trying to access features on concrete instances (UIBase or whatever). As I mentioned upthread, use of interfaces and "has" provides more flexibility and, while I've never actually tried it, might work for polyfills as well. So, instead of assuming that a polyfill adds a property/method to an instance (yes, I know that is actually what it does), its Royale API surface can be a bead or interface. That is more code for sure, but that pattern future-proofs the Royale code.
IOW, we shouldn't really encourage people to write indicator_content["animate"]. Yes, I know they can. But we probably should encourage them to access a bead. So then you would write:
var animateBead:IAnimateBead = indicator_content.getBeadByType(IAnimateBead);
animateBead.animate();
The AnimateBead's JavaScript implementation would call strand["animate"]().
But then it makes it possible to mimic adding some animation engine at runtime on other runtimes/platforms since beads should be implementable on every runtime/platform we are interested in.
My 2 cents,
-Alex
On 5/3/19, 3:39 PM, "Josh Tynjala" <jo...@apache.org> wrote:
ActionScript does not provide a mechanism for taking an existing class and adding new methods or properties to it.
In this case, I don't think you have any other option than to use bracket syntax, like indicator_content["animate"].
- Josh
On 2019/05/03 21:08:56, Carlos Rovira <ca...@apache.org> wrote:
> Another more question I just found and don't know how to solve.
>
> if I have a polyfill like Web Animations API that adds "animate" method to
> any Element object.
> Can someone post an example of an @extern file for a case like this? I
> don't imagine right now how can this be done, and maybe right not it can't
> be done.
>
> Example code I'm using now with brackets notation is:
>
> indicator_content["animate"]({ <this is an object with animation data to
> pass to animate method> });
>
> so I want royale user can do instead:
>
> indicator_content.animate({...});
>
> thanks
>
> El vie., 3 may. 2019 a las 23:03, Carlos Rovira (<ca...@apache.org>)
> escribió:
>
> > Hi,
> >
> > I now Greg is busy now with an important update
> > I can try to do it myself if Alex point me to the code I should look, for
> > me it would be part of the task to make this blog example in the best way
> > possible.
> > thanks
> >
> > El vie., 3 may. 2019 a las 22:58, Greg Dove (<gr...@gmail.com>)
> > escribió:
> >
> >> '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 <ah...@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" <ca...@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%7C2ffc116355b14bd2667708d6d0183019%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925199649559063&sdata=QRYYGpcZx5oBdEwa%2BMHOiTWxgLIpoXhzRRsFe3L4ctU%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%7C2ffc116355b14bd2667708d6d0183019%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925199649559063&sdata=KhyWmwmUnES0f7P7BJXgUg08oyW9iUZmJqmMOhM%2Bbac%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 (<
> >> > carlosrovira@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
> >> > (<ah...@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" <ar...@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 <
> >> > joshtynjala@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%7C2ffc116355b14bd2667708d6d0183019%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925199649559063&sdata=HWvr1rRp8wS2Xr9Ca2J%2BZe9t3pBTx%2FoWP2AeWYM5C50%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 <
> >> joshtynjala@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
> >> <aharui@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" <
> >> > carlosrovira@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 (<
> >> > >> carlosrovira@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 (<
> >> > >> joshtynjala@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%7C2ffc116355b14bd2667708d6d0183019%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925199649559063&sdata=e7eVL0od3je0k9CR7f%2FPqgE94Wu67pQ0PzU3VCYGUlA%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 <
> >> > carlosrovira@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%7C2ffc116355b14bd2667708d6d0183019%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925199649569068&sdata=gQuv7RVxp1jF6%2BC%2FJa1c4mjvU31wIxEQNSW%2B3ugKTF8%3D&reserved=0
> >> > >> >>>>>>
> >> > >> >>>>>
> >> > >> >>>>
> >> > >> >>>>
> >> > >> >>>> --
> >> > >> >>>> Carlos Rovira
> >> > >> >>>>
> >> > >>
> >> >
> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2ffc116355b14bd2667708d6d0183019%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925199649569068&sdata=gQuv7RVxp1jF6%2BC%2FJa1c4mjvU31wIxEQNSW%2B3ugKTF8%3D&reserved=0
> >> > >> >>>>
> >> > >> >>>>
> >> > >> >>>
> >> > >> >>> --
> >> > >> >>> Carlos Rovira
> >> > >> >>>
> >> > >>
> >> >
> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2ffc116355b14bd2667708d6d0183019%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925199649569068&sdata=gQuv7RVxp1jF6%2BC%2FJa1c4mjvU31wIxEQNSW%2B3ugKTF8%3D&reserved=0
> >> > >> >>>
> >> > >> >>>
> >> > >> >>>
> >> > >> >>
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >
> >> > > --
> >> > > Carlos Rovira
> >> > >
> >> >
> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2ffc116355b14bd2667708d6d0183019%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925199649569068&sdata=gQuv7RVxp1jF6%2BC%2FJa1c4mjvU31wIxEQNSW%2B3ugKTF8%3D&reserved=0
> >> > >
> >> > >
> >> >
> >> > --
> >> > Carlos Rovira
> >> >
> >> >
> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2ffc116355b14bd2667708d6d0183019%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925199649569068&sdata=gQuv7RVxp1jF6%2BC%2FJa1c4mjvU31wIxEQNSW%2B3ugKTF8%3D&reserved=0
> >> >
> >> >
> >> >
> >>
> >
> >
> > --
> > Carlos Rovira
> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2ffc116355b14bd2667708d6d0183019%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925199649569068&sdata=gQuv7RVxp1jF6%2BC%2FJa1c4mjvU31wIxEQNSW%2B3ugKTF8%3D&reserved=0
> >
> >
>
> --
> Carlos Rovira
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2ffc116355b14bd2667708d6d0183019%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925199649569068&sdata=gQuv7RVxp1jF6%2BC%2FJa1c4mjvU31wIxEQNSW%2B3ugKTF8%3D&reserved=0
>
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
Posted by Josh Tynjala <jo...@apache.org>.
ActionScript does not provide a mechanism for taking an existing class and adding new methods or properties to it.
In this case, I don't think you have any other option than to use bracket syntax, like indicator_content["animate"].
- Josh
On 2019/05/03 21:08:56, Carlos Rovira <ca...@apache.org> wrote:
> Another more question I just found and don't know how to solve.
>
> if I have a polyfill like Web Animations API that adds "animate" method to
> any Element object.
> Can someone post an example of an @extern file for a case like this? I
> don't imagine right now how can this be done, and maybe right not it can't
> be done.
>
> Example code I'm using now with brackets notation is:
>
> indicator_content["animate"]({ <this is an object with animation data to
> pass to animate method> });
>
> so I want royale user can do instead:
>
> indicator_content.animate({...});
>
> thanks
>
> El vie., 3 may. 2019 a las 23:03, Carlos Rovira (<ca...@apache.org>)
> escribió:
>
> > Hi,
> >
> > I now Greg is busy now with an important update
> > I can try to do it myself if Alex point me to the code I should look, for
> > me it would be part of the task to make this blog example in the best way
> > possible.
> > thanks
> >
> > El vie., 3 may. 2019 a las 22:58, Greg Dove (<gr...@gmail.com>)
> > escribió:
> >
> >> '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 <ah...@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" <ca...@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 (<
> >> > carlosrovira@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
> >> > (<ah...@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" <ar...@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 <
> >> > joshtynjala@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 <
> >> joshtynjala@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
> >> <aharui@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" <
> >> > carlosrovira@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 (<
> >> > >> carlosrovira@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 (<
> >> > >> joshtynjala@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 <
> >> > carlosrovira@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
> >> >
> >> >
> >> >
> >>
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
> >
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
Posted by Carlos Rovira <ca...@apache.org>.
Another more question I just found and don't know how to solve.
if I have a polyfill like Web Animations API that adds "animate" method to
any Element object.
Can someone post an example of an @extern file for a case like this? I
don't imagine right now how can this be done, and maybe right not it can't
be done.
Example code I'm using now with brackets notation is:
indicator_content["animate"]({ <this is an object with animation data to
pass to animate method> });
so I want royale user can do instead:
indicator_content.animate({...});
thanks
El vie., 3 may. 2019 a las 23:03, Carlos Rovira (<ca...@apache.org>)
escribió:
> Hi,
>
> I now Greg is busy now with an important update
> I can try to do it myself if Alex point me to the code I should look, for
> me it would be part of the task to make this blog example in the best way
> possible.
> thanks
>
> El vie., 3 may. 2019 a las 22:58, Greg Dove (<gr...@gmail.com>)
> escribió:
>
>> '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 <ah...@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" <ca...@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 (<
>> > carlosrovira@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
>> > (<ah...@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" <ar...@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 <
>> > joshtynjala@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 <
>> joshtynjala@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
>> <aharui@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" <
>> > carlosrovira@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 (<
>> > >> carlosrovira@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 (<
>> > >> joshtynjala@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 <
>> > carlosrovira@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
>> >
>> >
>> >
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
Posted by Carlos Rovira <ca...@apache.org>.
I put hljs.as class in a library, and in doing that hljs.as is
processed in GoogDepsWriter
and inject_html is pulled from that @externs class. This solve the problem
from that point.
So the real problem here is: If users has @externs classes in the
Application project, then they will get another processing different to
have this one in a library. And inject_html is not processed and, another
thing: source map file is generated when the externs class is in
Application project (while I removed creating in a recent commit).
Do you know some way to fix this problem in the best way?
thanks
El lun., 3 jun. 2019 a las 16:13, Carlos Rovira (<ca...@apache.org>)
escribió:
> Hi Alex,
>
> trying to make inject_html work for @externs classes.
> I'm seeing that GoogDepsWriter are not processing hljs.as extern class in
> my B012 example, that is located directly in top level package.
> I output with println all getFileInfo() classes there and hljs is not part
> of that set. Maybe is only processing @extern classes inside libraries?
> in this case the @externs class is located in the Application project.
>
> I'm going to see if I can get it's processed in other part and try to read
> from there the inject_html
>
> Just want to inform since could be something by design or not wanted effect
>
> thanks
>
> Carlos
>
>
> El sáb., 4 may. 2019 a las 5:36, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
>> I just searched the compiler code. Current inject_html handling appears
>> to be in GoogDepsWriter.java.
>>
>> On 5/3/19, 2:04 PM, "Carlos Rovira" <ca...@apache.org> wrote:
>>
>> Hi,
>>
>> I now Greg is busy now with an important update
>> I can try to do it myself if Alex point me to the code I should look,
>> for
>> me it would be part of the task to make this blog example in the best
>> way
>> possible.
>> thanks
>>
>> El vie., 3 may. 2019 a las 22:58, Greg Dove (<gr...@gmail.com>)
>> escribió:
>>
>> > '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 <aharui@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" <ca...@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%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=ubvldliTsViH69h%2FGeKby02C8H%2BKJ7HtblUo7dCnbrk%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%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=uBI0vW721xJqBH2I%2FuUrq92KIu2Vgf6YzcrOXEFGLHM%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 (<
>> > > carlosrovira@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
>> > > (<ah...@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"
>> <ar...@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 <
>> > > joshtynjala@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%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=nfefmf7ErxCMnNeY2UPTyFQ5BG%2BOPHyTtS4vZ1ea14Q%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 <
>> > joshtynjala@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
>> > <aharui@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" <
>> > > carlosrovira@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
>> (<
>> > > >> carlosrovira@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 (<
>> > > >> joshtynjala@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%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=ogITciULRUGWvwRsTg9kw68vqr5pCfcsgm8AC%2F6W0Kw%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 <
>> > > carlosrovira@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%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=yJoOS7qX8F%2BNfgKgjRCT97W5t2c1DEVRAyJ%2ByHahD90%3D&reserved=0
>> > > >> >>>>>>
>> > > >> >>>>>
>> > > >> >>>>
>> > > >> >>>>
>> > > >> >>>> --
>> > > >> >>>> Carlos Rovira
>> > > >> >>>>
>> > > >>
>> > >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=yJoOS7qX8F%2BNfgKgjRCT97W5t2c1DEVRAyJ%2ByHahD90%3D&reserved=0
>> > > >> >>>>
>> > > >> >>>>
>> > > >> >>>
>> > > >> >>> --
>> > > >> >>> Carlos Rovira
>> > > >> >>>
>> > > >>
>> > >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=yJoOS7qX8F%2BNfgKgjRCT97W5t2c1DEVRAyJ%2ByHahD90%3D&reserved=0
>> > > >> >>>
>> > > >> >>>
>> > > >> >>>
>> > > >> >>
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >
>> > > > --
>> > > > Carlos Rovira
>> > > >
>> > >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602112444&sdata=Ata%2BBbvYb4O9GX%2FzRS6qkcF7DcNCTfSC4C%2BqdNWW2U4%3D&reserved=0
>> > > >
>> > > >
>> > >
>> > > --
>> > > Carlos Rovira
>> > >
>> > >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602112444&sdata=Ata%2BBbvYb4O9GX%2FzRS6qkcF7DcNCTfSC4C%2BqdNWW2U4%3D&reserved=0
>> > >
>> > >
>> > >
>> >
>>
>>
>> --
>> Carlos Rovira
>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602112444&sdata=Ata%2BBbvYb4O9GX%2FzRS6qkcF7DcNCTfSC4C%2BqdNWW2U4%3D&reserved=0
>>
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
trying to make inject_html work for @externs classes.
I'm seeing that GoogDepsWriter are not processing hljs.as extern class in
my B012 example, that is located directly in top level package.
I output with println all getFileInfo() classes there and hljs is not part
of that set. Maybe is only processing @extern classes inside libraries?
in this case the @externs class is located in the Application project.
I'm going to see if I can get it's processed in other part and try to read
from there the inject_html
Just want to inform since could be something by design or not wanted effect
thanks
Carlos
El sáb., 4 may. 2019 a las 5:36, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> I just searched the compiler code. Current inject_html handling appears
> to be in GoogDepsWriter.java.
>
> On 5/3/19, 2:04 PM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi,
>
> I now Greg is busy now with an important update
> I can try to do it myself if Alex point me to the code I should look,
> for
> me it would be part of the task to make this blog example in the best
> way
> possible.
> thanks
>
> El vie., 3 may. 2019 a las 22:58, Greg Dove (<gr...@gmail.com>)
> escribió:
>
> > '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 <ah...@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" <ca...@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%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=ubvldliTsViH69h%2FGeKby02C8H%2BKJ7HtblUo7dCnbrk%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%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=uBI0vW721xJqBH2I%2FuUrq92KIu2Vgf6YzcrOXEFGLHM%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 (<
> > > carlosrovira@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
> > > (<ah...@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"
> <ar...@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 <
> > > joshtynjala@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%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=nfefmf7ErxCMnNeY2UPTyFQ5BG%2BOPHyTtS4vZ1ea14Q%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 <
> > joshtynjala@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
> > <aharui@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" <
> > > carlosrovira@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
> (<
> > > >> carlosrovira@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 (<
> > > >> joshtynjala@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%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=ogITciULRUGWvwRsTg9kw68vqr5pCfcsgm8AC%2F6W0Kw%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 <
> > > carlosrovira@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%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=yJoOS7qX8F%2BNfgKgjRCT97W5t2c1DEVRAyJ%2ByHahD90%3D&reserved=0
> > > >> >>>>>>
> > > >> >>>>>
> > > >> >>>>
> > > >> >>>>
> > > >> >>>> --
> > > >> >>>> Carlos Rovira
> > > >> >>>>
> > > >>
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=yJoOS7qX8F%2BNfgKgjRCT97W5t2c1DEVRAyJ%2ByHahD90%3D&reserved=0
> > > >> >>>>
> > > >> >>>>
> > > >> >>>
> > > >> >>> --
> > > >> >>> Carlos Rovira
> > > >> >>>
> > > >>
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=yJoOS7qX8F%2BNfgKgjRCT97W5t2c1DEVRAyJ%2ByHahD90%3D&reserved=0
> > > >> >>>
> > > >> >>>
> > > >> >>>
> > > >> >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > > --
> > > > Carlos Rovira
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602112444&sdata=Ata%2BBbvYb4O9GX%2FzRS6qkcF7DcNCTfSC4C%2BqdNWW2U4%3D&reserved=0
> > > >
> > > >
> > >
> > > --
> > > Carlos Rovira
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602112444&sdata=Ata%2BBbvYb4O9GX%2FzRS6qkcF7DcNCTfSC4C%2BqdNWW2U4%3D&reserved=0
> > >
> > >
> > >
> >
>
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602112444&sdata=Ata%2BBbvYb4O9GX%2FzRS6qkcF7DcNCTfSC4C%2BqdNWW2U4%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Using @extrens ( RE: Example of access external JS using Apache
Royale)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I just searched the compiler code. Current inject_html handling appears to be in GoogDepsWriter.java.
On 5/3/19, 2:04 PM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi,
I now Greg is busy now with an important update
I can try to do it myself if Alex point me to the code I should look, for
me it would be part of the task to make this blog example in the best way
possible.
thanks
El vie., 3 may. 2019 a las 22:58, Greg Dove (<gr...@gmail.com>)
escribió:
> '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 <ah...@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" <ca...@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%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=ubvldliTsViH69h%2FGeKby02C8H%2BKJ7HtblUo7dCnbrk%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%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=uBI0vW721xJqBH2I%2FuUrq92KIu2Vgf6YzcrOXEFGLHM%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 (<
> > carlosrovira@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
> > (<ah...@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" <ar...@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 <
> > joshtynjala@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%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=nfefmf7ErxCMnNeY2UPTyFQ5BG%2BOPHyTtS4vZ1ea14Q%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 <
> joshtynjala@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
> <aharui@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" <
> > carlosrovira@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 (<
> > >> carlosrovira@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 (<
> > >> joshtynjala@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%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=ogITciULRUGWvwRsTg9kw68vqr5pCfcsgm8AC%2F6W0Kw%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 <
> > carlosrovira@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%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=yJoOS7qX8F%2BNfgKgjRCT97W5t2c1DEVRAyJ%2ByHahD90%3D&reserved=0
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>>
> > >> >>>> --
> > >> >>>> Carlos Rovira
> > >> >>>>
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=yJoOS7qX8F%2BNfgKgjRCT97W5t2c1DEVRAyJ%2ByHahD90%3D&reserved=0
> > >> >>>>
> > >> >>>>
> > >> >>>
> > >> >>> --
> > >> >>> Carlos Rovira
> > >> >>>
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439&sdata=yJoOS7qX8F%2BNfgKgjRCT97W5t2c1DEVRAyJ%2ByHahD90%3D&reserved=0
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>
> > >>
> > >>
> > >>
> > >>
> > >
> > > --
> > > Carlos Rovira
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602112444&sdata=Ata%2BBbvYb4O9GX%2FzRS6qkcF7DcNCTfSC4C%2BqdNWW2U4%3D&reserved=0
> > >
> > >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602112444&sdata=Ata%2BBbvYb4O9GX%2FzRS6qkcF7DcNCTfSC4C%2BqdNWW2U4%3D&reserved=0
> >
> >
> >
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602112444&sdata=Ata%2BBbvYb4O9GX%2FzRS6qkcF7DcNCTfSC4C%2BqdNWW2U4%3D&reserved=0
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
Posted by Carlos Rovira <ca...@apache.org>.
Hi,
I now Greg is busy now with an important update
I can try to do it myself if Alex point me to the code I should look, for
me it would be part of the task to make this blog example in the best way
possible.
thanks
El vie., 3 may. 2019 a las 22:58, Greg Dove (<gr...@gmail.com>)
escribió:
> '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 <ah...@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" <ca...@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 (<
> > carlosrovira@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
> > (<ah...@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" <ar...@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 <
> > joshtynjala@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 <
> joshtynjala@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
> <aharui@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" <
> > carlosrovira@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 (<
> > >> carlosrovira@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 (<
> > >> joshtynjala@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 <
> > carlosrovira@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
> >
> >
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
Posted by Greg Dove <gr...@gmail.com>.
'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 <ah...@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" <ca...@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 (<
> carlosrovira@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
> (<ah...@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" <ar...@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 <
> joshtynjala@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 <jo...@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 <aharui@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" <
> carlosrovira@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 (<
> >> carlosrovira@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 (<
> >> joshtynjala@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 <
> carlosrovira@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
>
>
>
Re: Using @extrens ( RE: Example of access external JS using Apache
Royale)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ca...@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 (<ca...@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 (<ah...@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" <ar...@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 <jo...@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 <jo...@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 <ah...@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" <ca...@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 (<
>> carlosrovira@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 (<
>> joshtynjala@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 <ca...@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
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
Posted by Carlos Rovira <ca...@apache.org>.
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://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/highlight.min.js
"></script>
* <link rel="stylesheet" title="Atom One Dark" href="
https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/styles/atom-one-dark.min.css
">
* </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 (<ca...@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 (<ah...@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" <ar...@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 <jo...@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%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=IADdFIV05gFba9voojnIWzJOCimRR%2F0dp4fgneKs9xM%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 <jo...@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 <ah...@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" <ca...@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 (<
>> carlosrovira@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 (<
>> joshtynjala@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%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=PAmxrfMPo8lAt3tdyntHVlJ%2Bbk3F%2FWioTvjN7iRYSgw%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 <ca...@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%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=ogC7DNs6k8%2Bf4NUBRt6g5mFHTfa8Sk6W8gS%2FgnAiKqs%3D&reserved=0
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Carlos Rovira
>> >>>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=ogC7DNs6k8%2Bf4NUBRt6g5mFHTfa8Sk6W8gS%2FgnAiKqs%3D&reserved=0
>> >>>>
>> >>>>
>> >>>
>> >>> --
>> >>> Carlos Rovira
>> >>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=ogC7DNs6k8%2Bf4NUBRt6g5mFHTfa8Sk6W8gS%2FgnAiKqs%3D&reserved=0
>> >>>
>> >>>
>> >>>
>> >>
>>
>>
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
Posted by Carlos Rovira <ca...@apache.org>.
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 (<ah...@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" <ar...@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 <jo...@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%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=IADdFIV05gFba9voojnIWzJOCimRR%2F0dp4fgneKs9xM%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 <jo...@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 <ah...@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" <ca...@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 (<
> carlosrovira@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 (<
> joshtynjala@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%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=PAmxrfMPo8lAt3tdyntHVlJ%2Bbk3F%2FWioTvjN7iRYSgw%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 <ca...@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%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=ogC7DNs6k8%2Bf4NUBRt6g5mFHTfa8Sk6W8gS%2FgnAiKqs%3D&reserved=0
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Carlos Rovira
> >>>>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=ogC7DNs6k8%2Bf4NUBRt6g5mFHTfa8Sk6W8gS%2FgnAiKqs%3D&reserved=0
> >>>>
> >>>>
> >>>
> >>> --
> >>> Carlos Rovira
> >>>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=ogC7DNs6k8%2Bf4NUBRt6g5mFHTfa8Sk6W8gS%2FgnAiKqs%3D&reserved=0
> >>>
> >>>
> >>>
> >>
>
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Using @extrens ( RE: Example of access external JS using Apache
Royale)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ar...@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 <jo...@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%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=IADdFIV05gFba9voojnIWzJOCimRR%2F0dp4fgneKs9xM%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 <jo...@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 <ah...@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" <ca...@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 (<ca...@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 (<jo...@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%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=PAmxrfMPo8lAt3tdyntHVlJ%2Bbk3F%2FWioTvjN7iRYSgw%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 <ca...@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%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=ogC7DNs6k8%2Bf4NUBRt6g5mFHTfa8Sk6W8gS%2FgnAiKqs%3D&reserved=0
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Carlos Rovira
>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=ogC7DNs6k8%2Bf4NUBRt6g5mFHTfa8Sk6W8gS%2FgnAiKqs%3D&reserved=0
>>>>
>>>>
>>>
>>> --
>>> Carlos Rovira
>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=ogC7DNs6k8%2Bf4NUBRt6g5mFHTfa8Sk6W8gS%2FgnAiKqs%3D&reserved=0
>>>
>>>
>>>
>>
Re: Using @extrens ( RE: Example of access external JS using Apache
Royale)
Posted by Dany Dhondt <ar...@mac.com.INVALID>.
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 <jo...@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://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 <jo...@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 <ah...@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" <ca...@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 (<ca...@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 (<jo...@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%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 <ca...@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%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
>>>
>>>
>>>
>>
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
Posted by Josh Tynjala <jo...@apache.org>.
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 <jo...@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 <ah...@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" <ca...@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 (<ca...@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 (<jo...@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%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 <ca...@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%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
> >
> >
> >
>
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
Posted by Josh Tynjala <jo...@apache.org>.
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 <ah...@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" <ca...@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 (<ca...@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 (<jo...@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%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 <ca...@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%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
>
>
>
Re: Using @extrens ( RE: Example of access external JS using Apache
Royale)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ca...@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 (<ca...@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 (<jo...@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%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 <ca...@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%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