Writing a calendar control is great fun; figuring out the algorithm of how to render multiple appointments on the same time, evolving the API, … The ‘I always wanted to do that’ is what makes a hobby project interesting. Of course the control is no where near as refined as the commercial alternative(s), and it most definitely could use a number of additional skins, but it looks pretty decent and -most importantly- works. 🙂
From an architectural point of view the Agenda control has one clear goal: render appointments. Nothing more, nothing less. The API expects a list of appointments to be rendered, given the time frame that the Agenda control’s currently active skin is displaying. It does not care where the appointments came from, if they are unique, pink, blue, or repeating. It just wants to know the raw meta data, so it can draw the appropriate areas and assign CSS to them.
But that is a fairly primary functionality for an Agenda, suited for programmers who own the domain entities and the application Agenda is embedded in. End users may expect some additional functionality, like notifications, or repeating appointments. And the latter is what David Bal is trying to add.
David chose to create the ICalendarAgenda control by extending Agenda and bolting on the repeating behavior. For this ICalendarAgenda requires a list of instances (vcomponents) for the different types that the iCalendar specification defines; event (vevent), to-do (vtodo), journal (vjournal). Based on these definitions actual appointments are generated and provided to Agenda.
ICalendarAgenda nicely shows how a core control can be extended with additional functionality. In the discussions we had, a lot of time was spent keeping this separation strict, so Agenda can focus on rendering without being obfuscated with repeating logic. It is a good choice of David to use a standard for basing the implementation on. I’m very pleased with how the work is coming along. Keep up the good work, David!
ICalendarAgenda currently is part of JFXtras Labs.