Hi,
while putting the pieces together for the blog example I'm finding the
following.
For classes that wraps a js code that is an intrinsic file needed to make
the code function I think inject_html should work but I'm trying it and
seems this is not working. The code is like this:
package
{
/**
* @externs
*/
public class hljs
{
/**
* <inject_html>
* <script src="
https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/highlight.min.js
"></script>
* <link rel="stylesheet" title="Atom One Dark" href="
https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/styles/atom-one-dark.min.css
">
* </inject_html>
*/
public function hljs()
{
}
public static function highlightBlock(block:Element):void {}
}
}
So instead of add the inject_html in the code that calls the methods in
this step, I think it should be here
Make this sense?
El vie., 3 may. 2019 a las 9:38, Carlos Rovira (<[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%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 <[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%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=PAmxrfMPo8lAt3tdyntHVlJ%2Bbk3F%2FWioTvjN7iRYSgw%3D&reserved=0
>> >>>>>
>> >>>>> Basically, the class needs an asdoc comment with the @externs
>> tag (this
>> >>>>> is something that comes from Google Closure compiler, which we
>> use to
>> >>>>> create release builds) and the compiler should handle the rest.
>> >>>>>
>> >>>>> As I understand it, you don't even need to create a SWC library
>> for
>> >>>>> custom typedefs. Recently, Alex mentioned that the mxmlc
>> compiler is smart
>> >>>>> enough to handle a source file as long as it has the @externs
>> tag.
>> >>>>>
>> >>>>> - Josh
>> >>>>>
>> >>>>> On 2019/05/02 09:34:37, Carlos Rovira <[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%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=ogC7DNs6k8%2Bf4NUBRt6g5mFHTfa8Sk6W8gS%2FgnAiKqs%3D&reserved=0
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Carlos Rovira
>> >>>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=ogC7DNs6k8%2Bf4NUBRt6g5mFHTfa8Sk6W8gS%2FgnAiKqs%3D&reserved=0
>> >>>>
>> >>>>
>> >>>
>> >>> --
>> >>> Carlos Rovira
>> >>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=ogC7DNs6k8%2Bf4NUBRt6g5mFHTfa8Sk6W8gS%2FgnAiKqs%3D&reserved=0
>> >>>
>> >>>
>> >>>
>> >>
>>
>>
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
