Add Option To Load Events Via Ajax

subscribe .
Think this will be very important in future

Subscribe.

The new plan is to make the fallback optional, and load everything via AJAX, not querying the fallback. Should lead right into #921572: Pass date argument from view to display specific month, they might have to merge.

Trying to get a 6.x-1.0 release, new features can wait.

Here is a patch that provides an AJAX view provider from views fields mapped to JSON output. The fullcalendar style display can then choose the endpoint URL to connect fullcalendar JS to. This allows for the calendar to use default views args to limit date results (in this case by month) and also be able to traverse all available dates through the views provider.

I hope this helps.

No new features are being added to the 1.x branch.

subscribe

Update to patch: include hook_install for creating date_formatter for fullcalendar

What is even going on in that patch?
What is the date format for?
What is theme_seed_crayon()?

Hmm this adds an extra dependency.... to the fullcalender module:

+dependencies[] = views_ajax_endpoint

One solution to the dependency addition might be to submodule the additional AJAX endpoint views handler. That way the core fullcalendar module can be free of extra dependencies.

"What is even going on in that patch?" - Not sure what this means... A quick explanation: this patch provides an additional views display which is an AJAX JSON Endpoint which you can select which fields in the view map to what JSON is provided to the fullcalendar. The fullcalendar page style can then select to use the JSON endpoint as the provider so that the callbacks made by the jquery plugin fullcalendar will call the view. This allows for naviagation to months with live data update without loading the whole date info on the initial page load. (additionally, the view provider uses the date argument to specify the month it is currently looking at... I hard coded the date argument as YYYY-MM. This could probably use the native unix timestamp provided by the default plugin.)

"What is the date format for?" - This is for the view JSON Endpoint to provide the proper date format to the fullcalendar jquery plugin. It seems to consistently respond to ISO8601 formatting; which is why I was adding that to the date_formats install. (this probably needs to be cleaned up on uninstall).

"What is theme_seed_crayon()?" - Yes, this needs cleanup; I patched this from a site where we use the litecal (from Development Seed) CSS coloring on events. This makes a nice coloring based on the type passed from the view. (quick example: http://passingcuriosity.com/2010/going-further-with-litecal/)

I realize this does need work and is a couple of steps further than just installing the module; however, the end result is the fullcalendar jquery plugin using a separate views display as a JSON provider so that a single page load can callback asynchronously and navigate any date range.

Screesnhots would help to visualise what you're trying to do. I don't rly get the concept yet. But I'm interested in more.

We're not going to declare a dependency on a module that hasn't been touched in a year, never had a D6 release, and is only used on 15 sites.

Crayon is out of scope, see #1041068: Colorpicker similar to Calendar module.

This is an important feature (another issue filed today, #1051720: Events revert to prior positions while switching between months).

Here is a re-roll against 6.x-2.x-dev.

christianchristensen and I plan to continue working on this. We'll simplify the patch and we're investigating services_views in the Services module to provide an endpoint.

Any thoughts on using Services (services_views) for this? I know we're a little averse to reinventing the wheel on that front, so we're looking to use a module we already use.

I know you guys work on a 6.x branch but be aware of the fact that it NEEDS to be possible to port to D7. So if you find a module that is usefull be sure it has a d7 port or have at least a D7 port patch. The first module you were working with only had a 6.x branch 14 site installs and it isn't rly maintained.

We will definitely keep that in mind. We put patches out early as a policy, with the intent of getting quick feedback like this.

Services has 10k+ installs and is actively developed. While stable has it, the dev versions of it are missing Views integration, but it's being worked on.

A coworker of mine supposedly has a miracle solution for this that doesn't involve adding two dependencies. Will post back with more information.

Yes, this could be written without dependencies, but why reinvent the wheel?

Yes, this could be written without dependencies, but we were actively avoiding that.

We've implemented FullCalendar internally on completely custom code with JS callbacks, resizing, modals, etc. Our goal here was to move away from that, and reuse other modules. Services is an obvious one because it provides access to views as well as nodes and it's pretty popular.

Here is an example of the current patch on our site: http://www.allplayers.com/g/gpymcasports/calendar

If you rewrite your comment, mine makes no sense and makes me sound mean!

If it's focused, well-written code, we can easily backport it to 6.x-2.x. Currently there is no module that would suit our purposes that is available for both D6 and D7.

I'm not nearly as averse to using Services as I am Views AJAX Endpoint.
But Views support for D7 Services is split off into another module, which doesn't exist yet.

And everything is going into 7.x-2.x first, and then being backported. There is a healthy backlog of backporting to do, but we should get to that soon...

Sorry for the grumpy AM comment, I've rephrased it.

We aren't using 7.x yet, would love to, but don't have the bandwidth. Are you not accepting patches for 6.x?

subscribing

subscribing

subscribing

This is the first step. Filtering by date. Next is getting the pager to control it. Either forcing the FullCalendar pager to trigger the switch, or create our own pager and hide the FC one.

This works better with #921572: Pass date argument from view to display specific month.

Initial attempt. Still needs integration with the default next/previous buttons.

Change the pager to fullcalendar, and make sure Use Ajax is set to Yes. Also requires the patch at #1147234-1: Allow alphanumeric dom_id.

Patch must not've uploaded correctly. I'm getting 0 bytes...

Fair enough. Take two...

Patch applied cleanly... but I can't figure out how to get AJAXishness to start working. I set the view to 'Use AJAX: Yes', but it seemed like all the events were still loaded initially in the HTML. Is there a setting somewhere for turning on the AJAX functionality in the FullCalendar settings too?

Did you change the pager to the new fullcalendar? May take a cache clear to get that to show up.

Ah... now I see. The duplicated set of pagers (default graphic buttons at the top, and the links at the bottom) are confusing, so would it be possible to just use the default one, and hide the 'FullCalendar' pager? (I know you're still working on that aspect, but I just think it'd be best to have one set of back/forward buttons.

Great work so far!

I would put RTBC, but I don't think having the dual pagers is ideal; we need to either be able to disable the default forward/back buttons, or make them work like the pager links.

Okay.
Try this on for size!

Here is the full patch, as well as the lines I changed since last time.

Oh, this totally breaks week/day view. But I want to get this approach looked at before I keep going, to make sure I don't spend too much time down the wrong path.

Heh... I see what you mean. However, that's the functionality I think we should aim for. Now, a couple other nitpicks: The month displayed ("May 2011") doesn't change when I go back and forth... additionally, this does make the calendar months load a bit more slowly (even when running locally), so we should probably mention that in documentation relating to using AJAX.

But yeah, this is exactly how I'd hope the functionality could work. Simple drop-in change from non-ajax, "load-all-at-once" edition.

The month name changes for me. And yeah, the performance implications of each method need to be documented.
Now to make it not kill week/day view...

#1147234: Allow alphanumeric dom_id was committed, I will try to work on this more.

+1

Here's a patch with a complete different approach: use a menu callback to get the results from views and pushing that content back into the DOM. The ajax callback also calls drupal_page_footer() so for anonymous users even page caching will work and the retrieval of events is superfast. For authenticated users, I strongly suggest installing entitycache module (not even for fullcalendar, but as a default) which speeds up loading of entities since views always does that too nowadays, even when using fields. I've tested this with 4000 events and it's *MUCH* faster now.

Changes so far:

- Updated the javascript to be a bit faster too by creating full jQuery objects.
- Separate events parse function
- menu callback 'fullcalendar/ajax/results' and fullcalendar_results() function.
- updated default view using arguments
- dependency on date_views in info file

Code definitely needs cleanup but I'll let you guys play around with first to see if you actually like this approach or not. Probably needs some work also when switching from month/week/day, but that's for another hacking session :)

One thing I've also noticed is that fullcalendar_get_settings() can only handle one calendar. Granted, I don't think people will add multiple calendars on one page, but just wanted to mention it.

reroll against latest dev.

I don't think gcal will work...

Events only accepts a single array of events, you need to use eventsources to overcome that problem.
http://arshaw.com/fullcalendar/docs/google_calendar/ has more info about this.

Please not that we have to support "older" versions of the plugin (prior to 1.5). So we can't use the new approach described on the website.

New patch, makes google calendars work too.

Updated patch, should make other arguments make work do. Also, the ajax only fires as soon as someone adds a date argument, so that's win too. Not entirely sure about the cleanliness of the arguments replacement right now in the jQuery, but it works :)

Hmm something is wrong

1) I open the default calendar and I see the events, when I switch months I can't find any events.

2) When I use this on a view with arguments I get these kinda warnings:

Notice: Undefined offset: 0 in fullcalendar_check_arguments() (regel 307 van C:\xampp\htdocs\chirolimburg\sites\all\modules\fullcalendar\fullcalendar.module).

subscribing.

Fullcalendar running very slow for me. Is this the issue where folks are working on that?

If you have lots of events? YES
else NO

:)

It was my repeating date events. I'm hoping Views Content Cache will help with this as well, though it's not ready for D7 yet.

You can parameter you fullcalendar view in order to display only a certain number of events and to display them in descending order. If you do not have too many events in the "future from now", it may look like a full fullcalendar.

As a note: we have been iterating on (mainly due to fairly large calendar data sets) the fullcalendar implementation with AJAX callbacks as it provides a much more dynamic way to provide content to the the JavaScript fullcalendar frontend. There are a couple of patches above for the 6.x branch, but there is more over here: https://github.com/AllPlayers/Drupal-FullCalendar

How out of date is that github clone? All of the views files and includes are still in the parent directory? That's useless to me if I wanted to pull in changes. Also, a d.o sandbox would have been much better.

Still needs work per #42.

Wow, that is not a clone, that is a fork. In the most unusable way. Ouch.

:-(

I'm a very dissapointed to be honest... We know we lack ajax support and we know we maybe can fix it without some help.
Since february we are saying we are very interested in this and we never heard something back until today.

It's bad to hack core but it's also a very bad idea to fork modules. What if you want the color integration? Are you going to rip out all of these pieces out of fullcalendar and put it in your github? I can understand you need some features to get your project done. But it would be nice if you could share your solution and progress once in a while. We don't have to invent the wheel every day.

Look at swentel, he needed this to, and he gave back the results of his efforts. It's no completly done but it's getting there and he has a solution which doesn't require extra dependencies.

I'm not angry or so, just bit dissapointed.

To be clear, we did submit patches. They won't be accepted and we haven't had the resources to build a solution that we thought you would accept. Chris and I are not directly working on that project anymore, that's why the issue has gone quiet from our end. The Github "fork" has been up since February, it's simply what we are using, warts and all.

Ultimately, I hope we can bring things back together, but we have to provide our users a usable calendar today.

Just to be fair - we have been running off the patches discussed back in February and briefly and DrupalCon (please note the production demo link above) - the last I recall any actual implementation was Tim with "A coworker of mine supposedly has a miracle solution for this..." #17.

Please note we do not consider this a fork, we consider it a versioned place holder so we could continue to use the module, add plugins, and get work done. I am actually *very* surprised by the negative reaction, particularly noting that I was doing exactly as you described "...shar[ing my] solution and progress once in a while".

A couple of points of agreement: yes, this would be better as a d.o. sandbox (we'll work on making this happen), yes this is older (b/c the snapshot was from the time the original patches were submitted)

We have been using the fullcalendar jQuery plugin for sometime (with custom supporting code) and I would love to see us working at the cadence with contrib - unfortunately we *need* some of the features we are describing, so we implemented and patched.

I wish we could get over disappointment (or any anger too).

I don't think we are angry, at least I'm not. I was just a little dissapointed browsing through the fork. I had hoped that we could use some of the github stuff directly, that isn't the case. Srry if it sounded that negative.

I know you need to please your clients. I hope I can find some time next week to debug #41 so we can get this actually DONE, so you don't need your custom version anymore :).

Okay, getting back to the topic at hand:

After applying the patch and reverting the view, I get a 404. It seems that the argument that is added is to blame, as it is configured to provide a fixed value, but the fixed value is blank. Which would explain the 404.

Also, I'm not sure why the argument is changed_year_month. Is that just because the default view ships with the changed value as the date field?

Mostly, I'm not sure how the JS code for 'events' ever gets called twice. The initial load works fine, but switching the mode to week then back to month, or hitting next then previous, there are no events.

Sorry it took me so long to really look at this, swentel. Maybe we can talk about this on IRC this week.

Adding tag

Is there any workaround for the slow load of large calendars right now? I have one in particular that takes a minute or two. I tried Views Caching and it speeds it up but it displays the cached calendar in a list instead of the month view.

please see attached screenshot

Okay, so there is a Views bug preventing the contextual filter settings from being exportable. Here is a reroll of #41, and after you apply it and revert the view, go to Contextual Filters, then "Content: Updated year + month", then change the "Provide default value" type to "Current date".

I'm still not convinced that forcing everyone to add their date fields twice is best. I also haven't tested any combinations of fields, or even how it interferes with true arguments. We'll see how I do with trying to work around that.

I also pushed this up to a feature branch.
git clone --branch ajax-971034 http://git.drupal.org/project/fullcalendar.git

This works great. I had some troubles with custom arguments but with the right tricks my error messages disapeared.

I'll make a screencast in the near future.

Okay, now this is actually needs review.

You no longer have to manually add arguments for your date filters, as long as you set "Use Ajax" (under Advanced) to Yes, then it will Just Work™.

http://drupalcode.org/project/fullcalendar.git/commitdiff/361062f

I like things that Just Work™ - will try to test soon!

For future reference, the reason that swentel's patch never worked was #1273806: Non-plugin default argument types are not exported. Not his fault!

Needs a cache clear but after that ajax stuff works great. Even with multiple arguments.
One small problem with a google calendar:

Notice: Undefined offset: 2 in fullcalendar_check_arguments() (line 312 of C:\xampp\htdocs\fullcalendar\sites\all\modules\fullcalendar\fullcalendar.module).
Notice: Undefined offset: 2 in fullcalendar_check_arguments() (line 312 of C:\xampp\htdocs\fullcalendar\sites\all\modules\fullcalendar\fullcalendar.module).

So needs work for that.

Ow and the magic add argument stuff is some dirty code but it works :)

I decided to fix this myself...

So I made this :)

Committed. And hey, it's not THAT dirty! Earl was impressed it only took that many lines.

Here's a patch for those wary of git branches.

Cloned from Git and tested without any issues for me. The obvious changes that I see are the addition of the throbber gif and a pause while the data is loaded. Month/Week/Day views all test out.

No issues with my testing. It works for all views.

http://drupalcode.org/project/fullcalendar.git/commit/c76578e
http://drupalcode.org/project/fullcalendar.git/commit/79981bc

Yeah! Now to get #1272688: Add new argument default action that uses wildcard as default value fixed.

At some point, development of this patch was changed from 6.x to 7.x. What would be involved in backporting this to 6.x? Is it still in the works?