Custom Views 2.2.5

It is possible to customize the existing Available Views in addition to programming your own from scratch.

Customizing an Existing View

If you'd like to take one of the existing view types, like "basic" or "agenda", but display it with a custom duration, like 4-days instead of the stock 1-week or 1-day, do something like the following:

$('#calendar').fullCalendar({
    header: {
        center: 'month,agendaFourDay' // buttons for switching between views
    },
    views: {
        agendaFourDay: {
            type: 'agenda',
            duration: { days: 4 },
            buttonText: '4 day'
        }
    }
});

We use the views option similar to how View-Specific Options work but with the very important addition of the type property. Also, a date-range parameter is required, whether is be duration, visibleRange, or dayCount.

We have chosen "agendaFourDay" to be the name of our new custom view. It is advised to choose view names with the numbers spelled out like "four" instead of "4" because JavaScript disallows identifiers beginning with numbers, like "4day".

Also, in the above example, buttonText has been used to customize the header button's text. Notice how it has been specified as a single string, as opposed to an object hash, the way it is done in the global options.

If your calendar hosts only one custom view, a Generic View is a simpler way to define it.

Coding a View From Scratch

For advanced developers, FullCalendar provides an API for building custom views with the unlimited flexibility of JavaScript code. Using OOP programming principals, one can subclass the base View class, implementing or overriding each specific behavior as a method, and then registering the new class with FullCalendar, like so:

var FC = $.fullCalendar; // a reference to FullCalendar's root namespace
var View = FC.View;      // the class that all views must inherit from
var CustomView;          // our subclass

CustomView = View.extend({ // make a subclass of View

    initialize: function() {
        // called once when the view is instantiated, when the user switches to the view.
        // initialize member variables or do other setup tasks.
    },

    render: function() {
        // responsible for displaying the skeleton of the view within the already-defined
        // this.el, a jQuery element.
    },

    setHeight: function(height, isAuto) {
        // responsible for adjusting the pixel-height of the view. if isAuto is true, the
        // view may be its natural height, and `height` becomes merely a suggestion.
    },

    renderEvents: function(events) {
        // reponsible for rendering the given Event Objects
    },

    destroyEvents: function() {
        // responsible for undoing everything in renderEvents
    },

    renderSelection: function(range) {
        // accepts a {start,end} object made of Moments, and must render the selection
    },

    destroySelection: function() {
        // responsible for undoing everything in renderSelection
    }

});

FC.views.custom = CustomView; // register our class with the view system

The View class provides many other methods that can be overridden or leveraged. See the View class' source for more insight. It might be wise to watch the project on Github in case the API for any of the more advanced non-standard methods changes.

When overriding an advanced method, it is always a good idea to call its super-method, the method that the View super-class defines:

CustomView = View.extend({

    // clears the view's rendering and executes other cleanup tasks
    destroy: function() {

        // <your custom cleanup-code here>

        // call the super-class's method, forwarding all arguments
        View.prototype.destroy.apply(this, arguments);
    }

});

The above documentation is helpful for building a barebones view, but making it full-featured and interactive is a further challenging. A robust view should be right-to-left compatible, locale-customizable, allow event dragging and resizing, allow user selections, and more...

Making a full-featured view is beyond the scope of this document. Further documentation should be written and further APIs should be formalized, but for now, it would be best to browse FullCalendar's source on Github. Pay special attention to how BasicView and AgendaView are implemented and how they leverage the Grid system.