On Tue, Mar 26, 2013 at 5:00 PM, Maxim Solodovnik solomax...@gmail.comwrote:
I believe it is not the big deal how to set recurrences in *.ics files.
import should support both, export can support any.
The main problem is Database.
It should be possible to get the list of instances of recurring
event intersecting given period of time.
I infact assumed that OpenMeetings events directly deals with the ical4j
API and we persist the events through ical4j. As per your explanation, it
is not the case.
So we are persisting the events in our own persistent layer
while in-cooperate with the ical4j API.
In that case we need a Recurrence Event Manager who wraps the previously
mentioned Recurrence event handler (or IcalHandler) and at
#calculateRecurrences(Period) it will fetch the recurrence events from the
DB. And when creating a recurrence event #createRecurrenceEvent(HEvent)
will persist the HEvent meta data to the DB.
Please correct me if I am wrong/or am I missing any part ?
For ex.:
1) you have create annual event in 2002.03.25 (My best friend's birthday)
2) you open calendar and select March 2013
Event created in 2002 should be displayed.
Additionally these events should be editable in All, This and This and
later modes
IcalHandler is necessary for export/import only: 10 lines of code :)
On Tue, Mar 26, 2013 at 6:19 PM, Dishara Wijewardana
ddwijeward...@gmail.com wrote:
Hi all,
I have updated the JIRA with a possible architecture diagram[1] for Open
Meetings Recurrence events implementation.
Here in the diagram, IcalHandler is the one which is already there in the
OpenMeetings core as org.apache.openmeetings.utils.mail.IcalHandler.
I thought of implementing the Recurrence Event Handler on top of this (by
expanding the Icalhandler class) where Recurrence Event Handler will keep
the state of the events and manage everything in related to recurrences
and
provide an abstract interface which can be used by any core module of
the
OpenMeetings. In other words open meetings front end will not directly
call
to the Recurrence Event Handler interface but to some adapter in the core
which will deal with the aforementioned handler.
This way I feel the separation of concerns will meet and we will not
tightly coupled with any iCalculator vendor (which is already happening
now
through the IcalHandler).
Appreciate your valuable feedback on this architecture.
[1] -
https://issues.apache.org/jira/secure/attachment/12575505/recurrence-event-arch.jpg
--
Thanks
/Dishara
--
WBR
Maxim aka solomax
--
Thanks
/Dishara
