So, I just came upon another painful event bugaboo (as pasted in from Richard, when he was troubleshooting):
The navigation on the monthly view only goes up until the last months with events scheduled. sort of, there's some wriggles around what day of the month the event is posted for.
(you can, of course, hack the URL to show empty months in the future, there just isn't any navigation; sorry, there is navigation, but you can only go into the past, not the future)
And then of course there is the famous default "only show the next 30 days" feature, which is confusingly in the "table" section. You can set this to 365 to show a full year, but that is a hardcoded limit: you can't show more than a year.
So....any thought to revamping event as CCK date fields, making a new view_calendar module for calendar-like displays, and making ical kind of like view_feeds?
I think, technically, this new event module would define "start" and "end" labelled fields, which could then be used independently for regular CCK creation, or for event-enabling existing node types as event does now.
This may be a bit of a rant, and I haven't been signed up here until now, but needed to get these concepts out of my brain...
Comments
My head is spinning...
I think that many people would like to see improvements to Event - that's how all this got started :). Personally it seems to me that the display of events may be better taken care of in other modules (views??). As for implementing this with the CCK that is certainly an option. I have played around a little with using CCK for this and have some basic questions regarding the data model and also ease of customization on top of CCK - but this may be because I'm not totally up to speed on CCK yet. Regardless what this all points out to me is that we really need to nail the requirements before we talk about implementation - otherwise we'll be in a never ending loop.... and that makes my brain hurt...
I'm with Boris
The GJG flowcharts and drob's class model all say one thing to me; that the idea of an event is already falling prey to how you intend to use them. Let's back up a bit and review some of the basic truths:
So the reason I support Boris' assertion that our basic event type be anything with a CCK date field attached is that it leaves "what you want to do with it" and "how you want to view it" to other means. I think the very first step in this whole thing is to get some decent widgets for the CCK date field. And if you have questions about the CCK date field, don't forget that you can define your own CCK fields in other modules, including how you want the data to be represented. Likewise, modules can provide their own widgets for existing fields. Getting this step done right would be a big win.
Step two is to create a views_calendar module. It can be patterned on the views_feed module which takes a view and renders it as RSS. Same principle... take a view and render it as a calendar.
Once these two things have been done, you can create a slew of event-workflow modules that coordinate various signups, notifications, civic-this-that-and-the-other etc. But make the basic framework principle of what an event is the smallest and most focused unit of functionality you possibly can and don't pollute it with "how you want to use it".
This is how people want event and CCK to function
Read shrill's post on Drupal.org and look at her example page; the two biggest things that I take away are:
Yuppers
I am just getting back to this after a busy two weeks. I agree with the basic premise that I would boil down to "Conceptually, events are pretty abstract". As a matter of fact since I started working on this I've felt that "events" are poorly named. For an end-user the word "event" means something very different than what it means right now in "events" and certainly what it would mean if we go down the path that Robert is indicating. At that point it is more "time" or "period" perhaps.
=) On the same page
Cool stuff, views_scheduler and views_calendar, eh? Now we've just gotta get'm written.
Glimpse the future
To see where CCK+Views can take us, read this post about the views_scheduler module being written as part of SoC.
In particular, this comment
about loosely coupled schedules
Event Views has a calendar display
The Event Views module (http://drupal.org/node/67060) now has a calendar display. With some additional work, I think I can get it to push cck dates into a calendar (I have that on my features request list). I completely agree that the display should be relegated to views, input probably ultimately to cck, and then focus on processing in the event module.
Mixing cck dates (which are in iso format) along with unix timestamps gets us into the timestamps discussion (http://groups.drupal.org/node/731).