This view is for displaying metadata about calendars. Upcoming events, name, description and so on. This is probably not the best view for displaying a calendar in a traditional sense, i.e. displaying a month calendar or a year calendar, as it does not equip the context with any period objects. If you would like to do this you should use calendar_by_period.
This is the template that will be rendered.
This view is for getting a calendar, but also getting periods with that calendar. Which periods you get is designated with the list periods. You can designate which date you want the periods to be initialised to, by passing a date in request.GET. See the template tag query_string_for_date.
This is the template that will be rendered.
This is a list of period subclasses that designates which periods you would like to instantiate and put in the context.
This is a dictionary that returns the periods from the list you passed in. If you passed in Month and Day, then your dictionary would look like this
{
'month': <events.periods.Month object>
'day': <events.periods.Day object>
}
So in the template to access the Day period in the context you simply use periods.day.
This view is for showing an event. It is important to remember that an event is not an occurrence. Events define a set of recurring occurrences. If you would like to display an occurrence (a single instance of a recurring event) use occurrence.
This is the template that will be rendered.
This view is used to display an occurrence. There are two methods of displaying an occurrence.
From here you need a way to distinguish the occurrence and that involves.
or it requires a distinguishing datetime as designated by the keywords below. This should designate the original start date of the occurrence that you wish to access. Using get_absolute_url from the Occurrence model will help you standardise this.
This is the template that will be rendered.
This view is used to edit an occurrence.
From here you need a way to distinguish the occurrence and that involves
or it requires a distinguishing datetime as designated by the keywords below. This should designate the original start date of the occurrence that you wish to access. Using get_edit_url from the Occurrence model will help you standardise this.
This is the template that will be rendered.
This view is used to cancel an occurrence. It is worth noting that cancelling an occurrence doesn’t stop it from being in occurrence lists or being ‘exceptional’, it just changes the cancelled flag on the instance. It is important to check this flag when listing occurrences.
Also if this view is requested via POST, it will cancel the event and redirect. If this view is accessed via a GET request it will display a confirmation page.
from here you need a way to distinguish the occurrence and that involves
or it requires a distinguishing datetime as designated by the keywords below. This should designate the original start date of the occurrence that you wish to access. Using get_cancel_url from the Occurrence model will help you standardise this.
This is the template that will be rendered, if this view is accessed via GET.
This is the url to which you wish to be redirected after a successful cancellation.
This view is used for creating or editing events. If it receives a GET request or if given an invalid form in a POST request it will render the template, or else it will redirect.
This is the template that will be rendered
This view is for deleting events. If the view is accessed via a POST request it will delete the event. If it is accessed via a GET request it will render a template to ask for confirmation.
This is the template that will be rendered.
If you want to require a login before deletion happens you can set that here.