> 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 <carlosrov...@apache.org> wrote: > Hi, > > to sumarize (let me know if I'm wrong), the current ways to integrate an > existing library are 3: > > 1.- access vía brackets notation: This is the most easy and direct, an > example is TourDeJewel in class utils.HighlightCode > > var hljs:Object = window["hljs"]; > hljs["highlightBlock"](block); > > but this one is not what we really want since we are going with Roayle and > AS3 to get type checking and strong typing. So this, although useful is not > what we really want to use in out Apps, but since we want to maintain the > dynamic aspect of the language it could be very useful sometimes > > 2.- using typedefs > > This will be the next step to use a real type and dot notation, but seems > not easy or direct. > Users can't do this, they required that Royale framework devs add typedefs > to the typedefs repo and wait to next SDK release. What does not seems very > useful. > > In the other hand we'll need to know how to extend current typedefs since > don't know if we have docs about this. Until now I added to "missing.js" > file fo now, but this doesn't seems a valid path since it lacks > organization, separation, and a way for all people contributing to know wha > we have, what can be added and where, if not we'll find in time lots of > code very difficult to maintain. > > Yishay and Josh talked about to use TypeScript, but seems that is already > explored by Josh but not a valid path since will be very difficult to > maintain. > > 3.- wrapping libraries > > This is how we did with MDL. This will be recommended when we want to > integrate existing libraries with Royale to make it work with our APIs in a > more seamless way. But the problems is that this is very laborious. Can be > useful for some concrete libraries and we should do when needed (the case > is MDL). But the problem is that this not solve the problem of our users > that need to integrate a existing library themselves in a quick way. > > Let me know if you know other way. > > For me method 1, is ok to do the work, but doesn't make us justice. > method 2 should be the main one if there's a fast and easy way... I'm > missing something here? Can users create typedefs themselves? > method 3 can be useful for us or for users (doing their own libs, and > eventually can share with us to add to official royale repo and sdk) > but is something not fast at all and not as convenient and direct as method > 2, and will require maintenance as libs change. > > Could we agree that this is the currently available ways in Royale now to > use external JS libs? > > thanks > > -- > Carlos Rovira > http://about.me/carlosrovira >
