5.x-3.x - eventrepeat as API

One idea I have been playing around with is the idea of using CCK's multiple field option to put all repeating events into a single node with a separate field for each repeated event. That way you provide a single title and description for all events and display a list of the dates and times it repeats. Then we would use views to display each field on a calendar in the same way each node is displayed now (the calendar view code is pretty well fleshed out in the event_views module and just needs to be tweaked a bit to make it work this way). This would require changes in the event repeat code to create fields instead of nodes for each repeat, and I don't know how difficult that would be to do. I'm not sure yet how you handle the from and to time for each event, so that also needs to be thought through.

No time to work on this myself right now, just throwing this out there as something to consider.

Both of these are interesting suggestions. Anyone else interested in this who can spend some time on figuring out the potential problems would be most welcome to pitch in. As I stated in another issue, the functions that create repeat patterns are pretty complex and even small changes can cause massive bugs. After the new 4.7 release I'd be interested in exploring this more.

Just to take this a bit further, I think the changes I would make in event repeat would be to separate logic and database update functions, i.e. right now many function both determine the list of dates or ical string that is required and then immediately query or update the database. If they stopped and returned an array of dates or the ical string and then database queries and updates were done using a different function it might be easier to hook in a different option for the database handling or even let the module function as an api where cck can just grab the date array and do the database update itself. Plus, it might actually make the event repeat module a bit easier to maintain if database operations were consolidated in a single place.

Great suggestion Karen. Making the code more modular and api-like is something I've been wanting to do since I first took over this module several months ago, but I've been holding off due to the complexity of the module. I think it would be a great objective for the 5.0 version and would pave the way for a lot of improvements.

I probably have some code that will help this effort along. I needed repeating dates that did not create nodes for a recurring acoustic jam session tracking site a friend and I built (www.folkjam.org). I took eventrepeat as a base and created what I dubbed 'eventproject'.

The basic design of eventproject is the same as eventrepeat. The ical based date calculation logic is all the same. What differs is how the module keeps data. Rather than cloning events and altering the {event} table data to the correct dates, the module keeps a single copy of the node. Like eventrepeat, eventproject adds one record into a separate table to hold the repeat details. Where it differs in storage is that eventproject builds out instances of the following table for each repeat:

CREATE TABLE IF NOT EXISTS {event_projected_node} (
        projection_id int(10) unsigned NOT NULL default '0' auto_increment,
        nid int(10) unsigned NOT NULL default '0',
        event_start int(10) unsigned NOT NULL default '0',
        event_end int(10) unsigned NOT NULL default '0',
        timezone int(10) NOT NULL default '0',
        PRIMARY KEY (projection_id), KEY nid (nid), KEY event_start (event_start))

The fields in this structure are intentionally named after the fields in {event}. What I do when data is loaded up is create 'synthetic events'. I load up the node and then blend in the fields that are expected by the event module from this table. With a patch to the event module, the synthetic events from eventproject are able to appear in calendar views.

Some added functionality that I've worked in is a tab that describes the repeat rule to a user as well as a tab that shows all upcoming dates. You can see these in action on any of the jam session nodes on folkjam.org. http://www.folkjam.org/node/1972 is an example of a monthly recurring event. Note that there remains a bug in my code (and possibly in eventrepeat too) where a scenario causes {event_projected_node} records to be created again, causing duplicate dates on the calendars. I'm working on finding that one.

I'm talking with Sean on how and whether to contribute this code back. My biggest concern right now is my own time constraints that keep me from having the time to respond quickly to issues.

If there is interest I'll create myself a sandbox in Drupal's cvs and add this module to it for you to study.

I am very interested in sharing this change to eventrepeat back to the community - I don't see many people defending the eventrepeat behavior of making node copies. I understand why hunmonk did it, but I think we can do better now.

heh. i'm laughing because i fought hard when doing the initial layout of eventrepeat, to _not_ create/manipulate a bunch of nodes--all the other systems i researched used a dynamic rendering technique which i found much more elegant than the current approach--but killes and crunchwelch repeatedly insisted that for drupal, nodes should be created. since this was my first module, and i figured they knew something i didn't, i wrote it that way... :)

it's been awhile, so their exact reasoning has escaped me, but if you guys are serious about this approach, you might want to get some feedback from them--as i recall there were some valid reasons why the current approach was good.

reading over the thread, the suggestions sound more like the dynamic approach i was initially in favor of. the current eventrepeat code is just stupidly complex--i know i'd like to see it become more simple and flexible. i'm afraid i don't any time to help, but good luck!

I can certainly see the humor here given the full circle. Having used both the "make nodes" version and the "make lightweight date projection entry" versions of eventrepeat I would argue hard against making nodes. I can see where this violates some Drupal concepts about everything being a node, but that is not always the right answer. I don't see referrer logs being kept as nodes. :)

I had an argument with myself before rewriting my own event repeating logic for www.folkjam.org. One of the winning arguments was about associating data back to an event that repeats, like comments, ratings, reviews and regular attendees. While the latter three features are not up on our site yet, they didn't make sense in a world where I would have had to associate them with an ever growing number of nodes through the RID (repeat identifier for those who have not lived in this code). Why do that, when I can associate them with one node and then associate it with a list of dates in the future?

Anyway, it works better for our needs. It has some limitations too, like no multi-day repeating events.

If nodes are content than events shouldn't be nodes, IMHO.

Events are the connection with the real world and have nothing to do with content (yet). You could make it content once you (or a module) decides the event is important enough to make it content. Not all "interested" modules would want to make it content (at all or not at once). That is what I understand events should be.

So to go back karenS question (http://groups.drupal.org/node/1528#comment) whether eventrepeat should be a single node, I think events should be fundamentally different. They can be the source of a single or many nodes, or just stay an event. I have tried to trigger reaction before(http://groups.drupal.org/node/1521#comment), so I maybe far off.

+1 on this concept. sounds like the most flexible way to go.

I like the idea of splitting the logic down the middle, it gives a compatibilty path for the current eventrepeat, which is not a problem I'd addressed.

I've written the other half described in point #1 by Grugnog2, where eventrepeat (renamed eventproject) does not create nodes, but instead calculates future dates and writes them into a very simple row that is bound back to the node[1]. Sean has the code in his hands and is reviewing it. I've had it on production on folkjam.org for a few months now and am satisfied that the bugs have been 98% worked out. I also have a patch (not submitted) to event.module to allow it to include non-nodes on calendars.

If you want the code for review and assessment, contact me. I will share the tarball with anybody who has commit access to eventrepeat or who Sean asks me to share it with. I am not posting it anywhere that can be found by the average user because I don't want to create the chaos of two event repeating modules. That would be bad for everybody.

Scott

[1] The structure of that row is described here: http://drupal.org/node/87600#comment-146600

just a note that most of the systems i researched prior to writing eventrepeat did it a bit different: they only created a separate piece of content when something was altered on a day in the repeat pattern. for example, if november 8th was in the repeat pattern, but had no customizations, then it was just generated on the fly for display in calendars. if, however, the title was changed, then that day was actually created as a piece of content, and stored and retrieved as a piece of content in respect to the calendaring. i believe also that the day was then logged as an exception in the repeat pattern, to prevent it from being displayed twice. i liked this approach, because it seems to offer the best of both worlds.

This is great stuff. One question: When you talk about altered events in the repeat pattern generating a derivative are we talking about generating new nodes? What do we want to happen when someone creates several altered events from the main repeat pattern, and then he/she wants to update the whole group of events. For example, I have a weekly event, but 15 of them this year will need to be at a different time and in a different room. At some point the name of the event changes, and I want to change it across all of my events. Ideally it would be nice if there were a way to change the "master" event and have the OPTION to change all altered events as well. Or is this a road we shouldn't go down.

hunmonk - Generating the dates on the fly is not so far off from what we have today. You laid the foundation with the hook that was added to the event module to make sure that eventrepeat created nodes within the appropriate time frame before the event module read up the set of nodes it needed to display.

I added a similar hook to eventproject, my hacked eventrepeat variant. The major difference is that the hook brings back the data rather than ensuring that the data is in the database. This seemed to be the most appropriate way to integrate information into the calendar that was not an explicit node. Behind that hook eventproject runs the same logic that eventrepeat does to ensure the right data is in the database for that time frame, then it queries the db and sends the results back to the caller (the event module in this example) for processing. It is not a big logical leap to change this to read in the exceptions from the database and blend that with rows that are created on the fly based on the repeating rules.

I do wonder about the cost of doing it this way. By having one row written out for every date most of the heavy lifting is done by the database. Creating the result set on the fly would require reading in and processing every single node that was repeat-enabled and evaluating the ruleset, even for those nodes that did not have dates in the requested time frame. On a site like ours where nodes with repeats far outweigh nodes without repeats I worry about performance.

It certainly sounds more elegant this way.

I am working on a views calendar module that will display any node date field in Views which is going to be nice, but to work in views nodes must actually exist in the database, so generating them on the fly won't work for that purpose. Creating them in the database as cck date fields also works with Views, since cck fields are views-enabled, but again, generating fields on the fly would make them unavailable to Views. Just something to keep in mind as you think through this...

all this just makes me glad i'm not the module maintainer anymore. kind of makes your head hurt, doesn't it?? ;)

I finally sat down and figured out the new release system. HEAD has been branched to 4.7.x-2.x, meaning the current HEAD can now be used to develop a 5.0 compatible version. Event.module has recently released a patch to make it 5.0 compatible, so at this point, patches are welcome!

Name changed to make this the general issue for converting to 5.0 and using CCK.

I'm just starting to look at this stuff, but thought I would respond to comments 14 and 15. I'm in favor (like everyone it seems) of splitting the repetition from the nodes.

I think an initial implementation could naively allow a repeat pattern to be associated with an exact event ( == node). If anything in the event changed (including an exception in the repeat pattern) then it would be a differerent event (and node). Having one event's repeat pattern skip around another event's repeat pattern (because of an event split) could be added later, but might be confusing.

It would seem to address Sean's concern in 15 that each event node could have an additional field indicating a root event, from which it was derived. This would allow all events in a chain to be altered if necessary. You could then choose also to delete the whole chain if you wanted. I think there is also some work going on somewhere in relationships between events. That work could be exploited to related events in a sequence. However I don't think any of that is needed in an initial implementation.

I've been emailing between Sean (maintainer of Event repeat), KarenS, Gerhard and others to iron this out.

As of now date module now supports both to and from fields and can do some basic repeating in essence.

However, there still needs to be a solid API for having repeat events. It is my opinion that this should live with date module, *but* as a separate module that can be turned on/off.

99% of the time if you need repeat functionality, you need to use date module, makes the most sense to have those two live together.

If you haven't already, check out the latest version of date module (as of 21 Jan) to see this new functionality -- it might sway your vote if you don't already agree with me :-)

so is there a version that will work with v5? I started a site in v5 and I may have to scrap it all to go back to v4.7 as this is one module that I need now.

Several people have asked about getting eventrepeat's current functionality updated for Drupal 5. I'll be working on that sooner rather than later. I'll update progress for that at http://drupal.org/node/108276

As far as a date repeat module vs. eventrepeat goes, I'm still conflicted. At this point everyone agrees that we should move away from creating multiple nodes for repeating events. Right now I feel like there are enough people still using event.module that I can't ditch it for date.module. I still think there could be some value in rewriting eventrepeat so that it presents a nodeapi interface for creating a repeat pattern and returns an array of instances based on that pattern. This would be much more of an API approach, where calendar.module and event.module (as well as any modules that come up down the road) would need to have the tools to parse this array plot these instances. I personally like the date.module + calendar.module approach and would like to gravitate towards that, but I feel somewhat tied to the existing module.

Feedback encouraged.

Name change to differentiate between the other Drupal5 issue.

What is the reason to not create new nodes for repeating events?

If the views.module requires nodes then we want nodes, right?

I would think the repeat module could create a list of the nodes it creates, thereby connecting them for editing, review, etc.

Maybe this could be done in a database table, or maybe as a node itself that only serves to maintain the repeats.

just some ideas to chew on...looking forward to future versions

@Lowell: what you described is how the module works now.

lol

maybe I was thinking that it would be moved to using cck instead of just the event content type.

please let me know if I am just babbling 'again'

Here's the idea I'm playing around with right now:

1) The event repeat module is reconfigured to provide an API in addition to creating and storing event nodes itself. I visualize something like being able to submit an iCal repeat string as a http request as the instruction about what is wanted and receiving back an array of dates that fit the requested criteria.

2) The dates would not be stored as nodes or as fields, instead, the date array would be cached (and would expire eventually for periods that no one is looking at) so there could be unlimited dates without filling up the database with values that are never or seldom used.

3) The date module would be altered to provide a way for you to select a pattern and would store the pattern string, but would not actually store the dates. When you view the node, it would display a description of the repeat pattern (every Tues and Thursday from April 1 to June 30), rather than the dates themselves. That keeps the display nice and neat. Then there would be a tab or button you could use to see the actual list of dates. Those dates would be retrieved from the cache, maybe in the background using jQuery.

4) The trick was whether I could get the dates to display in the calendar if they didn't actually exist in the database, but I think I have that figured out too. I have reconfigured the calendar so you can insert items from a feed, like an ical feed. I will just set it up so it also inserts a 'feed' from the repeated dates cache as well.

This is still theoretical, have to see if it will really work :-)

This is still theoretical, have to see if it will really work :-)

Parts of it are not actually, although the implementation differs from where we are likely to end up.

1) The event repeat module is reconfigured to provide an API in addition to creating and storing event nodes itself. I visualize something like being able to submit an iCal repeat string as a http request as the instruction about what is wanted and receiving back an array of dates that fit the requested criteria.

In addition, such an API would need a date range in which to render dates, and would need to support interrogation to see if the range has already been partially or fully rendered. I may be too bound to current eventrepeat semantics as I think about this (I've done substantial work on the module). The module deals with ongoing generation of dates in a way that an API needs to capture.

2) The dates would not be stored as nodes or as fields, instead, the date array would be cached (and would expire eventually for periods that no one is looking at) so there could be unlimited dates without filling up the database with values that are never or seldom used.

I am with you 100% on not creating nodes. I believe that maintaining a date array that is opaque to SQL queries would be problematic for performance. One of the biggest challenges I've had with building folkjam.org has been in blending node-based event dates with non-node based eventrepeat dates[1]. The UNION I started out with was problematic enough with performance, and digging into a compound date array field would be even worse.

3) The date module would be altered to provide a way for you to select a pattern and would store the pattern string, but would not actually store the dates. When you view the node, it would display a description of the repeat pattern (every Tues and Thursday from April 1 to June 30), ...

A simple version of this can be seen in action here http://www.folkjam.org/node/3354/repeatdetails and here http://www.folkjam.org/node/3354/upcomingdates. Although I've still not spent the time to get the "April 1 to June 30" part working. I'd love some code to round that out.

4) The trick was whether I could get the dates to display in the calendar if they didn't actually exist in the database, but I think I have that figured out too. I have reconfigured the calendar so you can insert items from a feed, like an ical feed. I will just set it up so it also inserts a 'feed' from the repeated dates cache as well.

This works fine. I've done something similar to the event (4.7) module to blend in actual nodes with what I termed synthetic nodes. Taking in a feed is a cleaner approach - I just added a hook and passed back data formatted in the way that event would want it. One problem with the event module's internal data structure is that it keyed by NID. Since a single NID has many dates in my module and many can appear on a single calendar view, I had to change the key structure. I don't know what the CCK calendar code looks like - does it key by NID for the internal storage of the date data?

Scott

[1] I use my own refactored version of eventrepeat that I call eventproject. It does not use nodes for the repeats, but instead creates simple {nid,start,end,timezone} entries in a table. Sean is also well aware of it and has the code.

It's worth noting that KarenS, m3avrck and others will be holding a session about the future of events at DrupalCon next week. Unfortunately I can't make it, as I'll be out of the country.

As a side note, I'll also won't be around to check up from the 16th until the 26th. I'll check in when I'm back, and hopefully we'll have some news about the future of this module in the near future.

I'm curious about how some of the above strategies compare to how WebCalendar does this (an open source application). I've tested WebCalendar and it seemed to be a pretty robust event system with repeating events. Do they have a nice way of handling repeating events without performance and database issues? See http://sourceforge.net/projects/webcalendar/

I should add that I have really no idea of what's under WebCalendar's hood, so I'm asking the above question mainly to find out your inside perception of this. I'm not trying to offend your efforts by suggesting this other application does things better (I just thought there might be some wheel that was already invented there-- although I know they are not dealing with the need to integrate these things with nodes, etc.) So, I'm sure, in many ways, what is being done with events in Drupal is far more powerful than what WebCalendar could accomplish (integration with views, organic groups, taxonomy, etc.). Anyway, carry on and share your comparitive analysis only if you feel so inclined.

I took a quick look out of curiosity, and the WebCalendar download file is nearly 3MB to do nothing but calendars, which is nearly as big as Drupal 5.1 core + CCK 5.x + Views 5.x combined. A lot of the WebCalendar size comes from translations and documentation, but I still thought that was an interesting comparison.

Anyway, the program is so huge it's hard to figure out how it works without spending an awful lot of time. I'm not suggesting there aren't things to be learned from it, it is useful to see how other calendar applications handle things. I can see how the UI works in their demo (well sort of since the demo is broken) but I can't tell how they store the repeat data or how they handle those resource intensive repeat calculations, and that's the part I'm curious about.

If one has a repeating event, say a weekly class or a monthly meeting, that has a different topic each time, or different guest lecturers, could that be handled without creating a separate node for each instance? In Apple's iCal, we can create a repeating event, but then we can customize each one, and it asks, change only this instance, or change every future instance? I'm not sure what to do with that kind of situation now. I use date to make multiple dates and then within the node list the info for the next date, or for the next series of dates, but if i continually revise the node's info, then I cease to have an accurate archive. When someone clicks on an old date in Calendar view, they will not see the text specific to that past event. It's not the end of the world, but it would be great to work towards a solution, however distant in the future, when these problems are dealt with in a satisfactory manner.

Changing the title back since this is a thread to discuss that issue.

The best way to handle this now would be to not treat those events as repeats but as individual events that each have their own topic, speaker, location. It sounds like the only thing that really ties them together is that they all take place at the same time and they are part of a series, and you could use either taxonomy or a CCK field to identify the name of the series to provide a way to link them together.

And yes, there is a question about how to treat things like making changes to individual items in a series. That makes the handling of repeats even more complex and it is already extremely complex. My inclination would be to focus on finding a way to handle repeats that have the same characteristics for the whole series, at least for now, and leave more complex things like that to be considered later.

@scott.mclewin, I finally had time to go look at your site to see what you're talking about. I think that is very close to the direction I was thinking about, too so I'd like to find out more about how you accomplish that. And how do you put those dates on a calendar?

In the Calendar module I manufacture a nid that is a combination of the nid, the fieldname, and the delta to make sure it is unique (in the calendar module any field can be on a calendar, so you can have multiple values of multiple fields within the same node, lots of possible duplicate nids). Then I just have to fix the nid just before I send it to the theme to create a link to the title.

@scott, also, I intended that I would pass a date range to the API along with the string, but was not planning for the API to worry about whether or not it was already rendered, just blindly return the dates that fit the pattern. And there is no worry about integrating the cached array with SQL - SQL is not used. In the Calendar module Views is doing a SQL query of the nodes that exist in the database and returning an array of results, then I merge my cached feed array with the Views array to produce the calendar. My plan is to do my own handling of storing the dates and worrying about whether or not they already have been rendered, I just need an API that can take an ical string and return a list of dates that need to be generated, and maybe another API that can create a form to create the repeat string.

@KarenS - responses to several items in our running thread.

so I'd like to find out more about how you accomplish that. And how do you put those dates on a calendar? Certainly. I'm willing to hop on the phone with you to talk through it. With Sean's approval I'll share the eventproject.module code with you as well, including my minor patch to the event.module to make it understand what I dubbed 'synthetic nodes'. Those are quite simply all the data from the repeating node with the date fields replaced by whatever date is appropriate.

In the Calendar module Views is doing a SQL query of the nodes that exist in the database and returning an array of results, then I merge my cached feed array with the Views array to produce the calendar.
This fundamentally concerns me, as using the database to handle massive data operations is the route I always aim to take. It is not alwasy possible to do so, but that is my guiding principle. You may have enough facts to remove my concern (benchmarks, well laid out arguments, etc). Just reading that sentence cause a minor cringe.

I intended that I would pass a date range to the API along with the string, but was not planning for the API to worry about whether or not it was already rendered, just blindly return the dates that fit the pattern.
Don't loose sight of exceptions. Eventrepeat and eventproject both allow for exceptions in the dates being rendered, where the node editor can give a list of dates where an event should not be rendered. That gets used a lot on folkjam.org. A feature that is requested about once a month is the ability to add an off-series date into the series. This is primarily used when recurring events conflict with holidays or other big local events like festivals and the user excepts out the conflicting date and wants to add back in the adjusted date. Additionally, we have a case we need to cover when somebody has a repeating event that follows no programatic rules, but they still want it to show up on our site as a repeating event, as a single place where comments and users can be centralized. The 'add' exception is how I plan to deal with that too.

@scott, the reason for using a cached array for the repeats instead of putting them in the database goes back to m3avrck's concern about adding an infinite number of nodes as actual items in the database for dates with no real start and end time or for those that repeat often enough that the number of repeats could get huge. My original plan for date repeats was to actually create them in the database (as multiple value fields for a date), and m3avrck cringed at that idea. The idea of using a cached feed was an alternative way to avoid doing that. The idea is that separate cached feeds would be created for various time periods as needed, then they would be allowed to expire if not used again. That way the database wouldn't fill up with every possible date a repeating event could occur, and we would only be dealing with those dates that are actually being requested.

So either way we go I've got one of you cringing :-)

KarenS/the reason for using a cached array for the repeats instead of putting them in the database goes back to m3avrck's concern about adding an infinite number of nodes as actual items
Oh, lots of nodes makes me cringe too. I guess I'm a cranky old guy already.

Storing the repeats in the database does not require storing the full node. My implementation stores a single node and then a series of these:

      $query2 = db_query("CREATE TABLE IF NOT EXISTS {event_projected_node} (
                            projection_id int(10) unsigned NOT NULL default '0' auto_increment,
                            nid int(10) unsigned NOT NULL default '0',
			                event_start int(10) unsigned NOT NULL default '0',
            			    event_end int(10) unsigned NOT NULL default '0',
			                timezone int(10) NOT NULL default '0',
			                PRIMARY KEY (projection_id),
			                KEY nid (nid),
            			    KEY event_start (event_start)
                          ) TYPE=MyISAM /*!40100 DEFAULT CHARACTER SET utf8 */;");

The hook_nodeapi code pulls in the 'next' one to populate the timezone, event_start and event_end fields and also loads up an array of the next three events. Other APIs exist to pull up 'the node' at a different date. Duplicate nodes are never stored, but repeating dates into the future are in the DB, allowing me to use the database engine to crunch data.

I misspoke. I was never proposing storing an infinite number of nodes, I was going to store the data with one node that has multiple date fields. The way CCK stores multiple field values is in a table very similar to the one you are using, which would look like nid, vid, delta, value, value2, offset, timezone for each individual repeat, where the delta creates a unique instance of the date. That can all be done in CCK quite easily using the normal methods of handling multiple values, but there was still a concern about storing all that in the database.

@KarenS - Misspeaking forgiven. :)

I am far more inclined to maintain the repeat dates in the database than calculating them on the fly. I think calculation on the fly is the wrong path in the design.

Clearly a lot of thought and debate has already gone into how to model repeating events. Am I just making noise here on a dead/retired topic?

@scott, not at all! We need to think all these issues through carefully, and you clearly have experience finding a way to do it.

Hehe-- Scott, if you're just adding noise, then what I'm going to suggest will just be a silly cacophany

I'm also coming at this from a DB-centric background, so I'm not sure how it fits into a world that includes PHP -- and I'm not all that familiar with the drupal schema, so if this just won't work, then let me know. But I could easily see a multi-table approach to both the repeating dates (where we store the repeated dates in a table) and exceptions to series. There would be one table that stores all the default attributes (description, text, etc.) in a table, and creates a series of rows with the corresponding date in a second table. Then, in a third table, any exceptions are stored, with links from the date table. So if there are comments about a particular event, a custom description, etc, it creates an entry in the third table.

First thought is that the third table is essentially a node. So I guess i'm suggesting that default events aren't new nodes, but if something is customized, then it becomes one.

And the views would have to use outer joins, and any link from the calendar would have to use a case statement to see if there's a new node for that particular instance.

Does that make sense, or should I provide a sketch of examples? :/

@jhpark (#45) - Your silly cacophany mostly describes how the custom implementation I'm using on folkjam.org works, and basically how eventrepeat works. The major difference between my bespoke solution and eventrepeat is the use of nodes to store repeat dates vs little entries in a table (the one defined here). A secondary difference is how exceptions are handled in eventrepeat.

Eventrepeat stores a seralized PHP array of exception dates in the event repeat specific table that logically extends the node record. When date rendering is done (that is, the act of calculating dates for the requested window) the rendering logic simply does not create dates when the GMT adjusted render date matches a date in the exception array. IMHO this is a good solution and reduces the need to join an exception table to the dates table at query time.

@KarenS (#44) - Ok. I'll continue working to shape this with you. I believe that having the repeat dates in a database is a crucial design element. I also believe that having them as nodes is the wrong path. I wonder where Sean is. As soon as I get his clearance I'll send you the eventproject code and my event module patch that teaches it to handle rendering of multiple dates for a single node.

I've had trouble understanding a lot of this extensive thread, so please forgive if I'm off topic or missed some crucial issue, but FWIW, from a UI perspective I want to agree with jhpark @#45 on the not_node/node question : "So I guess i'm suggesting that default events aren't new nodes, but if something is customized, then it becomes one."

Does the analogy schedule/event = not_node/node work well here?

I picture the UI as ... a schedule is a list of timeslots (date-ranges) generated from a schedule_pattern, each timeslot is a placeholder_link (like Wikipedia's unwritten articles) for a single 'event' node. If an event node has not been created for a given timeslot yet, the first authorised person to use the link may create the node ...

1. create node content & title (or reset title/link label if that's been generated too ?),
2. move or apply this node's content to (an)other timeslot(s) in the same schedule (some kind of widget for multiple-selecting timeslots ...?),
3. (if authorised to edit the schedule) reset or delete/disable this timeslot from the schedule (creating an exception to the schedule_pattern),

... that would be quite acceptable, thank you ;)

From my understanding of the permissions system, it would seem that each schedule should be a node, and events are of course nodes. The schedule/timeslot/event relationship is basically a grandparent/parent/child relationship. Timeslots, however, should not be nodes but each an exclusive possible relationship between a schedule and an event. (See relativity.module for some very subtle methods of allowing various configuration rules for parent/child relationships, eg event_type_A may have one or more (timeslots on one or more) schedule_type_B parents ... , etc, etc)

If there can be only one event node for each scheduled timeslot (default), the schedule is effectively a series of exclusive timeslots. Thus it is a very short step to (for example) a resource booking schedule ... the resource (eg the village bike) is constructed as a schedule with (1 hour) timeslots corresponding to the schedule_pattern : repeat every hour between 9am and 5pm weekdays. When someone wants to book the bike, they create a node as a child of the relevant timeslots ... If the event is a CCK node that hangs on a given 'timeline', it can have whatever fields are necessary but it's date&time is fixed by it's parent timeslot. The View (eg Calendar) of the schedule would only need to distinguish between (not_timeslot,) timeslot_without_child, and timeslot_with_child.

I hope you can see that this one example suggests how the 'repeat event' feature could potentially have many diverse applications. ... I don't think I am off topic ;)

oh one more thought ... could the event repeat module be manifest as a mere CCK field widget (that generates the list of timeslots), with admin/settings/event_repeat for configuring the rules per-content-type of timeslot_node_relationships ;?

Finally had a chance to digest the conversation from when I was on vacation. Here are some quick thoughts:

For the UI:
The favored model for the interface consistently rolls around to iCal. I'd like to keep us in that direction, as it is a proven solution that is easy for most people to understand. Obviously, whatever makes the most sense is the way to go, and this is definitely still open for debate, but I think we can take m3avrck's ideas and make this sexy.

For repeating events that are not quite repeating events:
There is an alternative type of repeating events that I've encountered numerous times, and this is the scheduled approach. Over a year ago I wrote an small module that could schedule theater runs, allowing a parent and child relationship between a page-type node and events. This allowed you to layout multiple events of a similar type in one shot, giving each slightly different nids, titles, content, times, etc. This is a slightly different project from true repeating events. It sounds like there is still some interest here and there in something that facilitates this kind of thing, so maybe I'll try and dust that module off and post it somewhere. I just wanted to bring that up as the wall of "out of scope" for this discussion so that we all know where the focus is.

On exceptions:
One thing about the current eventrepeat that can be a bit misleading is that the word exception is a bit ambiguous:

First there are exceptions as defined by the repeat string, as per the iCal specification, currently held in the eventrepeat table (this is not a serialized array). These simply tell the repeat sequence to skip certain dates. The eventrepeat module currently only uses this when creating event nodes. At the point of displaying a calendar, the nodes exist on their own and use standard event module procedures.

Second there are the edited event exceptions where the "This occurrence only" radio button was selected. All that happened is that the event node was modified. The event string was not changed. At the point of dispalying a calendar, the nodes use standard event module procedures. Checking the "Leave individual edits in sequence" box in the settings page means that the rid to nid relationship is still in the event_repeat_nodes table. This will result in your changes being over-written (the way iCal behaves). Otherwise it is not, and editing the event with "Apply to all" checked will re-create the edited event so that you can potentially have two on that day.

A third type of exception is the deleted node type exception. This is where you deleted one event in the series, with "This occurrence only" checked on the delete confirmation screen. As far as the repeat string is concerned, that instance still exists, but the repeat id to node id relationship may or may not still be there based on the "Leave individual edits in sequence" option. Again, if you edit your repeating event, the deleted event will come back if it is still in the sequence. Otherwise, the relationship will have been removed that node does not get re-created.

The fourth type is not really an exception, but is important to remember when thinking this through. This is the edit all future occurrences exceptions. Here you've edited an event and choosen "all future occurrences" radio button. In this case, you are actually truncating the old set of repeating events by adjusting the repeat_end date. A new repeating id and string are created and event_repeat_nodes is updated to change all of the events nids to use the new rid. All the nodes are also updated.

OK, that may have been a bit too basic at some levels, but I thought having that comprehensive list of behaviors might be helpful in this discussion.

As always, a big thanks to hunmonk for writing this wonderful beast in the first place. ;)

Do we feel that we're at a point where we can start talking next steps?

Also, I'd love to hear if anything came out of DrupalCon that might affect what we are doing. Anyone?

If remark #36 of this thread means that a simple repeating event like a weekly class with just different topics is not going to be handled by a new eventrepeat module one should really rethink the design, IMO.

The module should handle repeating events like:
New years day
Birthday’s
Workdays
Meetings
Roomreservations
Weekly classes
Visits to the therapist

Why should event repeat be so complex? Because we have a hard time understanding what a repeated event is? Could eventrepeat be a php Class with properties? Could an event be an object?

Can the discussion about “node or no node” be handled by creating a module "eventnode" similar to "usernode"? Sometimes we really like it if users can become nodes:
http://drupal.org/node/130756

Obviously an event must have properties with standard values, but they should not be fixed. We should be able to change a “Topic” attribute as well as begin date, begin time, end date, end time, and body-properties. Should an event have a time property at all times? Isn't title and desciption not enough to call it an event?

Now should an event repeat indefinitely, no (cause they don’t in real life). Repetition depends on the event, so it should be flexible, but obligatory at creation time. It may have a maximum to prevent countless repetitions. One could repeat a "new years day" event a thousand times, repeat one's own birthday for a 100 years, repeat workdays for 10 years, repeat a meeting schedule for 1 year, repeat visits to therapist for 9 weeks, repeat weekly classes for a semester, etcetera. Just before the end of a repetition period one may want/need to extend the repetition, some more visits to the therapist, plan the meetings for the upcomming year, etcetera.

IMO, a simple workflow could be:

Create an eventrepeat (a class with standard property values)
Decide on a repetition period
Create events (objects in that repetition period)
Offer a list of events/eventrepeats in the repetition period.

Allow properties of each event to be edited
Allow properties to be extended (hmm?)
Allow the event list to be extended by changing the repetition period, adding an extra event/object.
Allow deletion of (multiple) events/objects
Allow the creation of a node for each event/object. You make it a node if you consider the event important enough to call them content. For example your grandma’s birthday is usually not "a node", but just "a reminder". If she turns 75 years old you may want to throw a party, ask for volunteer, ask people to chip-in etcetera. At that point the event may become a node.

Always allow to go back to the list of events/eventrepeats, to extend the list, edit, delete events or to turn them into a node.

Just my 2 cents.

The work flow that #36 outlines would seem to be the ideal end-goal. It emulates the work flow of iCal, where you create events, then make exceptions. This is how eventrepeat currently works, and I agree that it'd be nice to keep that functionality in some manner. Essentially what you are doing is dropping the repeating event out of the sequence and making a stand-alone event out of it.

The code to get repeating events would need to know to skip that event. At some point, a "Leave individual edits in sequence" option might be useful, where the repeating event might have to know to kill the exception and start paying attention to the original again.

Karen and Scott, does that work with your underlying concepts? At what point do you think this would get sticky?

And to clarify, my point about scope in #50 above dealt with a string of events where there was no consistent pattern (like a theater run). Apologies if that wasn't clear.

Having just carefully re-read this entire thread, the direction of this discussion seems to be:
How to extract a particularly interesting function from eventrepeat and rebuild it as an API or something so that it can be used more widely.
The interesting function -basically- accepts parameters to define a pattern and then generates a list of definite timeslots that correspond to that pattern.

It may be helpful to agree terms for some key concepts:
a) an event = a node with content about an actual (=unique) occurence.
eg "My Birthday Party."
b) a timeslot = a specific date, an instance of a date-range, a single continuous 'duration' defined by one start time and one end time, something in which an 'event' occurs.
eg "8am-5pm Tues 23/04/2007."
c) a schedule = a list of timeslots, a timetable, programme, etc; if a Calendar is a list of all possible times and dates, a Schedule is a filtered selection of those times.
eg "8am-5pm Tue 23/04/2007, 8am-5pm Wed 24/04/2007, 8am-5pm Thu 25/04/2007."
d) a pattern = an aggregate of filters used to specify the selection of timeslots that should appear on a schedule.
eg "every Tuesday ; between 9am and 6pm ; excluding bank holidays ; when the moon is full ; in 2006 and 2008 ;...". (check out www.timeanddate.com)
e) If exceptions are part of the pattern, they are not exceptions.
f) UI doesn't mean page layout and colour-scheme, it means the interactive ergonomics, workflow, permissions, plug-ins, customisation, etc ;)

The main issues/questions seem to be:
1. how to implement a UI for configuring the schedule filters?
2. how to store the generated list of timeslots ?
3. how to display the generated list of timeslots ?
4. how to edit an established list (ranging from using a new pattern to 'refactor' it entirely..., to merely adjusting or nullifying one or two timeslots within it) ?
5. how to link event node content to one or more listed timeslots ?

Is that a fair summary?

I suppose, your schedule compares to my "eventrepeatlist".
Your timeslot would be a property of the "object" event (and "class" eventrepeat).
Event IMO is not a node by default, but can be (use an eventnode module/API).
Other modules hook into the "class" eventrepeat to get information about the expected upcomming events that have not been actually created yet. For example "room for hire" with time slots for next years agenda. The third party module Calendar should expect that information from eventrepeat class is not always valid (unless the pattern is marked "always valid"). Real and valid information should be derived from the event objects that have actually been created. This is just a list/schedule.

No need for exceptions if all objects have a unique class-id and you don't want to interfere with the pattern/class. No need to restrict timeslots, just leave restrictions (and filters Q1) up to third party modules like Calendar. Timeslot would be a property of event so that should answer Q5. If you store event-objects in a table (Q2) than it shouldn't be too hard to create a list (Q4). Use a pattern/Class for events that have not actually been created and use a table with object (not nodes by default) for the events that belong to a pattern/Class and that have actually been created (and combine the objects within the repetition period with the expected events using the pattern outside the repetition period; with the ability for third party modules to distinguish between the two) .

Just a reminder since this thread is getting a bit unwieldy, this is a discussion about using CCK Dates as repeating events and has nothing to do with how the Event module will handle repeats. I assume that event repeat will continue to create them as nodes as always, but either way, that's not the subject of this thread.

So here's my thinking right now:

1) For simple repeats, like birthdays and reminders, that have no exceptions and no new info generated each time, I'm thinking we use the feed approach instead of creating them in the database. This should be very lightweight since nothing is actually stored in the database.

2) For anything where there are exceptions, we will create actual items in the database as multiple value fields in a CCK date module because trying to deal with exceptions on the fly is going to create more overhead than just storing the date in the database would.

3) To handle the concept of needing to handle events that are part of a series but where aspects may change, like the teacher or the topic, I'm thinking right now that we need to find a way to allow you to indicate what fields in the node will stay the same in all cases and which should be made editable on repeats so we don't have to duplicate all info in all repeats. This is will probably need to be handled as another module that extends the date module. I don't want to add that much new complexity as a part of the date module itself.

@JohnG
That looks like a pretty good vocab, the only thing I'd suggest is using "instance" instead of "timeslot."

@This discussion in general.
As for the focus of this conversation, in a perfect world, I'd want to move towards creating a contrib API that both event.module and calendar.module can use to handle repeating events. This is pretty much in line with JohnG's summary in #52 above. I understand, however, that there may be significant differences between the two modules that may make this cumbersome.

Independent of what happens with calendar.module in regards to repeating events, (and assuming that we are not phasing out event.module), repeating events as nodes must go away for event.module. There are too many performance issues and too many bugs that will just go away once the "instances as nodes" method goes away. At the very least, the "table of instances" approach that Scott came up with for eventproject will be used.

While we are re-writing this, it seems to make a lot of sense to examine the possibility of joining forces. It would be great to find the areas where both modules can benefit from a single code base, possibly adding hooks to both modules to handle whatever this central module returns to plot instances.

I think that the date.module and the calendar.module are going to overtake event.module at some point, if only because of the way CCK is slowly moving/has moved towards core. As such, I'd like to focus the direction of repeating events to support that. However, I also see that a lot of people still use event.module. I feel that I have to support them in some manner (even if that is just an upgrade path and promise of same level of functionality in calendar.module).

@KarenS
Thanks for pointing out that this conversation is getting unwieldy. Somewhere up above, I think I remember you suggesting that eventrepeat move towards a more API-oriented approach. Can you speak briefly on how you see the relationship between the modules now that we've come a bit further down the road? Is this still a possibility?

@Everyone
Thanks for keeping up on this. There's a lot of complexity here and I appreciate everyone pitching in to try and figure this out.

What I visualize is that event repeat get broken down into a couple APIs -- one that takes an ical string and some parameters and returns an array of dates that fit those parameters, and one that will create an input form that allows you to select repeat parameters. This should be a separate API module that has no dependency on either the Event or the Date modules.

Then, I would refactor the Event Repeat module so that is updates the Event module, using the API to create its forms and calculate the repeat values. I would have the separate modules (Date and whatever module is creating repeats for the Event module) handle their own storage of the results, exceptions, etc. I see no reason for the API to worry about that, since storage decisions will depend on how the separate modules are using the results.

So we would end up with a Repeat API module that has all the API stuff used by both modules, and the Event Repeat module becomes the part that handles the storage of repeat events for the Event module.

That's pretty much in line with my aims for the module. Thanks for the response and clarification.

I think the next big goal for this will be to create a massive patch that carves away everything from eventrepeat, leaving only the form_alter, nopeapi and repeat string handling functions (plus anything else we think is needed). This will then become the next branch for 5x.

Thoughts?

I'd only just like to add that since it seems like CiviEvent is off and running now (and recurring events functionality is supposed to be added by June), I wonder if that project will in a matter of time surpass the functionalilty of this one and if we should take this into account. since i haven't tried it out yet, I don't know how well its data integrates with drupal and with views, or whether it's overkill and/or adds its only limitations or headaches. maybe it's just as well to continue with cck date, views and event repeat development for awhile regardless...

Since nobody has added any other additional thoughts here for a couple of weeks, I would bet everyone is finally more or less on the same page now and it's time to get started :)

Civicrm is a rather large offering that many people with simpler contact management needs would not want to install. So there is definitely a need for a full-fledged, standalone calendar with all the flexibility of Drupal (in my opinion).

@ #60 bomarmonk - +1 I strongly agree. CivicCRM is a different animal, and not a solution to mainstream Drupal development.

I've been slammed the lasts few weeks, and haven't had a chance to get started on this. Hopefully, this is something that I can take a crack at in the next week or two. At the very least, I will try to branch the code so that we can start creating patches.

sub

subscribing

Here is the current plan up for review:

1. Release an official 5.x-1.0 - (as is with the current bugs)
2. Branch to 5.x-2.x
3. Create a large patch that comments out anything related to saving nodes and start building the API up from there. As discussed above, this will be a form alter and nodeapi module that presents event repeat in a node form, processes its data, and returns an array for either the module to use directly, or for a helper module to translate as needed.
4. Work out the details for getting this to work with event and date modules.
5. Start fixing bugs from there until it is stable.
6. Create a 5.x-2.0 release

Something I sure wish everyone would remember is that CCK does not exist on ALL sites. I do not have it on any of my 16 sites and would hate to be forced to install it just to keep using Event.

@hunmonk, scott.mclewin To node or not to node? The question really is how to store things. I would argue that, Drupal definitions aside, once you store a row of data - in ANY form - you have created a "node." So the question really is do you follow Drupal guidelines or not. Frankly, I don't care. What I do care about is that you try not to force me to install any more modules than I have to. You cannot count on the prescence of anything beyond core, or something upon which your existence is based - in this case, the Event module.

Something I sure wish everyone would remember is that CCK does not exist on ALL sites. I do not have it on any of my 16 sites and would hate to be forced to install it just to keep using Event.

Not sure what this has to do with event repeat, but nothing I've seen in the work on the Event module would require you to install CCK. You can already create new content types in core. You only need CCK if you want to add extra fields.

Michelle

Here's the catch, Michelle. The Date module and the Calendar module have been designed with the views module in mind (and a great deal of built-in flexibility). These modules work with CCK to do the same thing as the event module, but do it in a way that offers even more presentation options (see the timeline module if you want to see how varied those views can become). Anyway, the event module (and event repeat) are still the way to go if you want a single calendar with recurring events. But I am looking forward to repeating events becoming a sort of API that both Calendar and Date can use!

Er...of course you probably already know that... my understanding is that event repeat and event will continue to work independently from CCK (so no worries there).

Heh, yeah, I did already know that, but it was a nice clarification for those who don't, so thanks. :)

Michelle

@michelle, bomarmonk: The title of this request is "...Use CCK date field". The description of this request says: ...use the date CCK field as well as (or rather than) the event module content type...

Further, #1 says ...idea of using CCK's multiple field option to put all repeating events into a single node....

And then #11 asks: What do people think about... Update a 'multiple' CCK date field...

So it sounds like this request is a move to make Event Repeat DEPENDENT on CCK. Am I reading this thread wrong?

------------------------------------------------------------------------
@KarenS #34: The difference is that WebCalendar is intended as a stand-alone application, not a Drupal module; therefore its has all the environment and rendering code, etc. that it wouldn't need if it was written as a Drupal add-on application. Also notice that a good part of that 3MB is documentation which is far more complete than Event and Event Repeat's documentation.

Nancy: You said, "Something I sure wish everyone would remember is that CCK does not exist on ALL sites. I do not have it on any of my 16 sites and would hate to be forced to install it just to keep using Event." That's what I was responding to. Event is not the same as Eventrepeat. Regardless of what Eventrepeat does, you will not need to install CCK to use Event.

At any rate, if you look at the response immediately before yours it says: "4. Work out the details for getting this to work with event and date modules." which sounds to me like it's intended that Eventrepeat will continue to support the event module as well as adding support for the cck date field.

Michelle

Sorry for not being around to answer this. I had unplugged for the long weekend. The intent here is to create an API module that can work with event module or date/calendar/cck/views.

As an additional update, killes has recently informed me that his work on getting event module and eventrepeat to use date fields instead of unix timestamps is almost complete (see http://drupal.org/node/132256). This means we will be creating a 5.x-2.x first, then creating the API in a 5.x-3.x version.

Thanks for the confirmation. I haven't investigated Event Repeat yet as I've been pretty busy trying to help fix Event & Event all day. I plan on using Event Repeat eventually so it's good to know that it will continue to be compatible with Event.

Michelle

I guess I need to find out what the difference is between a date field and a Unix time stamp. Then I'll probably have to update that code snippet I posted for Event.

Nancy: The timestamp is a unix timestamp which is the number of seconds that have passed since around 1970. If you look at your event table, the start time will be something like 4732947349832893 (just random typing there... not an actual timestamp ;). This causes issues in events with events moving to the wrong month stuff like that. So killes re-wrote the event module (5.x-2.x) to use actual dates. So if you look in the table using the new module you'll see something like 2007-06-01 10:00:00 which is a heck of a lot easier to read.

It sounds from Sean's comment that event repeat uses the normal looking date and that he was waiting for killes to get event converted. BTW, Sean, if you're reading this, it's nearly ready. Of course it's up to killes when to say it's good enough for release, but I've been working at testing and debugging and I think it's pretty close. The main problem with it at this point is broken views which, ironically, seems to be because _views_ wants a timestamp. LOL

Michelle

Easier to read, harder to do arithmetic. But I'll live. I don't understand the time stamp problem you mention - that's exactly why so many systems have gone to timestamp type dates. Oh well, my applications aren't rocket science.

Just to clarify, eventrepeat currently uses unix timestamps and 5.x-2.x for eventrepeat will be a switch to the date field (I might have been a big vague about that). To confirm this, I am changing the name of this thread (again).

Michelle, just for our education, can you give us a quick reference or explanation on why it is OK for us to switch to date fields now? Is this because Drupal has dropped mysql3, which is why we were using unix timestamps in the first place?

Michelle, just for our education, can you give us a quick reference or explanation on why it is OK for us to switch to date fields now? Is this because Drupal has dropped mysql3, which is why we were using unix timestamps in the first place?

Killes could answer that better than me. I know the reason for the switch was that there was issues with dates jumping around with the timestamp and it's much easier to troubleshoot when the dates are stored as readable dates. I don't know if there's some reason beyond that which makes it "ok" or if that was the only reason. I'm jumping into event as of a couple weeks ago with 5.x-2.x after not having used it since 4.7 so I haven't been through all the timestamp issues.

Michelle

The reason has not much to do with mysql 3. I've always wanted to do this since it would be much easier to debug and now I've found a sponsor who allows me to do this. :)

In fact, event-5.2 will still almost work with mysql 3. Only the "upcoming events" block will require mysql 4.1.1.

First, let me say that I will live with this change.

Second, let me remind people that "Those who don't know history are doomed to repeat it." I've been doing computers since they were made with transistors. Who out there knows what a core plane is? So I've seen first-hand a lot of computer date problems, not the least of which was the dreaded Y2K issue that made me a lot of money.

Because of all these problems, most systems went to a timestamp of some sort. In doing so, not only did they solve their problems but discovered that sorting, arithimetic, and comparison problems got very simple. Quick, how many days have elapsed between 02-08-2007 18:00 and 04-03-2007 09:00? Now, I bet you can figure it out faster between 1170476429 and 1179262419. Sure it's "nice" to be able to read the dates in the database, but they're really there for the computer to process, which it does far more often than you have to look at the database. I prefer my site to be fast to run, rather than fast to debug.
I certainly understand the niceities of having a human-readable format, and it looks like the chosen format at least lends itself to string comparisons (that will still be slower than numeric comparisons). But it would also be nice if a "standard" format was chosen, such as ISO or RFC. I still haven't found the APIs, although I'm sure there some, for converting these values so that I can do my arithmetic on them.

I've been very tardy in posting something I promised a month ago - I'll chalk it up to having a newborn on my hands.

Sean has given me the ok to put my rewritten version of eventrepeat on this thread - I'd held it back in the past as I did not want to create a competing module. For the sake of this discussion I thought I'd include it. What is not included here is a patch to event.module to blend the repeating events created by 'eventproject' into the calendars.

The eventproject (as in it projects the dates for a node into the future) module is what we use on http://www.folkjam.org to handle all of our repeating events. Visit the site to see this module in action.

I reworked eventrepeat about a year ago for the list of reasons described in the top of eventproject.module. The biggest single change is that it does not create nodes - rather it creates a table of future date/times and associates that with a single node. There are upsides and downsides to this, which are also described in eventproject.module in the attached .zip flie. For folkjam.org the upsides far outweighed the downsides.

While we have this module in production use, I'm not recommending that you use it for a production site - first and foremost I'm not prepared to support this module. I am posting it here because I think a working reference implementation of no-nodes-for-repeats is important to the discussion.

Anybody who wants the event.module patches (for 4.7) can ask for them through my contact form - but don't ask if you want this for your production site. It is for reference in working with a functional eventproject.

Scott

subscribing

@ray007 - if you click on the "Issues" link in the upper right corner of the page, you'll get a "Subscribe" link.

I just wanted to alert readers of this thread to my comments on the matter here: http://drupal.org/node/117431

I'm just now starting to read this thread, but I don't think my idea has been covered here. Basically, the idea is to use node revisions for each repetition so that more than just the date can be changed each time. Additionally, there is a module that lets you put a new revision in a queue so that users don't see it until it is released. This way, the current revision (current event) will be seen while the next revision (next event) is modified/revised/approved by the creator. My wife currently uses e-vite.com for a children's play group where the time is usually the same but the location changes each time. Using revisions where cck_address, cck_phone, or whatever can be used allows the changing of details like this.

If you like this method, let KarenS know.

I'll now finish reading this thread and make any comments below. Thanks for reading.

Having just finished reading this whole thread, (wow, it's huge!) I think I can say that using node revisions, as outlined in the thread link I mention above, is in-line with the salient points as discussed in comments numbered 4, 5, 6, 11, 12, 13, 14, 15, 21, 24, 26, 29, 35, 36, 39, 40, 45, 46, 47, 49, 50 and 54. [It looks like most comments after that are clarifications of ideas already mentioned.]

Regarding #40 and infinite repeats, I think it would be a simple UI thing to ask the creator how far in the future/how many events to show at present/at any given time.

I also strongly agree with KarenS's comment #54 that things could/should be broken up this way and that using revisions could be a part of the solution.

Oh, let me clarify that I agree that an API should be made to do the calculations which is separate from any implementation and that 'using node revisions' falls into the implementation category.

In reading this thread, I'm still not 100% sure that the workings of such an API have been specified. What I mean is, what are the inputs to the API, what does it calculate, and what are the outputs? Does the API deal with such things as weekend/holiday avoidance? Does it do all of the funky calcs for rules such as "the 1st Tuesday after the 2nd Monday in November"?

Maybe this was addressed above and I read over it too fast.

I also think that having done the calcs, that the API should spit the results out in the flavor (format) of the user's choosing.

Am I too late to this party for anything I say to matter?

@sean, I started working on this to see how a separate api might look and how it could integrate with both the Event and Date modules, and the first problem I ran into was the use of the map table as a method to calculate things like 'the last Tuesday in the month'. The current method requires the creation and maintenance of that table using cron, and that any date you want to calculate must be present in the table in order to do a calc. Then cron wipes all values prior to the current date out of the table.

Lots of problems there for what I want to be able to do -- I need to be able to use this on a broad range of both current and past dates, so just making sure all potential dates are in the table is problem number 1. And what do you do if someone tries to 'change all instances' of an event that started in the past? It looks like there are problems there.

Anyway, I have a potential solution and I think it could work quite well. I am re-working the PEAR Date Calc module as an include file to be added to the Date API. That will allow you access to functions like date_calc_next_day_of_week(), date_calc_begin_of_prev_month(), etc etc with no need for the mapping table. This will give us the ability to calculate any past or future date.

I have already decided I am adding this to the Date API since I can use it to simplify lots of code in both the Date and Calendar modules. As I get this more fleshed out, I thought I'd create a Repeat API module to do the calculations such that it would work with both Date and Event, and then post a patch to Event Repeat to adapt it to use this new functionality so you can see how it would look and figure out if you like the approach. It would really whittle a LOT of code out of Event Repeat which would make it much easier to maintain.

You might be interested in the date calculation algorithms referenced here: http://www.smart.net/~mmontes/ushols.html

That sounds great karen.

My only question is how this affects some shared-hosting users, etc. I'm not sure if I can say how widely supported PEAR is for some hosts. I think it's pretty good, but if we're going to be requiring PEAR, maybe it's something to discuss. Then again, eventrepeat is such a beast that it may exclude some users as it is currently written. Perhaps someone who's been keeping up with support for various users could comment here.

Also, I think we are nearing the time when this thread needs to be closed. Once we get this last point decided, I'll close this and start a clean one where we can actually track patches, etc.

@sean, I'm not going to require PEAR, I"m going to re-write the PEAR Date Calc code to make it a Drupal file with no PEAR dependencies. PEAR Date Calc is licensed under the BSD license which I believe means I can create a derivative Drupal file. PEAR Date Calc is very stable code that won't need much if any work once it's been 'Drupalized'.

@nancyw, it looks like those are holiday algorithms. I hadn't gone that far, but adding some of that kind of functionality could maybe be in an optional module so people who don't want all that overhead can leave it out. PEAR also has some holiday algorithms that could maybe be factored into another derivative file. Keeping up with holiday algorithms might be more work that Date Calc, so I'm not sure I'm volunteering to do that, but maybe someone else would be interested.

They are used for holidays, but the gist of them is appropriate for Event Repeat. They calculate 2nd Wednesday, or last Thursday of the month, etc. They could also be appropriate to put in Date API, at least IMO.

PEAR Date Calc has enough functionality to do things like the 2nd Wednesday, or last Thursday of the month, so that's covered. It just doesn't do holidays out of the box (but there is another PEAR module that does). The reason I am pushing for PEAR's date functions is because it's the standard for handling dates in php. It's extremely stable code that's been tested and debugged and has been used by millions of people for years. I don't have any idea how well tested the algorithms your linked page are. They may be fine, we just don't know, but I do know that PEAR's date functions work.

That's great then. Holidays are my job. Events that repeat on the 3rd Saturday are Event_Repeat's job.

@Karen, thanks for the clarification, that sounds like a great way to proceed.

I'm going to go ahead and close this issue as the main questions that started it have been answered (at least initially). I'll post a link to this on the project page as a reference point.

Unless this method totally falls apart, let's let this monster of a thread rest. Please post any additional questions concerning this as a new issue. :)