我正在构建一个需要支持重复事件的组日历应用程序,但我提出的处理这些事件的所有解决方案似乎都很简单。我可以限制一个人可以看多远的未来,然后一次性生成所有事件。或者,我可以将事件存储为重复的,并在日历上动态显示它们,但如果有人想更改事件的特定实例的细节,则必须将它们转换为正常事件。
我相信有更好的办法,但我还没找到。对重复发生的事件建模的最佳方法是什么?在这种方法中,您可以更改或删除特定事件实例的细节?
(我使用Ruby,但请不要让这限制了你的回答。如果有ruby特定的库或其他东西,那么最好知道。)
将事件存储为重复事件并动态地显示它们,但是允许重复事件包含特定事件的列表,这些事件可以覆盖特定日期的默认信息。
当您查询重复发生的事件时,它可以检查当天的特定覆盖。
如果用户进行了更改,那么您可以询问他是希望更新所有实例(默认详细信息)还是仅更新当天(创建一个新的特定事件并将其添加到列表中)。
如果用户要求删除此事件的所有递归,您还可以获得详细信息列表,并可以轻松删除它们。
唯一有问题的情况是用户想要更新这个事件和所有未来的事件。在这种情况下,你必须把重复发生的事件分成两部分。此时,您可能需要考虑以某种方式链接重复发生的事件,以便将它们全部删除。
我开发了多个基于日历的应用程序,还编写了一组支持递归的可重用JavaScript日历组件。我写了一篇关于如何设计递归式的概述这可能对一些人有帮助。虽然有一些建议是针对我所编写的库的,但所提供的绝大多数建议都适用于任何日历实现。
以下是一些要点:
Store recurrence using the iCal RRULE format -- that's one wheel you really don't want to reinvent
Do NOT store individual recurring event instances as rows in your database! Always store a recurrence pattern.
There are many ways to design your event/exception schema, but a basic starting point example is provided
All date/time values should be stored in UTC and converted to local for display
The end date stored for a recurring event should always be the end date of the recurrence range (or your platform's "max date" if recurring "forever") and the event duration should be stored separately. This is to ensure a sane way of querying for events later. Read the linked article for more details about this.
Some discussion around generating event instances and recurrence editing strategies is included
这是一个非常复杂的话题,有很多很多有效的方法来实现它。我要说的是,我实际上已经成功地实现了几次递归,并且我会谨慎地从那些没有实际使用过递归的人那里获得建议。
我正在处理以下问题:
http://github.com/elevation/event_calendar -日历的模型和助手
http://github.com/seejohnrun/ice_cube -令人敬畏的循环宝石
http://github.com/justinfrench/formtastic -简单表单
以及一个正在进行的gem,它将formtastic扩展为一个输入类型:recurrent (form。schedule:as =>:循环),它会呈现一个类似ical的界面和一个before_filter来将视图再次序列化到一个IceCube对象中。
我的想法是使它难以置信的容易添加循环属性到一个模型,并在视图中容易地连接它。都在几行字里。
这给了我什么?索引,可编辑,循环属性。
Events存储单个日实例,并在日历视图/helper中使用
说的任务。schedule存储了yaml的IceCube对象,所以你可以像这样调用:task.schedule.next_suggestion。
概述:我使用两个模型,一个平面,日历显示,和一个属性的功能。