By default, Rails applications build URLs based on the primary key -- the id column from the database. Imagine we have a Person model and associated controller. We have a person record for Bob Martin that has id number 6. The URL for his show page would be:
/people/6
But, for aesthetic or SEO purposes, we want Bob's name in the URL. The last segment, the 6 here, is called the "slug". Let's look at a few ways to implement better slugs.
It's pretty easy to do polymorphic associations in Rails: A Picture can belong to either a BlogPost or an Article. But what if you need the relationship the other way around? A Picture, a Text and a Video can belong to an Article, and that article can find all media by calling @article.media
This example shows how to create an ArticleElement join model that handles the polymorphic relationship. To add fields that are common to all polymorphic models, add fields to the join model.
| $OutputEncoding = New-Object -typename System.Text.UTF8Encoding | |
| [Console]::OutputEncoding = New-Object -typename System.Text.UTF8Encoding |
| # Support for Rspec / Capybara subdomain integration testing | |
| # Make sure this file is required by spec_helper.rb | |
| # (e.g. save as spec/support/subdomains.rb) | |
| def switch_to_subdomain(subdomain) | |
| # lvh.me always resolves to 127.0.0.1 | |
| hostname = subdomain ? "#{subdomain}.lvh.me" : "lvh.me" | |
| Capybara.app_host = "http://#{hostname}" | |
| end |
| module MyApp | |
| class Application < Rails::Application | |
| require Rails.root + 'lib/custom_public_exceptions' | |
| config.exceptions_app = CustomPublicExceptions.new Rails.public_path | |
| end | |
| end |
| module ApplicationHelper | |
| def current_class?(test_path) | |
| return 'active' if request.path == test_path | |
| '' | |
| end | |
| end |
On Tue, Mar 12, 2013 at 1:26 PM, Martin Fowler [email protected] wrote:
The term pops up in some different places, so it's hard to know what it means without some context. In PoEAA I use the pattern Service Layer to represent a domain-oriented layer of behaviors that provide an API for the domain layer. This may or may not sit on top of a Domain Model. In DDD Eric Evans uses the term Service Object to refer to objects that represent processes (as opposed to Entities and Values). DDD Service Objects are often useful to factor out behavior that would otherwise bloat Entities, it's also a useful step to patterns like Strategy and Command.
It sounds like the DDD sense is the sense I'm encountering most often. I really need to read that book.
The conceptual problem I run into in a lot of codebases is that rather than representing a process, the "service objects" represent "a thing that does the process". Which sounds like a nitpicky difference, but it seems to have a real impact on how people us
| @media (min-width:320px) { /* smartphones, portrait iPhone, portrait 480x320 phones (Android) */ } | |
| @media (min-width:480px) { /* smartphones, Android phones, landscape iPhone */ } | |
| @media (min-width:600px) { /* portrait tablets, portrait iPad, e-readers (Nook/Kindle), landscape 800x480 phones (Android) */ } | |
| @media (min-width:801px) { /* tablet, landscape iPad, lo-res laptops ands desktops */ } | |
| @media (min-width:1025px) { /* big landscape tablets, laptops, and desktops */ } | |
| @media (min-width:1281px) { /* hi-res laptops and desktops */ } |
| <%= form_for(@thing) do |f| %> | |
| <% if @thing.errors.any? %> | |
| <div id="error_explanation"> | |
| <h2><%= pluralize(@thing.errors.count, "error") %> prohibited this thing from being saved:</h2> | |
| <ul> | |
| <% @thing.errors.full_messages.each do |msg| %> | |
| <li><%= msg %></li> | |
| <% end %> | |
| </ul> |