Great project! A couple of pointers to make things easier/different:
1. -js-dynamic-access-unknown-members=true” allows use of obj.property instead of obj[“property”] 2. There is loadJavascript utility function in org.apache.royale.utils.js. That can be used for lazy-loading of libraries instead of inject_html. Harbs > On May 4, 2019, at 8:28 AM, Frost, Andrew <[email protected]> wrote: > > Hi > > Responding (belatedly!) to a few of these points: > > - I need to look at how to get those typedefs working! as yes, it would be > great to not have to use the obj["property"] notation! > - Equally: yes I found it useful to redefine the API. I don't like the way > that everything is specified as a property within a config object that's > passed in to the constructor, though it seems a common pattern in JavaScript. > For me, I would to set up individual properties, so hopefully that's what > this approach can achieve (and of course, now each property is set within the > mxml tag) > - I just grabbed the latest source for that component, turns out to be > 4.1.0.. I didn't get on so well with trying to actually find the API for the > calendar in order to reproduce everything it can do, so was mostly working of > the samples and demo code, trying to make sure the same thing could be done > in Royale. > > One interesting part I found was setting the header: rather than defining a > class with a 'center' property (as I didn't know what other properties it > might have) I just left this as an Object, and then in MXML I could use > <fx:Object center='value'/> to define it. Which struck me as incredibly > flexible! - although not ideal I think, as then you lose all the benefits of > the type checking and it wouldn't have corrected me if I spelt "center" and > "centre", etc... > > The injection of the script/css tags was interesting, I didn't want to have > to pull in everything all at once, hence separating out the 'plugins' into > different classes actually really helped with that. Probably it would be > useful to have some interfaces defined so that we can identify which plugins > are also views, and get the view-specific settings for these 'properly' > rather than testing for the existence of a particular property.. > > Anyway: lots could be improved here, but it was a useful exercise.. > > > thanks > > Andrew > > > -----Original Message----- > From: Dany Dhondt [mailto:[email protected] > <mailto:[email protected]>] > Sent: 03 May 2019 07:28 > To: [email protected] <mailto:[email protected]> > Subject: [EXTERNAL] Re: The start of a FullCalendar Royale component... > > The (very) good news is that is IS possible. To me as a developer (and others > we’re hoping to use Royale), it is vital to know that it can be done. At some > point in developing an application with Royale, we’ll stumble on some > functionality or component which just isn’t available in Royale. At that > point, it is simply not acceptable to say ‘well hey, it can’t be done right > now but come back in a year or so’. > FullCalendar is a good example because every developer will need a calendar > component sooner or later. FC is becoming a standard in javascript (+70k > downloads a week). > @Andrew, I’ll post the FullCalendar question on StackOverflow. Could you > answer it? That way, Royale will emerge too when people search on the > FullCalendar tag. > Another question: did you use the 4.x version of FC or the (older) 3.x > version? > > Thanks > Dany > >> Op 3 mei 2019, om 07:55 heeft Piotr Zarzycki <[email protected] >> <mailto:[email protected]>> het volgende geschreven: >> >> Hi Andrew, >> >> First of all Thank you for using Moonshine! I think there is one good >> advantage to going by your approach instead typedefs. You can redefine >> API to completely new if you don't like in the original component. >> Those new API may have a bit more of a AS3 style etc. >> >> Thanks, >> Piotr >> >> On Fri, May 3, 2019, 6:26 AM Alex Harui <[email protected] >> <mailto:[email protected]>> wrote: >> >>> Hi Andrew, >>> >>> That's cool! Thank you for demonstrating that such a thing can be done. >>> >>> I'm not sure there is a "best approach" for doing something like >>> this. It really depends on how much time you want to put into it. >>> If you want to use a 3rd-party component in your app and only want to >>> use a few APIs, then the approach you took is fine and solves your problem >>> quickly. >>> >>> On the other hand, if you want to make it complete and offer it to >>> others to use you may find that creating typedefs for the options and >>> calendar objects and other objects you are wrapping will eliminate >>> the need to use bracket access such as 'options["defaultView"] = >>> _defaultView;' and thus allow the IDE to offer better code-assist and >>> catch typos so you don't later waste time debugging why >>> 'options["defaultview"]' is not working. >>> >>> Thanks, >>> -Alex >>> >>> On 5/2/19, 2:07 PM, "Frost, Andrew" <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi >>> >>> Something that Dany Dhondt wrote recently, about using the >>> "fullcalendar" React component, got me to wondering how easy it was >>> to wrap these sorts of third party components into Royale. >>> >>> The answer turned out to be: it's pretty straightforward. I'm not >>> sure I've used the best approach (no 'typedefs' or anything) but I've >>> created some wrapper classes that can be used from MXML to drop in a >>> calendar component and add events etc. Lots of extra work to do to >>> get it to the stage where it's as functional as the JS/React etc >>> versions, but the lack here is (a) time and (b) documentation (I >>> can't see a full API for the various FullCalendar classes..!) >>> >>> Hope it's useful for folk to see how quickly this can be done... >>> >>> >>> https://clicktime.symantec.com/3DP7MFZw5gAqNwkJHvM2oYm7Vc?u=https%3A%2F%2Fnam04.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fajwfrost%252Froyale-playground%252Ftree%252Fmaster%252FCalendarProject%26data%3D02%257C01%257Caharui%2540adobe.com%257C19735c4310c64d1152b808d6cf423d43%257Cfa7b1b5a7b34438794aed2c178decee1%257C0%257C0%257C636924280737194314%26sdata%3DxmrL7z1UB9Mh3FpmbD6iGy9JORZ0YDmXjdiZvDJRm1Y%253D%26reserved%3D0 >>> >>> <https://clicktime.symantec.com/3DP7MFZw5gAqNwkJHvM2oYm7Vc?u=https%3A%2F%2Fnam04.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fajwfrost%252Froyale-playground%252Ftree%252Fmaster%252FCalendarProject%26data%3D02%257C01%257Caharui%2540adobe.com%257C19735c4310c64d1152b808d6cf423d43%257Cfa7b1b5a7b34438794aed2c178decee1%257C0%257C0%257C636924280737194314%26sdata%3DxmrL7z1UB9Mh3FpmbD6iGy9JORZ0YDmXjdiZvDJRm1Y%253D%26reserved%3D0> >>> (the wrapper classes are in src/io/fullcalendar, and the mxml file >>> that uses them is just src/CalendarProject.mxml .. I've been using >>> Moonshine and just uploaded the whole project so there's lots of >>> irrelevant files in there too!) >>> >>> >>> thanks >>> >>> Andrew
