Rails 3, Where Routing gets awesome!
by Savvas Georgiou on Nov 11, 2010
- 549 views
Slides form my presentation of Routing in Rails 3 in Athens Ruby Meetup #4
Slides form my presentation of Routing in Rails 3 in Athens Ruby Meetup #4
Accessibility
Categories
Tags
More...Upload Details
Uploaded via SlideShare as Apple Keynote
Usage Rights
© All Rights Reserved
Statistics
- Favorites
- 1
- Downloads
- 10
- Comments
- 0
- Embed Views
- Views on SlideShare
- 548
- Total Views
- 549
Xiaohong Zhao
yehuda katz:
When designing the new router, we all agreed that it should be built first as a standalone piece of functionality, with Rails sugar added on top.
Internally, the router simply matches requests to a rack endpoint, and knows nothing about controllers or controller semantics. Essentially, the router is designed to work like this:
yehuda katz:
When designing the new router, we all agreed that it should be built first as a standalone piece of functionality, with Rails sugar added on top.
Internally, the router simply matches requests to a rack endpoint, and knows nothing about controllers or controller semantics. Essentially, the router is designed to work like this:
yehuda katz:
When designing the new router, we all agreed that it should be built first as a standalone piece of functionality, with Rails sugar added on top.
Internally, the router simply matches requests to a rack endpoint, and knows nothing about controllers or controller semantics. Essentially, the router is designed to work like this:
yehuda katz:
When designing the new router, we all agreed that it should be built first as a standalone piece of functionality, with Rails sugar added on top.
Internally, the router simply matches requests to a rack endpoint, and knows nothing about controllers or controller semantics. Essentially, the router is designed to work like this:
yehuda katz:
When designing the new router, we all agreed that it should be built first as a standalone piece of functionality, with Rails sugar added on top.
Internally, the router simply matches requests to a rack endpoint, and knows nothing about controllers or controller semantics. Essentially, the router is designed to work like this:
yehuda katz:
When designing the new router, we all agreed that it should be built first as a standalone piece of functionality, with Rails sugar added on top.
Internally, the router simply matches requests to a rack endpoint, and knows nothing about controllers or controller semantics. Essentially, the router is designed to work like this:
yehuda katz:
When designing the new router, we all agreed that it should be built first as a standalone piece of functionality, with Rails sugar added on top.
Internally, the router simply matches requests to a rack endpoint, and knows nothing about controllers or controller semantics. Essentially, the router is designed to work like this:
yehuda katz:
When designing the new router, we all agreed that it should be built first as a standalone piece of functionality, with Rails sugar added on top.
Internally, the router simply matches requests to a rack endpoint, and knows nothing about controllers or controller semantics. Essentially, the router is designed to work like this:
yehuda katz:
When designing the new router, we all agreed that it should be built first as a standalone piece of functionality, with Rails sugar added on top.
Internally, the router simply matches requests to a rack endpoint, and knows nothing about controllers or controller semantics. Essentially, the router is designed to work like this:
yehuda katz:
When designing the new router, we all agreed that it should be built first as a standalone piece of functionality, with Rails sugar added on top.
Internally, the router simply matches requests to a rack endpoint, and knows nothing about controllers or controller semantics. Essentially, the router is designed to work like this:
yehuda katz:
When designing the new router, we all agreed that it should be built first as a standalone piece of functionality, with Rails sugar added on top.
Internally, the router simply matches requests to a rack endpoint, and knows nothing about controllers or controller semantics. Essentially, the router is designed to work like this:
yehuda katz:
When designing the new router, we all agreed that it should be built first as a standalone piece of functionality, with Rails sugar added on top.
Internally, the router simply matches requests to a rack endpoint, and knows nothing about controllers or controller semantics. Essentially, the router is designed to work like this:
yehuda katz:
When designing the new router, we all agreed that it should be built first as a standalone piece of functionality, with Rails sugar added on top.
Internally, the router simply matches requests to a rack endpoint, and knows nothing about controllers or controller semantics. Essentially, the router is designed to work like this: