Client-side Event Modelling

[Jimmy-Lin]

Issue Description

Users Affected:

All users

Functionality Requested:

Create a client-side model of Event. This will interface with a future API exposing the server model of Event.

The main idea is to create a class called Event that supports a set of methods that will send AJAX requests to the server return promises to be fulfilled by responses. Once this is done, it will be easy to fetch the data from the server and pass the data to client-side view

The class should support the following methods:

List all events

class method: Event.list
parameters: none
returns: Promise
description:
Sends a GET request to the path /events/
Expects the server to return a JSON of all events { items: [event1, event2, ...] }
The if the requesting user does not have the right authorization, it may return a 400 with an error message. (User identity is encrypted in a cookie, make sure those are included present)
The promised object should be the final server response

List published events

class method: Event.published
parameters: none
returns: Promise
description:
Sends a GET request to the path /events/published
Expects the server to return a JSON of all events { items: [event1, event2, ...] }
The if the requesting user does not have the right authorization, it may return a 400 with an error message. (User identity is encrypted in a cookie, make sure those are included if present)
The promised object should be the final server response

List published events

class method: Event.show
parameters: event ID
returns: Promise
description:
Sends a GET request to the path /events/(:event_id)
Depending on the server response:

• if the server gives an error, throw that error
• if the server returns a found object return that object
  The if the requesting user does not have the right authorization, it may return a 400 with an error message. (User identity is encrypted in a cookie, make sure those are included if present)
  The promised object should be the final server response

Create a new event

class method: Event.create
parameters:

• title: string containing the name of the event
• description: brief description of the event
• tier: integer denoting the membership required for this event (ignore or set to 0)
• topic: integer denoting the topic of the event (ignore or set to 0)
  returns: Promise
  description:
  0. Send a GET request to the path /events/schema this provides the type declaration of each attribute and allows you to build an input form.
  1. Send a GET request to the path /events/new this provides you with a new instance of the record with any default values to fill the form in
  2. Fill in the record using the arguments used when calling this method
  3. Send a POST request to the path /events with the event you filled inside the body
     The request body, wait for server to respond.
  4. Depending on the response:
  • If the server gives an error, throw that error
  • if the creation is successful, return the response from the POST`
    The server may respond with 401 for unauthorized request or 400 for bad request or 404 if a resource is not found, thrown these as exceptions otherwise return a promise of the created record that comes back from the server after the POST
    (User identity is encrypted in a cookie, make sure those are included if present)

  Delete an event

  class method: Event.delete
  parameters: event ID
  returns: Promise
  description:
  Sends a DELETE request to the path /events/(:event_id)
  returns the server response

  In general, if the server response is an error ( status code >= 400 ) then throw that as an error.

  Progress

  Status: Not assigned

  Implementation

  Commit Hash: Not Yet Complete

  Author: @Jojo991

  Reviewer: @Jimmy-Lin, @bchugg

  Prior Behaviour:

  Currently there's no client-side logic for Events, this will help abstract away a lot of complexity when it comes time to integrate the event view

  New/Modified Behaviour:

  The event view should be able to get all it's needed data by calling methods in this class, instead of having to write lots of boiler-plate for AJAX calls.

  Validation

  Test Files:

  List Test Files Added/Modified

  Manual Validation Procedure:

  List Manual Checks Needed

  Follow-Up

  Usage Documentation:

  No Documentation

  Requirements:

  List Special Instructions Needed When Pulling/Deploying