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 (<[email protected]>) 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 <[email protected]> > 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" <[email protected]> wrote: > > > > Hi, > > > > while putting the pieces together for the blog example I'm finding > the > > following. > > > > For classes that wraps a js code that is an intrinsic file needed to > > make > > the code function I think inject_html should work but I'm trying it > and > > seems this is not working. The code is like this: > > > > package > > { > > /** > > * @externs > > */ > > public class hljs > > { > > /** > > * <inject_html> > > * <script src=" > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcdnjs.cloudflare.com%2Fajax%2Flibs%2Fhighlight.js%2F9.12.0%2Fhighlight.min.js&data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550849329&sdata=Ly6nMG8kCFvf2Dl4PCohbV8T9MPU%2F7OV2CaYrQNFXnY%3D&reserved=0 > > "></script> > > * <link rel="stylesheet" title="Atom One Dark" href=" > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcdnjs.cloudflare.com%2Fajax%2Flibs%2Fhighlight.js%2F9.12.0%2Fstyles%2Fatom-one-dark.min.css&data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550849329&sdata=C512YPiiwRTU909ZEV5dOT94FELRDVSqm4mNYt58fLY%3D&reserved=0 > > "> > > * </inject_html> > > */ > > public function hljs() > > { > > } > > > > public static function highlightBlock(block:Element):void {} > > } > > } > > > > So instead of add the inject_html in the code that calls the methods > in > > this step, I think it should be here > > > > Make this sense? > > > > > > > > El vie., 3 may. 2019 a las 9:38, Carlos Rovira (< > > [email protected]>) > > escribió: > > > > > Hi Alex, > > > > > > for me is difficult right now think about what would be better for > > > TypeScript. I think all will depend on how people interact in the > > following > > > months/years to show us what't the best for Royale in the long > term. > > > I think bringing TS to Royale as a first citizen language will make > > us > > > more accesible and people will considere us more since TS is the > > language > > > people choose over AS3 (although I for example like AS3 more and if > > we get > > > few things like generics we'll be great to compete with TS), but > > this is a > > > very complex task, so I know this hardly be done unless someone > > comes with > > > time and knowledge to make it happen. And if we think about things > > that are > > > complex and hard to add and see the importance/value it will bring > to > > > Royale I think a WebAssembly target will be over TS since it > clearly > > > enhance the Roayle purpose of generate multiple sources. > > > > > > In the other hand, make TS just to do TypeDefs, again maybe users > > should > > > express here if it could be needed, I can't say right now how much > > this > > > could be important for Royale, so maybe time and users will let us > > know > > > what to do. > > > > > > > > > > > > El jue., 2 may. 2019 a las 22:44, Alex Harui > > (<[email protected]>) > > > escribió: > > > > > >> The word "package" has many meanings. In AS3 it is a way of > > avoiding API > > >> name collisions. AIUI, an AS3 package in SWF code has no object > or > > >> function representation. It effectively just creates a longer > > "qualified > > >> name". IOW, in a SWF, if there is a class "mx.core.UIComponent", > > there is > > >> no "mx.core" object you can iterate to see all of the classes. > > >> > > >> For Royale's JS output, an AS3 package has an object > representation > > in > > >> debug mode because we use the same pattern as Google Closure. So > > there > > >> really would be an "mx" Object with a "core" property object with > a > > >> UIComponent function that serves as the constructor. However, in > > >> production, these package objects are often collapsed, so it is > > best to not > > >> assume the objects exist. > > >> > > >> Then there are Node/NPM packages and modules and other sorts of > > >> "packaging". But in this thread I was only referencing AS3 > > Packages. > > >> > > >> Also in this thread I mentioned TypeScript. While Royale could > > support > > >> TypeScript as Carlos mentioned, as an alternative to writing AS3, > I > > only > > >> mentioned it because the existence of a TypeScript definition for > a > > library > > >> indicates that the library can have a strongly-typed API surface > > which > > >> means it is highly likely you can create Royale typedefs for that > > library, > > >> and because I thought that Josh's converter was still working. > > Supporting > > >> TypeScript as an alternative programming language in Royale is a > > >> significant chunk of work and is not something I plan to work on > at > > this > > >> time. But I was only mentioning using TypeScript to generate > > typedefs, > > >> which is a different effort and could be a smaller effort and give > > us > > >> access to a huge set of typedefs. I have no plans to work on that > > at this > > >> time either, but I could imagine myself working on that if there > > was enough > > >> demand for it. > > >> > > >> HTH, > > >> -Alex > > >> > > >> On 5/2/19, 11:24 AM, "Dany Dhondt" <[email protected]> > > wrote: > > >> > > >> Hi Josh, > > >> > > >> Aren’t most of the packages just functions? > > >> In ES6, you’d import packages as > > >> Import { myFunct, myVar } from ‘my-package’ > > >> In older javascript you’d: > > >> const myPackagePointer = require(‘my-package’) > > >> > > >> So your ‘fun’ example sounds like heaven to me! This is > exactly > > what > > >> we need. > > >> > > >> About Typescript: do we need that at all? I think, but maybe > > this > > >> goes beyond my technical knowledge, all node packages are compiled > > into > > >> plain old javascript functions. Typescript is only needed for > > authoring the > > >> packages. Once compiled there’s no trace of Typescript at all. If > > this is > > >> indeed true, then we shouldn’t bother about Typescript at all, and > > just > > >> concentrate on incorporating the pure javascript libs. > > >> > > >> Dany > > >> > > >> > Op 2 mei 2019, om 19:57 heeft Josh Tynjala < > > [email protected]> > > >> het volgende geschreven: > > >> > > > >> > Just for fun, here's another way that you could create a > > typedef > > >> for hljs so that the highlightBlock() function is directly in a > > package > > >> (similar to flash.net.navigateToURL), instead of as a static > method > > on a > > >> class: > > >> > > > >> > > > >> > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FkhVI&data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550849329&sdata=E%2BzcgdC3TLRNC%2FL8IfXSeXQZslQJP7pEMcL5z%2FpcV3g%3D&reserved=0 > > >> > > > >> > If you did it this way, you'd need to import it before you > > can call > > >> the function, like this: > > >> > > > >> > import hljs.highlightBlock; > > >> > > > >> > Or this should work too, if you prefer: > > >> > > > >> > import hljs.*; > > >> > > > >> > And then you can call the function directly (without the > hljs. > > >> prefix): > > >> > > > >> > highlightBlock(block); > > >> > > > >> > As you can see, the way that you choose to expose a JS > > library to > > >> ActionScript is pretty flexible. Some JavaScript libraries are > just > > a > > >> function, and some have APIs that work more like classes. > Depending > > on the > > >> library, one way may work better than the other. > > >> > > > >> > - Josh > > >> > > > >> > On 2019/05/02 17:48:49, Josh Tynjala < > [email protected]> > > >> wrote: > > >> >> Exactly right. When you create a typedef class, you're > > trying to > > >> simulate how you would access the API as if you were writing in > > plain > > >> JavaScript. You call hljs.highlightBlock() in JavaScript, so you > > need a > > >> class that works the same way in ActionScript. > > >> >> > > >> >> Another option for organization would be to keep all of > your > > >> typedefs in a separate folder from your app's source files, and > > reference > > >> the typedefs folder using the source-path compiler option. > > >> >> > > >> >> - Josh > > >> >> > > >> >> On 2019/05/02 16:23:45, Alex Harui > <[email protected] > > > > > >> wrote: > > >> >>> Hi Carlos, > > >> >>> > > >> >>> I don’t think hljs is in a package called "externs". In > > Josh's > > >> example, hljs was in the top-level package. And that's because > > hljs is > > >> found at runtime off of the global window object, not some > > sub-object > > >> called "externs". So, the hljs.as file containing the externs > has > > to go > > >> in the root of a source-path, not in some folder called "externs" > > (which is > > >> why some folks will take the time to create a separate typedefs > SWC > > so as > > >> not to clutter the root of their application's source directory). > > >> >>> > > >> >>> Then instead of "import externs.hljs", it should be > "import > > hljs" > > >> (or shouldn’t be needed at all). > > >> >>> > > >> >>> HTH, > > >> >>> -Alex > > >> >>> > > >> >>> On 5/2/19, 9:11 AM, "Carlos Rovira" < > > [email protected]> > > >> wrote: > > >> >>> > > >> >>> Hi, > > >> >>> > > >> >>> in my latest commit I added hljs extern class like Josh > > show > > >> in package > > >> >>> externs in TDJ > > >> >>> > > >> >>> Then I didn't commit the following since is not working > > for me: > > >> >>> > > >> >>> 1.- In HighlightCode class (in utils package TDJ) > > >> >>> > > >> >>> added: > > >> >>> > > >> >>> import externs.hljs; > > >> >>> > > >> >>> changed the method highlightBlock to: > > >> >>> > > >> >>> COMPILE::JS > > >> >>> /** > > >> >>> * block is the element (WrappedHTMLElement) inside the > > >> component (the > > >> >>> <code> tag) > > >> >>> */ > > >> >>> public function > > highlightBlock(block:Element):void > > >> >>> { > > >> >>> hljs.highlightBlock(block); > > >> >>> } > > >> >>> > > >> >>> and running it I get: > > >> >>> > > >> >>> Uncaught ReferenceError: externs is not defined > > >> >>> at utils.HighlightCode.highlightBlock > > (HighlightCode.as:53) > > >> >>> at > > >> >>> > > >> > > > WelcomeSection.components.ExampleAndSourceCodeTabbedSectionContent.dataReadyHandler > > >> >>> (ExampleAndSourceCodeTabbedSectionContent.as:138) > > >> >>> at > > >> services.GitHubService.goog.events.EventTarget.fireListeners > > >> >>> (eventtarget.js:284) > > >> >>> at > > Function.goog.events.EventTarget.dispatchEventInternal_ > > >> >>> (eventtarget.js:381) > > >> >>> at > > >> services.GitHubService.goog.events.EventTarget.dispatchEvent > > >> >>> (eventtarget.js:196) > > >> >>> at > > >> >>> services.GitHubService.org > > >> .apache.royale.events.EventDispatcher.dispatchEvent > > >> >>> (EventDispatcher.js:71) > > >> >>> at > > >> services.GitHubService.services_GitHubService_completeHandler > > >> >>> (GitHubService.as:54) > > >> >>> at > > >> >>> org.apache.royale.net > > >> .HTTPService.goog.events.EventTarget.fireListeners > > >> >>> (eventtarget.js:284) > > >> >>> at > > Function.goog.events.EventTarget.dispatchEventInternal_ > > >> >>> (eventtarget.js:381) > > >> >>> at > > >> >>> org.apache.royale.net > > >> .HTTPService.goog.events.EventTarget.dispatchEvent > > >> >>> (eventtarget.js:196) > > >> >>> > > >> >>> What I'm doing wrong? > > >> >>> > > >> >>> thanks! > > >> >>> > > >> >>> > > >> >>> El jue., 2 may. 2019 a las 18:02, Carlos Rovira (< > > >> [email protected]>) > > >> >>> escribió: > > >> >>> > > >> >>>> Hi Josh, > > >> >>>> > > >> >>>> I think this piece of knowledge you just exposed here is > > key for > > >> the > > >> >>>> success of Royale. > > >> >>>> > > >> >>>> I'll try to use this in TDJ to experiment with it and > will > > use > > >> in the blog > > >> >>>> example I plan to do. > > >> >>>> > > >> >>>> thanks! > > >> >>>> > > >> >>>> > > >> >>>> El jue., 2 may. 2019 a las 16:36, Josh Tynjala (< > > >> [email protected]>) > > >> >>>> escribió: > > >> >>>> > > >> >>>>>> Users can't do this, they required that Royale > framework > > devs > > >> add > > >> >>>>> typedefs to the typedefs repo and wait to next SDK > > release. > > >> What does not > > >> >>>>> seems very useful. > > >> >>>>> > > >> >>>>> Users can create their own typedefs from scratch. > > >> >>>>> > > >> >>>>> I just created a quick example for hljs, that exposes > the > > >> >>>>> highlightBlock() function: > > >> >>>>> > > >> >>>>> > > >> > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FdIq0&data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550849329&sdata=hyGPtFg919vlEreGs9E7OqkqRcSHImOIGt8Mt5FNfaI%3D&reserved=0 > > >> >>>>> > > >> >>>>> Basically, the class needs an asdoc comment with the > > @externs > > >> tag (this > > >> >>>>> is something that comes from Google Closure compiler, > > which we > > >> use to > > >> >>>>> create release builds) and the compiler should handle > the > > rest. > > >> >>>>> > > >> >>>>> As I understand it, you don't even need to create a SWC > > library > > >> for > > >> >>>>> custom typedefs. Recently, Alex mentioned that the mxmlc > > >> compiler is smart > > >> >>>>> enough to handle a source file as long as it has the > > @externs > > >> tag. > > >> >>>>> > > >> >>>>> - Josh > > >> >>>>> > > >> >>>>> On 2019/05/02 09:34:37, Carlos Rovira < > > [email protected]> > > >> wrote: > > >> >>>>>> Hi, > > >> >>>>>> > > >> >>>>>> to sumarize (let me know if I'm wrong), the current > ways > > to > > >> integrate an > > >> >>>>>> existing library are 3: > > >> >>>>>> > > >> >>>>>> 1.- access vía brackets notation: This is the most easy > > and > > >> direct, an > > >> >>>>>> example is TourDeJewel in class utils.HighlightCode > > >> >>>>>> > > >> >>>>>> var hljs:Object = window["hljs"]; > > >> >>>>>> hljs["highlightBlock"](block); > > >> >>>>>> > > >> >>>>>> but this one is not what we really want since we are > > going > > >> with Roayle > > >> >>>>> and > > >> >>>>>> AS3 to get type checking and strong typing. So this, > > although > > >> useful is > > >> >>>>> not > > >> >>>>>> what we really want to use in out Apps, but since we > > want to > > >> maintain > > >> >>>>> the > > >> >>>>>> dynamic aspect of the language it could be very useful > > >> sometimes > > >> >>>>>> > > >> >>>>>> 2.- using typedefs > > >> >>>>>> > > >> >>>>>> This will be the next step to use a real type and dot > > >> notation, but > > >> >>>>> seems > > >> >>>>>> not easy or direct. > > >> >>>>>> Users can't do this, they required that Royale > framework > > devs > > >> add > > >> >>>>> typedefs > > >> >>>>>> to the typedefs repo and wait to next SDK release. What > > does > > >> not seems > > >> >>>>> very > > >> >>>>>> useful. > > >> >>>>>> > > >> >>>>>> In the other hand we'll need to know how to extend > > current > > >> typedefs > > >> >>>>> since > > >> >>>>>> don't know if we have docs about this. Until now I > added > > to > > >> "missing.js" > > >> >>>>>> file fo now, but this doesn't seems a valid path since > > it lacks > > >> >>>>>> organization, separation, and a way for all people > > >> contributing to know > > >> >>>>> wha > > >> >>>>>> we have, what can be added and where, if not we'll find > > in > > >> time lots of > > >> >>>>>> code very difficult to maintain. > > >> >>>>>> > > >> >>>>>> Yishay and Josh talked about to use TypeScript, but > > seems that > > >> is > > >> >>>>> already > > >> >>>>>> explored by Josh but not a valid path since will be > very > > >> difficult to > > >> >>>>>> maintain. > > >> >>>>>> > > >> >>>>>> 3.- wrapping libraries > > >> >>>>>> > > >> >>>>>> This is how we did with MDL. This will be recommended > > when we > > >> want to > > >> >>>>>> integrate existing libraries with Royale to make it > work > > with > > >> our APIs > > >> >>>>> in a > > >> >>>>>> more seamless way. But the problems is that this is > very > > >> laborious. Can > > >> >>>>> be > > >> >>>>>> useful for some concrete libraries and we should do > when > > >> needed (the > > >> >>>>> case > > >> >>>>>> is MDL). But the problem is that this not solve the > > problem of > > >> our users > > >> >>>>>> that need to integrate a existing library themselves > in a > > >> quick way. > > >> >>>>>> > > >> >>>>>> Let me know if you know other way. > > >> >>>>>> > > >> >>>>>> For me method 1, is ok to do the work, but doesn't make > > us > > >> justice. > > >> >>>>>> method 2 should be the main one if there's a fast and > > easy > > >> way... I'm > > >> >>>>>> missing something here? Can users create typedefs > > themselves? > > >> >>>>>> method 3 can be useful for us or for users (doing their > > own > > >> libs, and > > >> >>>>>> eventually can share with us to add to official royale > > repo > > >> and sdk) > > >> >>>>>> but is something not fast at all and not as convenient > > and > > >> direct as > > >> >>>>> method > > >> >>>>>> 2, and will require maintenance as libs change. > > >> >>>>>> > > >> >>>>>> Could we agree that this is the currently available > ways > > in > > >> Royale now > > >> >>>>> to > > >> >>>>>> use external JS libs? > > >> >>>>>> > > >> >>>>>> thanks > > >> >>>>>> > > >> >>>>>> -- > > >> >>>>>> Carlos Rovira > > >> >>>>>> > > >> > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550849329&sdata=Y4KEWA%2BiX8w0X8ERfqU5%2FzVlAoEIm8XeEkCowIeRC4Y%3D&reserved=0 > > >> >>>>>> > > >> >>>>> > > >> >>>> > > >> >>>> > > >> >>>> -- > > >> >>>> Carlos Rovira > > >> >>>> > > >> > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550859338&sdata=0jc3vowPhWNFT3kVOO40WG55yfBxqosrg10bfeckpDE%3D&reserved=0 > > >> >>>> > > >> >>>> > > >> >>> > > >> >>> -- > > >> >>> Carlos Rovira > > >> >>> > > >> > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550859338&sdata=0jc3vowPhWNFT3kVOO40WG55yfBxqosrg10bfeckpDE%3D&reserved=0 > > >> >>> > > >> >>> > > >> >>> > > >> >> > > >> > > >> > > >> > > >> > > > > > > -- > > > Carlos Rovira > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550859338&sdata=0jc3vowPhWNFT3kVOO40WG55yfBxqosrg10bfeckpDE%3D&reserved=0 > > > > > > > > > > -- > > Carlos Rovira > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550859338&sdata=0jc3vowPhWNFT3kVOO40WG55yfBxqosrg10bfeckpDE%3D&reserved=0 > > > > > > > -- Carlos Rovira http://about.me/carlosrovira
