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]] Sent: 03 May 2019 07:28 To: [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]> 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://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 >> >> >> >> >>
