Re: Standalone Lightning for webapps?

On 27.01.2016 19:39, Philipp Kewisch wrote:
> 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 :)
>
>
Just to complement Philipp's answer.
He mentioned "sabredav", see the fruux pages which is based on sabredav.
Head over to https://fruux.com/developers/

Good luck