alexkahn / reservator Goto Github PK

Should display:

• List of their starred restaurants
• Upcoming reservations

Should be able to

• Modify reservations

Since the restaurant index isn't the best place to send users anymore, it may be intelligent to generate a contoller whose sole responsibility is grabbing data from various models that produces a landing page and the two dash boards.

It could look something like:

class HomeController < ApplicationController
  before_action :authenticated?, on: [:owner_dashboard, :patron_dashboard]

  def index
  end

  def owner_dashboard
    redirect_to action: "index" unless current_user.owner?
  end

  def patron_dashboard
    redirect_to action: "index" unless current_user.patron?
  end

end

It would be smart to generalize the logic for checking authorization alongside authentication. It may be necessary to check the calling method to see what to check for and just send back a boolean - probably a job for controller concerns or the like.

In app/assets/javascripts/star.js.coffee, something like:

function toggleStar ->
var url;
if $('#star').hasClass('starred') 
   url = '/stars/delete'
else 
  url = 'stars/create'

$.post({
  url: url,
  method: "post",
  success: ->
    $('#star').toggle( '.starred')
})

If erb can be used to pass in the url or other fun stuff then a more complicated method may not be needed.

There should of course be routes that responds_to json and render json response objects that confirm or deny the creation of the star.

@carolineartz I've got some traction on this database business but any advice would totally rock!

Needed:

• edit
• index?

Need updating

• new
• show

Should display:

• Restaurant list with count of stars
• Reservations (pending, confirmed, ordered)

Should be able to:

• Confirm or deny reservations by restaurant
• Add a new restaurant

There should be maps on restaurant show pages.

This means that some sort of geocoding needs to be done (it can be outsourced to the Goog), it would be good to have it persist (buildings don't move much) and it can be easily recalculated if the address field changes via a model callback that calls a geocoder object.

Tools:

• Leaflet.js
• HTML Location grabber for users

Should validate that reservation can only be made in future
Should have a scope available for upcoming reservations like:

scope :visible, -> { where("date_time > ?", Time.now) }