Review

Topics Covered: Building Twitter By Hand

---

Exercises

E1: Review

1. Should you ever edit the schema.rb file? If not, what is it good for?
2. Why do we prefer form_for over form_tag ?
3. What are partials used for?
4. Explain to Zack why the comic below is funny:

E2: My data needs a way

1. What are examples of View Helper methods and what are they useful for?
2. cd into Meowbook, and hit rake routes. Identify the prefixes for your routes.
3. The URL /tweets corresponds to both tweets#index and tweets#create in our routes.rb file. How is this possible?
4. What does a redirect_to achieve? How is it different from rendering a view file?
5. In your routes.rb file, if you have a route that says root 'tweets#index', then a redirect_to "/" takes you to which URL?

E3: Hook it together

For this exercise, list the 6 steps required to put together a functioning Rails Application without scaffolding.

<<<<<<< HEAD

E2: Meowbook Upgrade

=======

E4: Meowbook Upgrade

>>>>>>> c8d630323065c2d822ba5256b783baec6e524ec4

In 9A you created User and Post, without scaffolding, to include the functionality to create new users/posts, and to see all of your posts. You also included relations for both resources.

Today we're going to continue rebuilding Meowbook by adding the update and delete actions. Before we jump in, however, we need to consider the nature of these two actions. For the update action, it makes sense that a user should be able to update a profile. Should they be able to update someone else's profile? Does it make sense for a user to be able to update a post? Do we want this kind of functionality? A user being able to delete a post also makes sense (we all say embarassing things now and again, even cats). Should a user be able to delete any post though? How about deleting users? Should you be able to delete someone else's profile?

Use these questions to think about how you would ensure that users do not have access to actions that they shouldn't.

Defining the above restrictions may be simplified by using User.last to identify the current user. Think about which actions will require you to define the current user.

---

Projects

Keep On Keepin On

You've spent the past few days honing your proposals and planning out your apps. While the planning process is ultimately continuous, your proposals and plans flexing and evolving as issues arise, you finally have enough information about your products to actually start building! After you've finalized your resources and the attributes each will require, start creating the relevant migrations and models (remember to include your relations in your models). You will also meet with a TA before the end of the day to check in on your progress.