Random notes on Kronolith Ajax view

Full-Display events

are loaded via AjaxFramework Handler/getEvent

this calls into shared code to transform the javascript submitted into a kronolith event
calls event->toJson for frontend presentation
calls attendee->toJson but adds some transformations

Saving an event from Ajax

AjaxFramework saveEvent

$event is initialized from readForm() method
Attendees are scanned for existing and removed

edit.inc includes the mask with both user and attendee fields

Autocompleters

There are suggest-as-you-type autocompleters in the create/edit event forms.

TagAutocompleter, ResourceAutocompleter, ContactAutocompleter and UserAutocompleter are implemented as so-called Imple's - They are an archaic form of ajax framework. We should design replacements for them using horde/http_server and horde/routes.

There is some loss/mismatch of information between users/attendees restored from a saved event and those newly added through the autocompleter. Also, it would be good to have the same window for users and "email attendees" as it feels unnatural to users and also complicates the backend code.

-> Have a unified KronolithUserAttendeeAutocompleter which searches both addressbook entries and users (if listable or searchable) OR a middleware-based equivalent. In the middleware case, more custom JS is needed to emulate/replace the imple behaviour.
-> Use the unified autocompleter
-> drop the specific user field
-> Make the backend smart enough to recognize users either way

kronolith.js addAttendee already CAN accept EITHER a string or a predefined object. Maybe this can be used independently from the Imple framework.

Users COULD be privileged by having kronolith automatically add/update their copy of an event ("Local delivery") rather than sending out itips.