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]> 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]> 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]> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fajwfrost%2Froyale-playground%2Ftree%2Fmaster%2FCalendarProject&data=02%7C01%7Caharui%40adobe.com%7C19735c4310c64d1152b808d6cf423d43%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924280737194314&sdata=xmrL7z1UB9Mh3FpmbD6iGy9JORZ0YDmXjdiZvDJRm1Y%3D&reserved=0 >> (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 >> >> >> >> >>
