Show a single movie

[maggielove]

-A template/ view that will show a single movie pulled from the 3rd party API--title, poster, director, rating, date added, release date, comments (note: comments will start out only showing comments a user has put on his/ her own selected movies) --(Will)

(Eventual option: make it so that users can see other users' comments on movies other users have already selected.) --(Luis)

[luisarce5]

Added & committed in luis branch the following:. Completed Route ('/') in movies_controller.js. which is accessed as /movies. That route connects to database and displays the database's contents in /movies route in browser. For this to work, I seeded sample in database manually thru $mongo in terminal.

* Important amendment to original post * Run $mongod in terminal and leave that window open.
Then open another window in terminal, and then you can access the database in new window by running $mongo. \ End of amendment**

$mongo Now in mongo:

use moviegoer // creates database named moviegoer & switches to it.

then seeded sample movie in database.

db.mymovies.insert({ ... title: "The Good Dinosaur", ... overview: "‘The Good Dinosaur’ asks the question: What if the asteroid that forever changed life on Earth missed the planet completely and giant dinosaurs never became extinct?", ... release_date: 2015-11-25, ... poster_path: "/2ZckiMTfSkCep2JTtZbr73tnQbN.jpg", ... comments: "" ... })

Then, confirm that there is a new item in database

db.mymovies.find()

• Notes: 1) In order for data to flow from database thru controller, server and display in browser, make sure that name chosen when creating database 'moviegoer' matches name used in server.js in line 20: mongoose.connect('mongodb://localhost/moviegoer'); 2) For this to work, this also required that the movie schema be already created in /models.movie.js

[luisarce5]

Additional important point for the steps listed in the comment above to work. Run $mongod in terminal and leave that window open. Then open another window in terminal, and then you can access the database by running $mongo. Then you can execute all the steps described in the comment above regarding seeding a sample in the database.

[maggielove]

Hey Luis,

This looks good! I haven't tested anything yet.

• I was just confused by the naming of the route. Going off the way we've been semantically naming routes, I would expect a /movies/ route to display a list of movies (--and maybe for our app, this would actually not be /movies but https://api.themoviedb.org/3/movie/now_playing?api_key=5c47d1a627613469f840623448f6e67b and https://api.themoviedb.org/3/movie/upcoming?api_key=5c47d1a627613469f840623448f6e67b)

while a route that would display a single movie would be called something like /movies/:id

I have to take a closer look at your code and the database, but would it make sense to just move your Movie.find() code into a route called /:id ?

• Also, were you not able to run the command > use moviegoerApp to use our db? Just because that was how we named our database in the server.js file (l.20), so I was wondering why your test db was called 'moviegoer'.

[luisarce5]

Thanks for the comments and feedback. They are really helpful. Let me address different issues:

1) I agree with requiring a route such as movie/:id which I know is what we had defined and I will add. I had just wanted to post my progress with the index route ('/') within the movie router which helps to test that the database connects. However, the '/' route as included now is different than the route than the /id route. As I indicated in my original post, the '/' route retrieves ALL of the data in the database w/o filters. Recall this is just a route not seen by the user, and is only used by the back end if needed; of course we can omit if not used. Separately, on the /:id route, we filter by :id and display the result of a specific movie, as you point out.

Another point to remember, since we are using the route constructor, the route defined as ‘/‘ in the movies controller actually is accessed in the browser thru the route /movies/. So, a new route defined as ‘/:id' in the movies controller would be accessed in the browser thru the route /movies/:id. Perhaps you know already know it, but in any case, this link helped me to clarify how the Route constructor and syntax works. http://expressjs.com/guide/routing.html In particular the section express.Router. Something to consider when building the users controller.

2) This second issue relates to how we want to structure the framework of the app. The three of us had briefly touch upon it yesterday as we have two (maybe more) options to handle data once a user has already added a movie to his 'mymovies' .
2a) Are we storing the data for that movie info in the Mongo database?; or 2b) Are we accessing the 3rd party API to retrieve the movie info each time we want to render the info of that movie already listed under ‘mymovies;.

I think we talked about storing the data in Mongo for retrieval and display when necessary, so I worked under that assumption. Hence, the movies routes would access the database rather than the 3rd party API. This would be in line with the actions of Delete (issue # x14) and Edit (issue #x12) which modify the data in the database and not the 3rd party API. Anyway, we can change to either option as we decide (i.e. access API or Mongo database). We could even have a combination of them in our routes, as it is clear that we initially are required to get the info from the 3rd party API.


3) This brings me to a new issue, we had not discussed, differentiating in our naming between routes searching for / displaying a movie in the 3rd Party API and routes searching for / displaying a movie already selected by an User (which would have other fields such as user comments, user ratings, etc.)

Anyway, regardless of our choice, I agree we need to define in the controller the routes you pointed out: https://api.themoviedb.org/3/movie/now_playing?api_key=5c47d1a627613469f840623448f6e67b and https://api.themoviedb.org/3/movie/upcoming?api_key=5c47d1a627613469f840623448f6e67b)

It is just a matter of what naming convention we want to use in order to differentiate.

[luisarce5]

I'll include both approaches in the code as I move forward for now. We can then decide what we want.

[luisarce5]

Movie.find() sends back all of the data in the collections mymovies, it does not filter. Filtering is done in the route :/id.

[maggielove]

Hey Luis, thanks for this! In response to:

1) "So, a new route defined as ‘/:id' in the movies controller would be accessed in the browser thru the route /movies/:id. "--Yes, on the same page here. Sorry for not being more clear when I was describing routes. I think the concept of your '/' route will make more sense once we start pulling movies from TMDb into user profiles (which ties into (2) and (3) below.).

2) I came across this when I was working on the user model. I think it would make the most sense to store the films in the database, but specifically, in a user's array of either 'to-watch' or 'watched' movies. (Still thinking this through--it might make more sense after I push up my user model). But yeah, you're right--we obviously want to be deleting and editing from our database, not the TMDb API.

3) I think naming of user routes will become clearer, to me at least, after I've done some more coding. We'll need routes both for a user's profile (/users/:id ?), which will show all movies (watched and to be watched, among other things), and for an individual movie on a user's profile (/users/:user_id/movies/:id ? This might be too complex/ not correctly named).

[luisarce5]

In movies controller, already added route /searchBytitle/:title' which is accessed in the browser at /movies/searchByTitle/:title. This performs a search in the database in the mymovies collection for a movie title (which presumably has already been added by an User), finds it and displays in the browser the info corresponding to that movie. If not found, it displays in the browser a corresponding message indicating so.