Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
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 () 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 () > 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" 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 () >> 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 > > >> > 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" >> 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 >> > > { >> > > /** >> > > * >> > > * 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 >> > > "> >> > > * 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 >> > > "> >> > > * >> > > */ >> > > public function hljs() >> > > { >> > > } >> > > >> > > public static function >> highlightBlock(block:Element):void {} >> > > } >> > > } >> > > >> > > So instead of add the inject_html in the code that calls the >> methods >> > in >> > > this step, I think it should be here >> > > >> > > Make this sense? >> > > >> > > >> > > >> > > El vie., 3 may. 2019 a las 9:38, Carlos Rovira (< >> > > carlosrov...@apache.org>) >> > > escribió: >> > > >> > > > Hi Alex, >> > > > >> > > > for me is difficult right now think about what would be >> better for >> > > > TypeScript. I think all will depend on how people interact >> in the >> > > following >> > > > months/years to show us what't the best for Royale in the >> long >> > term. >
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
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 () 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" 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 () > 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 > > 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" > 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 > > > { > > > /** > > > * > > > * 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 > > > "> > > > * 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 > > > "> > > > * > > > */ > > > public function hljs() > > > { > > > } > > > > > > public static function > highlightBlock(block:Element):void {} > > > } > > > } > > > > > > So instead of add the inject_html in the code that calls the > methods > > in > > > this step, I think it should be here > > > > > > Make this sense? > > > > > > > > > > > > El vie., 3 may. 2019 a las 9:38, Carlos Rovira (< > > > carlosrov...@apache.org>) > > > escribió: > > > > > > > Hi Alex, > > > > > > > > for me is difficult right now think about what would be > better for > > > > TypeScript. I think all will depend on how people interact > in the > > > following > > > > months/years to show us what't the best for Royale in the > long > > term. > > > > I think bringing TS to Royale as a first citizen language > will make > > > us > > > > more accesible and people will considere us more since TS is > the > > > language > > > > people choose over AS3 (although I for example like AS3 more > and if > > > we get > > > > few things like generics we'll be great to compete with TS), > but > > > this is a > > > > very complex task, so I know this hardly be done unless > someone > > > comes with > > > > time and knowledge to make it happen. And if we think about > things > > > that are > > > > complex and hard to add and see the importance/value it will > bring > > to > > > > Royale I think a WebAssembly target will be over TS since it > > clearly
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
On 5/7/19, 1:37 AM, "Yishay Weiss" 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)
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 , 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 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. ... replacementModel.data = "foo"; 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" 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 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 f
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. ... replacementModel.data = "foo"; 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" 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 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" 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)
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 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" 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)
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" 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)
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" 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 () 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)
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 () 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)
>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)
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" 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 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"]({ 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 () > 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 () > > 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 > >> 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" 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 > >> > { > >> > /** > >> > * > >> > * 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%7Cfa7b1b5a7b34438794aed2c178de
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
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" 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 () 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 > 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" 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 > > { > > /** > > * > > * 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 > > "> > > * 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 > > "> > > * > > */ > > public function hljs() > > { > > } > > > > public static function highlightBlock(block:Element):void {} > > } > > } > > > > So instead of add the inject_html in the code that calls the methods > in > > this step, I think it should be here > > > > Make this sense? > > > > > > > > El vie., 3 may. 2019 a las 9:38, Carlos Rovira (< > > carlosrov...@apache.org>) > > escribió: > > > > > Hi Alex, > > > > > > for me is difficult right now think about what would be better for > > > TypeScript. I think all will depend on how people interact in the > > following > > > months/years to show us what't the best for Royale in the long > term. > > > I think bringing TS to Royale as a first citizen language will make > > us > > > more accesible and people will considere us more since TS is the > > language > > > people choose over AS3 (although I for example like AS3 more and if > > we get > > > few things like generics we'll be great to compete with TS), but > > this is a > > > very complex task, so I know this hardly be done unless someone > > comes with > > > time and knowledge to make it happen. And if we think about things > > that are > > > complex and hard to add and see the importance/value it will bring > to > > > Royale I think a WebAssembly target will be over TS since it > clearly > > > enhance the Roayle purpose of generate multiple sources. > > > > > > In the other hand, make TS just to do TypeDefs, again maybe users > > should > > > express here if it could be needed, I can't say right now how much > > this > > > could be important for Royale, so maybe time and users will let us > > know > > > what to do. > > > > > > > > > > > > El jue., 2 may. 2019 a las 22:44, Alex Harui > > () > > > 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",
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
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 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 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"]({ > 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 (< > carlosrov...@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 () > > > 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 > > >> 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" > 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 > > >> > { > > >> > /** > > >> > * > > >> > * 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 > > >> > "> > > >> > * 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 > > >> > "> > > >> > * > > >> > */ > > >> > public function hljs() > > >> > { > > >> > } > > >> > > > >> > public static function > highlightBlock(block:Element):void {} > > >> > } > > >> > } > > >> > > > >> > So instead of add the inject_html in the code that calls the > > >> methods in > > >> > this step, I think it should be here > > >> > > > >> > Make this sense? > > >> > > > >> > > > >> > > > >> > El vie., 3 may. 2019 a las 9:38, Carlos Rovira (< > > >> > carlosrov...@apache.org>) > > >> > escribió: > > >> > > > >> > > Hi Alex, > > >> > > > > >> > > for me is difficult right now think about what would be > better for > > >> > > TypeScript. I think all will depend on how people interact in > the > > >> > following > > >> > > months/years to show us what't the best for Royale in the long > > >> term. > > >> > > I think bringing TS to Royale as a first citizen language will > > >> make > > >> > us > > >> >
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
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 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"]({ 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 () > 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 () > > 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 > >> 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" 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 > >> > { > >> > /** > >> > * > >> > * 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 > >> > "> > >> > * 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 > >> > "> > >> > * > >> > */ > >> > public function hljs() > >> > { > >> > } > >> > > >> > public static function highlightBlock(block:Element):void {} > >> > } > >> > } > >> > > >> > So instead of add the inject_html in the code that calls the > >> methods in > >> > this step, I think it should be here > >> > > >> > Make this sense? > >> > > >> > > >> > > >> > El vie., 3 may. 2019 a las 9:38, Carlos Rovira (< > >> > carlosrov...@apache.org>) > >> > escribió: > >> > > >> > > Hi Alex, > >> > > > >> > > for me is difficult right now think about what would be better for > >> > > TypeScript. I think all will depend on how people interact in the > >> > following > >> > > months/years to show us what't the best for Royale in the long > >> term. > >> > > I think bringing TS to Royale as a first citizen language will > >> make > >> > us > >> > > more accesible and people will considere us more since TS is the > >> > language > >> > > people choose over AS3 (although I for example like AS3 more and > >> if > >> > we get > >> > > few things like generics we'll be great to compete with TS), but > >> > this is a > >> > > very complex task, so I know this hardly be done unless someone > >> > comes with > >> > > time and knowledge to make it happen. And if we think about things > >> > that are > >> > > complex and hard to add and see the importance/value it will > >> bring to > >> > > Royale I think a WebAssembly target will be over TS since it > >> clearly > >> > > enhance the Roayle purpose of generate multiple sources. > >> > > > >> > > In the other hand, make TS just to do TypeDefs, again maybe users > >> > should > >> > > express here if it could be needed, I can't say right now h
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
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"]({ }); so I want royale user can do instead: indicator_content.animate({...}); thanks El vie., 3 may. 2019 a las 23:03, Carlos Rovira () 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 () > 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 >> 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" 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 >> > { >> > /** >> > * >> > * 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 >> > "> >> > * 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 >> > "> >> > * >> > */ >> > public function hljs() >> > { >> > } >> > >> > public static function highlightBlock(block:Element):void {} >> > } >> > } >> > >> > So instead of add the inject_html in the code that calls the >> methods in >> > this step, I think it should be here >> > >> > Make this sense? >> > >> > >> > >> > El vie., 3 may. 2019 a las 9:38, Carlos Rovira (< >> > carlosrov...@apache.org>) >> > escribió: >> > >> > > Hi Alex, >> > > >> > > for me is difficult right now think about what would be better for >> > > TypeScript. I think all will depend on how people interact in the >> > following >> > > months/years to show us what't the best for Royale in the long >> term. >> > > I think bringing TS to Royale as a first citizen language will >> make >> > us >> > > more accesible and people will considere us more since TS is the >> > language >> > > people choose over AS3 (although I for example like AS3 more and >> if >> > we get >> > > few things like generics we'll be great to compete with TS), but >> > this is a >> > > very complex task, so I know this hardly be done unless someone >> > comes with >> > > time and knowledge to make it happen. And if we think about things >> > that are >> > > complex and hard to add and see the importance/value it will >> bring to >> > > Royale I think a WebAssembly target will be over TS since it >> clearly >> > > enhance the Roayle purpose of generate multiple sources. >> > > >> > > In the other hand, make TS just to do TypeDefs, again maybe users >> > should >> > > express here if it could be needed, I can't say right now how much >> > this >> > > could be important for Royale, so maybe time and users will let us >> > know >> > > what to do. >> > > >> > > >> > > >> > > El jue., 2 may. 2019 a las 22:44, Alex Harui >> > () >> > > 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, i
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
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 () 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 > 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" 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 > > { > > /** > > * > > * 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 > > "> > > * 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 > > "> > > * > > */ > > public function hljs() > > { > > } > > > > public static function highlightBlock(block:Element):void {} > > } > > } > > > > So instead of add the inject_html in the code that calls the methods > in > > this step, I think it should be here > > > > Make this sense? > > > > > > > > El vie., 3 may. 2019 a las 9:38, Carlos Rovira (< > > carlosrov...@apache.org>) > > escribió: > > > > > Hi Alex, > > > > > > for me is difficult right now think about what would be better for > > > TypeScript. I think all will depend on how people interact in the > > following > > > months/years to show us what't the best for Royale in the long > term. > > > I think bringing TS to Royale as a first citizen language will make > > us > > > more accesible and people will considere us more since TS is the > > language > > > people choose over AS3 (although I for example like AS3 more and if > > we get > > > few things like generics we'll be great to compete with TS), but > > this is a > > > very complex task, so I know this hardly be done unless someone > > comes with > > > time and knowledge to make it happen. And if we think about things > > that are > > > complex and hard to add and see the importance/value it will bring > to > > > Royale I think a WebAssembly target will be over TS since it > clearly > > > enhance the Roayle purpose of generate multiple sources. > > > > > > In the other hand, make TS just to do TypeDefs, again maybe users > > should > > > express here if it could be needed, I can't say right now how much > > this > > > could be important for Royale, so maybe time and users will let us > > know > > > what to do. > > > > > > > > > > > > El jue., 2 may. 2019 a las 22:44, Alex Harui > > () > > > 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 >
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
'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 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" 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 > { > /** > * > * 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 > "> > * 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 > "> > * > */ > public function hljs() > { > } > > public static function highlightBlock(block:Element):void {} > } > } > > So instead of add the inject_html in the code that calls the methods in > this step, I think it should be here > > Make this sense? > > > > El vie., 3 may. 2019 a las 9:38, Carlos Rovira (< > carlosrov...@apache.org>) > escribió: > > > Hi Alex, > > > > for me is difficult right now think about what would be better for > > TypeScript. I think all will depend on how people interact in the > following > > months/years to show us what't the best for Royale in the long term. > > I think bringing TS to Royale as a first citizen language will make > us > > more accesible and people will considere us more since TS is the > language > > people choose over AS3 (although I for example like AS3 more and if > we get > > few things like generics we'll be great to compete with TS), but > this is a > > very complex task, so I know this hardly be done unless someone > comes with > > time and knowledge to make it happen. And if we think about things > that are > > complex and hard to add and see the importance/value it will bring to > > Royale I think a WebAssembly target will be over TS since it clearly > > enhance the Roayle purpose of generate multiple sources. > > > > In the other hand, make TS just to do TypeDefs, again maybe users > should > > express here if it could be needed, I can't say right now how much > this > > could be important for Royale, so maybe time and users will let us > know > > what to do. > > > > > > > > El jue., 2 may. 2019 a las 22:44, Alex Harui > () > > 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 becau
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
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" 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 { /** * * 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 "> * 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 "> * */ 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 () 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 () > 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
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
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 { /** * * https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/highlight.min.js "> * https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/styles/atom-one-dark.min.css "> * */ 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 () 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 () > 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" 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 >> het volgende geschreven: >> > >> > Just for fun, here's another way that you could create a typedef >> for hl
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
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 () 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" 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 > 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 tha
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
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" 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 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 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 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 so
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
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 () 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 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 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 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" 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 > >>> 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_ > >>
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
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 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 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 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 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" 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 > >>> 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) > >>>
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
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 () 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 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 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" 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 > > > tag) > > > */ > > > public function highlightBlock(block:Element):void > > > { > > > hljs.highlightBlock(block); > > > } > > > > > > and running it I get: > > > > > > Uncaught ReferenceError: externs is not defined > > > at utils.HighlightCode.highlightBlock (HighlightCode.as:53) > > > at > > > > > WelcomeSection.components.ExampleAndSourceCodeTabbedSectionContent.dataReadyHandler > > > (ExampleAndSourceCodeTabbedSectionContent.as:138) > > > at services.GitHubService.goog.events.EventTarget.fireListeners > > > (eventtarget.js:284) > > > at Function.goog.events.EventTarget.dispatchEventInternal_ > > > (eventtarget.js:381) > > > at services.GitHubService.goog.events.EventTarget.dispatchEvent > > > (eventtarget.js:196) > > > at > > > services.GitHubService.org > .apache.royale.events.EventDispatcher.dispatchEvent > > > (EventDispatcher.js:71) > > > at > services.GitHubService.services_GitHubService_completeHandler > > > (GitHubService.as:54) > > > at > > > org.apache.royale.net > .HTTPService.goog.events.EventTarget.fireListeners > > > (eventtarget.js:284) > > > at Function.goog.events.EventTarget.dispatchEventInternal_ > > > (eventtarget.js:381) > > > at > > > org.apache.royale.net > .HTTPService.goog.events.EventTarget.dispatchEvent > > > (eventtarget.js:196) > > > > > > What I'm doing wrong? > > > > > > thanks! > > > > > > > > > El jue., 2 may. 2019 a las 18:02, Carlos Rovira (< > carlosrov...@apache.org>) > > > escribió: > > > > > > > Hi Josh, > > > > > > > > I think this piece of knowledge you just exposed here is key for > the > > > > success of Royale. > > > > > > > > I'll try to use this in TDJ to experiment with it and will use > in the blog > > > > example I plan to do. > > > > > > > > thanks! > > > > > > > > > > > > El jue., 2 may. 2019 a las 16:36, Josh Tynjala (< > joshtynj...@apache.org>) > > > >
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
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 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 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 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" 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 >>> 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 >>> () >>>escribió: >>> Hi
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
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 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 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" 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 > > 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 > > () > > 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 > > () > > > 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
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
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 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" 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 > 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 > () > 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 > () > > 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 wrote: > >> > Hi, > >> > > >> > to sumarize (let me know if I'm wrong), the current ways to > integrate an > >> > existing library are 3: >
Re: Using @extrens ( RE: Example of access external JS using Apache Royale)
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" 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 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 () 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 () > 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 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.