Re: Standalone Lightning for webapps?

On 1/27/16 4:13 PM, CC wrote:
> On Wednesday, January 27, 2016 at 2:32:33 PM UTC, Alan Lord wrote:
> 
>> How about using something like:
>>
>> http://fullcalendar.io/
> 
> I think - I may be wrong - that it only displays a public Google calendar. Public calendars appear in search results and can be viewed by anybody. The calendar itself is stored at Google. If you want to change the calendar, you have to log on at Google with a Google account. It looks nice, but has a very limited use case. I could do pretty much the same trivially by displaying the source calendar in an iframe, and Google gives you a link to do exactly that.
> 
> I've looked at a lot of other options, but they all have similar limitations. Basically, the JS/jQuery ones are, I think, all display-only, so you have to handle talking to the calendar server yourself in your server code.
> 
> The advantage of using the Lightning code would be that it handles both the front- and back-end: it talks to the calendar server, *and* it creates JS for output. I think. This lets you create private calendars which can be both read and written by a group of users.
> 

The Lightning code is pretty much geared towards working in a client
side application. If you are implementing this from scratch I'd rather
suggest using various other libraries. You should defintiely do 1,  then
you have the choice of either doing 2, 3 or 4.


1) Fullcalendar
This is really the best solution for calendar display in the browser.
Use a custom backend that hooks up to the remote server and maybe does
some caching.

2) dav.js + ical.js
This should allow you to access the calendar server from a client. Using
it directly from the browser may not work with many servers due to CORS.
If you tell the server to accept CORS you might be able to though. If
you use sabredav, you can check out the CORSPlugin in the repo mentioned
in (4).

You can possibly use dav.js from node though and proxy the data in any
format you want if you prefer the indirection.

You can then use ical.js to parse the ical data (or have the server
return jCal instead, calendarserver/sabredav support this), then hand
this off to fullcalendar or whatever else you use.


3) JMAP (https://github.com/jmapio)
You can use the jmap-perl proxy to proxy calls to the caldav server,
then use the jmap protocol to show the data in the frontend. See also
https://github.com/linagora/jmap-client for a client implementation,
note it is currently geared towards mail though. There also seems to be
another js library for it on the jmapio site.

4) custom JSON frontend using HAL + ical.js
If you can choose the actual caldav server, you could use sabredav and
then use/adapt the custom frontend Linagora wrote for it. The frontend
serves the calendar data in a JSON format using the HAL standard.
https://github.com/linagora/esn-sabre

You may still need ical.js to parse the server data though.

Writing a full calendaring solution is not an easy task though :)