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.cssdata=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439sdata=uBI0vW721xJqBH2I%2FuUrq92KIu2Vgf6YzcrOXEFGLHM%3Dreserved=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.cssdata=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439sdata=uBI0vW721xJqBH2I%2FuUrq92KIu2Vgf6YzcrOXEFGLHM%3Dreserved=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 flexible than requiring "is" (
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%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7Ce6ca6613bd5a4315d99108d6d16104ac%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636926611965222777sdata=n7yCDIWT3QYtHMTHNNDoy%2FZYau5D6w3gGWJwQMAejhg%3Dreserved=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
> >> > {
> >> > /**
> >> > *
> >> > *
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.cssdata=02%7C01%7Caharui%40adobe.com%7C922752ecb7bf4513718208d6d00ae5fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925142602102439sdata=uBI0vW721xJqBH2I%2FuUrq92KIu2Vgf6YzcrOXEFGLHM%3Dreserved=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=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550849329=C512YPiiwRTU909ZEV5dOT94FELRDVSqm4mNYt58fLY%3D=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
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.cssdata=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550849329sdata=C512YPiiwRTU909ZEV5dOT94FELRDVSqm4mNYt58fLY%3Dreserved=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
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.cssdata=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550849329sdata=C512YPiiwRTU909ZEV5dOT94FELRDVSqm4mNYt58fLY%3Dreserved=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.cssdata=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550849329sdata=C512YPiiwRTU909ZEV5dOT94FELRDVSqm4mNYt58fLY%3Dreserved=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 because
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.cssdata=02%7C01%7Caharui%40adobe.com%7C868c28fb190b470d90c608d6d00907c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636925134550849329sdata=C512YPiiwRTU909ZEV5dOT94FELRDVSqm4mNYt58fLY%3Dreserved=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
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%2FkhVIdata=02%7C01%7Caharui%40adobe.com%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437sdata=IADdFIV05gFba9voojnIWzJOCimRR%2F0dp4fgneKs9xM%3Dreserved=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
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%2FkhVIdata=02%7C01%7Caharui%40adobe.com%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437sdata=IADdFIV05gFba9voojnIWzJOCimRR%2F0dp4fgneKs9xM%3Dreserved=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
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
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=02%7C01%7Caharui%40adobe.com%7C91b9c474703f4878a7b408d6cf18e064%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924103085455525=J8d1PlqvyFfdIqVdpH0y%2FaXV%2BZzoYxm3w6Q9eo%2BIH7c%3D=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%2FdIq0data=02%7C01%7Caharui%40adobe.com%7C91b9c474703f4878a7b408d6cf18e064%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924103085455525sdata=J8d1PlqvyFfdIqVdpH0y%2FaXV%2BZzoYxm3w6Q9eo%2BIH7c%3Dreserved=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.
>>
Using @extrens ( RE: Example of access external JS using Apache Royale)
Hi,
in my latest commit I added hljs extern class like Josh show in package
externs in TDJ
Then I didn't commit the following since is not working for me:
1.- In HighlightCode class (in utils package TDJ)
added:
import externs.hljs;
changed the method highlightBlock to:
COMPILE::JS
/**
* block is the element (WrappedHTMLElement) inside the component (the
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://paste.apache.org/dIq0
>>
>> Basically, the class needs an asdoc comment with the @externs tag (this
>> is something that comes from Google Closure compiler, which we use to
>> create release builds) and the compiler should handle the rest.
>>
>> As I understand it, you don't even need to create a SWC library for
>> custom typedefs. Recently, Alex mentioned that the mxmlc compiler is smart
>> enough to handle a source file as long as it has the @externs tag.
>>
>> - Josh
>>
>> On 2019/05/02 09:34:37, Carlos Rovira 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
