We need a calendar view of the views nodes. I will be posting something preliminary here shortly.

Comments

karens’s picture

This has been added to the latest cvs. I added in a views plugin that runs the nodes through the event_get_calendar api in the event.module. You can see the event views options in the views page type selector -- month, week, day, and table.

It looks like that api is not returning exactly what we need, although it is close. We either need some patches to the api or a different api (depending on whether patching the current api will break other modules). Some of the problems I see are:

* The calendar title is coming back in a td rather than a th element, which breaks css and themes that expect it to be a th.

* The calendar title is displaying the short form of the month with no year, instead of the long form of the month with a year.

* If you try the week option, it returns the whole month instead of just one week, and it returns the month title instead of the week title.

I'd like feedback from anyone who is familiar with the event api. Are there other modules using it that will break if we try to patch it to fix the above problems? Does anyone want to try to propose patches to that api that will clean things up for our purposes?

merlinofchaos’s picture

The main difference my idea for the calendar plugin had was that I would use magic fields. The fields would format data so that the node appeared to have an event_start and an optional event_end.

The query_handler would add the field using an AS statement such as: node.created AS event_start

And the field info would be 'visible' => false

It would also have a special field, probably something like 'event_start' => true, so that the validator could ensure that the query had the right field.

I was also working on a way to ensure that it knew what date range it was supposed to be using, but the calendar view may actually be able to determine that automagically based upon what results it got. If that works that way, then normal arguments are so very much the way to go.

karens’s picture

That's an interesting idea. I assume you would still create the calendar view by running the results through the event api? Or maybe you had something else in mind for generating the calendar. Are you thinking I should pull this out of the event_views module so you can do this elsewhere? I don't want to interfere with whatever your plans were :-)

merlinofchaos’s picture

You are right; I was still thinking to run the results through the event api. Which is why I was letting something else pretend to be event_start so that the calendar would just use that data.

karens’s picture

Well then we still need to get the event api patched to fix some of the problems noted above. This will only work if both views and event are enabled, so it might make sense to keep the calendar plugin in this module rather than somewhere else, but I'm happy to do this any way you like.

eaton’s picture

Hmmm. I haven't had a chance to look at the code yet, but wouldn't the calendar view be useful for other types of content, on sites where event.module isn't installed? Blog posts, for example. Is the construction of the calendar itself dependent on event.module? Or is the logic just geared towards the subtleties of content with both a start AND an end date?

merlinofchaos’s picture

Oh no, I agree; if I implied I meant to have it elsewhere, that was a miscommunication on my part. It is currently right where I believe it should be. I was simply pointing out the features I'd thought out for it!

You've done great work, KarenS, and I'm more than happy to sit back and offer advice and insight and allow all to enjoy the fruits of your labors! =)

karens’s picture

Eaton, you're right, there are lots of places it could be useful. The problem is that we need something to generate the calendar template and at the moment the event api is the best way to do that. Using merlin's ideas, we could make any date field a pseudo event, so it could be used for nodes other than event nodes, but we would still need the event api to generate the calendar.

The only way to avoid the need to have event installed is by creating the code to generate a calendar somewhere else, but you would still have to install whatever module was creating the calendar.

karens’s picture

I've just uploaded a major update to add to the calendar theme capabilities. It requires a patch to the event module api that I submitted at http://drupal.org/node/68630 to work. If that patch is not committed, I will back these changes out in my next update. Added by the update and the patch to the events module are calendar page types that are getting very close to emulating the look and feel of the current event module, including prev and next navigation links. An updated default calendar view is included that takes advantage of the new features. Be sure to clear your cache. For best results, you probably should delete any existing event views views and re-create them.

karens’s picture

I'm seeing some problems in the prev next links where they're off by 1 in some cases. It works perfectly on my local version, but I see errors on the demo site, so it's a timezone conversion issue, probably. I'll have to do some research...

karens’s picture

Got the next/prev links problem worked out and updated the cvs. It was an overdose of gmmktime :-)

karens’s picture

Status: Active » Fixed

This has generally been accomplished, although there will be ways to improve it. I'll close this issue and we can open issues for other specific features that are desired/needed.

Anonymous’s picture

Status: Fixed » Closed (fixed)