我正在构建一个需要支持重复事件的组日历应用程序,但我提出的处理这些事件的所有解决方案似乎都很简单。我可以限制一个人可以看多远的未来,然后一次性生成所有事件。或者,我可以将事件存储为重复的,并在日历上动态显示它们,但如果有人想更改事件的特定实例的细节,则必须将它们转换为正常事件。

我相信有更好的办法,但我还没找到。对重复发生的事件建模的最佳方法是什么?在这种方法中,您可以更改或删除特定事件实例的细节?

(我使用Ruby,但请不要让这限制了你的回答。如果有ruby特定的库或其他东西,那么最好知道。)


当前回答

重复事件可能会有很多问题,让我强调一些我所知道的。

解决方案1 -没有实例

存储原始约会+复发数据,不存储所有实例。

问题:

当你需要的时候,你必须在一个日期窗口中计算所有的实例,成本很高 无法处理异常(即。你删除一个实例,或者移动它,或者更确切地说,你不能用这个解决方案这样做)

解决方案2 -存储实例

存储从1开始的所有内容,以及链接回原始约会的所有实例。

问题:

占用很大的空间(但是空间很便宜,所以很小) 必须优雅地处理异常,特别是在做出异常后返回并编辑原始约会时。例如,如果您将第三个实例向前移动一天,那么如果您返回并编辑原始约会的时间,在原始日期重新插入另一个实例,并保留已移动的实例,该怎么办?断开移动的那个?试着适当地改变移动的那个?

当然,如果不打算使用异常,那么任何一种解决方案都可以,基本上可以从时间/空间权衡方案中进行选择。

其他回答

I would use a 'link' concept for all future recurring events. They are dynamically displayed in the calendar and link back to a single reference object. When events have taken place the link is broken and the event becomes a standalone instance. If you attempt to edit a recurring event then prompt to change all future items (i.e. change single linked reference) or change just that instance (in which case convert this to a standalone instance and then make change). The latter cased is slightly problematic as you need to keep track in your recurring list of all future events that were converted to single instance. But, this is entirely do-able.

因此,在本质上,有两类事件-单个实例和重复事件。

我建议使用ruby的date库的功能和range模块的语义。循环事件实际上是一个时间,一个日期范围(开始和结束),通常是一周中的某一天。使用日期和范围可以回答任何问题:

#!/usr/bin/ruby
require 'date'

start_date = Date.parse('2008-01-01')
end_date   = Date.parse('2008-04-01')
wday = 5 # friday

(start_date..end_date).select{|d| d.wday == wday}.map{|d| d.to_s}.inspect

产生事件的所有日子,包括闰年!

# =>"[\"2008-01-04\", \"2008-01-11\", \"2008-01-18\", \"2008-01-25\", \"2008-02-01\", \"2008-02-08\", \"2008-02-15\", \"2008-02-22\", \"2008-02-29\", \"2008-03-07\", \"2008-03-14\", \"2008-03-21\", \"2008-03-28\"]"

我使用如下所述的数据库模式来存储递归参数

http://github.com/bakineggs/recurring_events_for

然后使用runt动态计算日期。

https://github.com/mlipper/runt

如果你有一个没有结束日期的重复约会怎么办?虽然空间很便宜,但你没有无限的空间,所以解决方案2在那里是行不通的……

我建议,“没有结束日期”可以解决到本世纪末的结束日期。即使是日常活动,场地数量也很便宜。

您可以直接将事件存储在iCalendar格式中,这允许无限重复、时区本地化等等。

您可以将这些存储在CalDAV服务器中,然后当您想要显示事件时,您可以使用CalDAV中定义的报告选项,要求服务器在所查看的时间段内扩展重复出现的事件。

或者你可以自己将它们存储在数据库中,并使用某种iCalendar解析库来进行扩展,而不需要PUT/GET/REPORT与后端CalDAV服务器进行对话。这可能是更多的工作-我相信CalDAV服务器隐藏的复杂性在某个地方。

从长远来看,以iCalendar格式保存事件可能会让事情变得更简单,因为人们总是希望将它们导出,以便放在其他软件中。