You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by "Frost, Andrew" <An...@Harman.com> on 2019/05/02 21:07:26 UTC
The start of a FullCalendar Royale component...
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://github.com/ajwfrost/royale-playground/tree/master/CalendarProject
(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
Re: The start of a FullCalendar Royale component...
Posted by Carlos Rovira <ca...@apache.org>.
Shared here! :)
https://twitter.com/ApacheRoyale/status/1124349214127947776
El vie., 3 may. 2019 a las 18:13, Carlos Rovira (<ca...@apache.org>)
escribió:
> Great example Andrew! Thanks for sharing!! :)
>
> El vie., 3 may. 2019 a las 8:49, Piotr Zarzycki (<
> piotrzarzycki21@gmail.com>) escribió:
>
>> Hi Dany,
>>
>> And this comes to conclusion as well - Hey why we cannot bump our version
>> to 1.0 - whatever gap user will have he can literally fill with existing
>> JS
>> components.
>>
>> Thanks,
>> Piotr
>>
>> pt., 3 maj 2019 o 08:28 Dany Dhondt <ar...@mac.com.invalid>
>> napisał(a):
>>
>> > 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 <
>> piotrzarzycki21@gmail.com>
>> > 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 <ah...@adobe.com.invalid>
>> > 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" <An...@Harman.com>
>> 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
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> >
>> >
>>
>> --
>>
>> Piotr Zarzycki
>>
>> Patreon: *https://www.patreon.com/piotrzarzycki
>> <https://www.patreon.com/piotrzarzycki>*
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: The start of a FullCalendar Royale component...
Posted by Carlos Rovira <ca...@apache.org>.
Great example Andrew! Thanks for sharing!! :)
El vie., 3 may. 2019 a las 8:49, Piotr Zarzycki (<pi...@gmail.com>)
escribió:
> Hi Dany,
>
> And this comes to conclusion as well - Hey why we cannot bump our version
> to 1.0 - whatever gap user will have he can literally fill with existing JS
> components.
>
> Thanks,
> Piotr
>
> pt., 3 maj 2019 o 08:28 Dany Dhondt <ar...@mac.com.invalid>
> napisał(a):
>
> > 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 <
> piotrzarzycki21@gmail.com>
> > 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 <ah...@adobe.com.invalid>
> > 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" <An...@Harman.com> 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
> > >>
> > >>
> > >>
> > >>
> > >>
> >
> >
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: The start of a FullCalendar Royale component...
Posted by Piotr Zarzycki <pi...@gmail.com>.
Hi Dany,
And this comes to conclusion as well - Hey why we cannot bump our version
to 1.0 - whatever gap user will have he can literally fill with existing JS
components.
Thanks,
Piotr
pt., 3 maj 2019 o 08:28 Dany Dhondt <ar...@mac.com.invalid> napisał(a):
> 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 <pi...@gmail.com>
> 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 <ah...@adobe.com.invalid>
> 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" <An...@Harman.com> 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
> >>
> >>
> >>
> >>
> >>
>
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: The start of a FullCalendar Royale component...
Posted by Dany Dhondt <ar...@mac.com.INVALID>.
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 <pi...@gmail.com> 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 <ah...@adobe.com.invalid> 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" <An...@Harman.com> 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
>>
>>
>>
>>
>>
Re: The start of a FullCalendar Royale component...
Posted by Piotr Zarzycki <pi...@gmail.com>.
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 <ah...@adobe.com.invalid> 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" <An...@Harman.com> 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
>
>
>
>
>
Re: The start of a FullCalendar Royale component...
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <An...@Harman.com> 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
RE: The start of a FullCalendar Royale component...
Posted by Jonathan Moore <jd...@uvawise.edu>.
Andrew,
You might was to look it some native Actionscript classes. Flex comes to mind Flex 3.3 was the probably the best for animators Adobe and Apache, get familiar with Flex 3rd party frameworks.
Thanks,
Jonathan.
________________________________________
From: Frost, Andrew [Andrew.Frost@Harman.com]
Sent: Thursday, May 02, 2019 5:07 PM
To: dev@royale.apache.org
Subject: The start of a FullCalendar Royale component...
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://github.com/ajwfrost/royale-playground/tree/master/CalendarProject
(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