mholling-subdomain_routes 0.1.0

data/LICENSE

@@ -0,0 +1,20 @@
+Copyright (c) 2009 Matthew Hollingworth
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

data/README.textile

@@ -0,0 +1,323 @@
+h1. SubdomainRoutes - Adding Subdomains to Rails Routing
+
+The Rails "routing system":http://api.rubyonrails.org/classes/ActionController/Routing.html is a pretty impressive piece of code. There's a fair bit of magic going on to make your routes so easy to define and use in the rest of your Rails application. One area in which the routing system is limited however is its use of subdomains: it's pretty much assumed that your site will be using a single, fixed domain.
+
+There are times where it is preferable to spread a website over multiple subdomains. One common idiom in URL schemes is to separate aspects of the site under different subdomains, representative of those aspect. It many cases a simple, fixed subdomain scheme is desirable: _support.whatever.com_, _forums.whatever.com_, _gallery.whatever.com_ and so on. On some international sites, the subdomain is used to select the language and localization: _en.wikipedia.org_, _fr.wikipedia.org_, _ja.wikipedia.org_. Other schemes allocate each user of the site their own subdomain, so as to personalise the experience (_blogspot.com_ is a good example of this).
+
+A couple of plugins currently exists for Rails developers wishing to incorporate subdomains into their routes. The de facto standard is "SubdomainFu":http://www.intridea.com/2008/6/23/subdomainfu-a-new-way-to-tame-the-subdomain. (I'll admit - I haven't actually used this plugin myself.) There's also "SubdomainAccount":http://github.com/shuber/subdomain_account/tree/master.
+
+I've recently completed work on a subdomain library which fully incorporates subdomains into the rails routing environment - in URL generation, route recognition *and* in route definition, something I don't believe is currently available. As an added bonus, if offers the ability to define routes for _dynamic subdomains_, which are recognised based on the contents of your database, or on other dynamic conditions.
+
+h2. Installation
+
+The gem is called <code>SubdomainRoutes</code>, and is easy to install from GitHub (you only need to add GitHub as a source once):
+
+<pre>
+gem sources -a http://gems.github.com
+sudo gem install mholling-active_url
+</pre>
+
+In your Rails app, make sure to specify the gem dependency in environment.rb:
+
+<pre>
+config.gem "mholling-subdomain_routes", :lib => "subdomain_routes", :source => "http://gems.github.com"
+</pre>
+
+(Note that the SubdomainRoutes gem requires Rails 2.2 or later to run since it uses <code>ActiveSupport::Memoizable</code>. If you're on an older version of Rails, you need to get with the program. ;)
+
+Finally, you'll probably want to configure your session to work across all your subdomains. You can do this in your environment files:
+
+<pre>
+# in environment/development.rb:
+config.action_controller.session[:session_domain] = "yourdomain.local" # or whatever
+
+# in environment/production.rb:
+config.action_controller.session[:session_domain] = "yourdomain.com" # or whatever
+</pre>
+
+h2. Mapping a Single Subdomain
+
+Let's start with a simple example. Say we have a site which offers a support section, where users submit and view support tickets for problems they're having. It'd be nice to have that under a separate subdomain, say _support.mysite.com_. With subdomain routes we'd map that as follows:
+
+<pre>
+ActionController::Routing::Routes.draw do |map|
+  map.subdomain :support do |support|
+    support.resources :tickets
+    ...
+  end
+end
+</pre>
+
+What does this achieve? A few things. For routes defined within the subdomain block:
+
+* named routes have a <code>support_</code> prefix;
+* their controllers will have a <code>Support::</code> namespace;
+* they will only be recognised if the host subdomain is _support_; and
+* paths and URLs generated for them by <code>url_for</code> and named routes will force the _support_ subdomain if the current host subdomain is different.
+
+This is just what you want for a subdomain-qualified route. Rails will recognize _support.mysite.com/tickets_, but not _www.mysite.com/tickets_.
+
+Let's take a look at the flip-side of route recognition - path and URL generation. The subdomain restrictions are also applied here:
+
+<pre>
+# when the current host is support.mysite.com:
+support_tickets_path
+=> "/tickets"
+
+# when the current host is www.mysite.com:
+support_tickets_path
+=> "http://support.mysite.com/tickets"
+
+# overriding the subdomain won't work:
+support_tickets_path(:subdomain => :www)
+#  ActionController::RoutingError: Route failed to generate
+#  (expected subdomain in ["support"], instead got subdomain "www")
+</pre>
+
+Notice that, by necessity, requesting a path still results in an URL if the subdomain of the route is different. If you try and override the subdomain manually, you'll get an error, because the resulting URL would be invalid and would not be recognized. This is a good thing - you don't want to be linking to invalid URLs by mistake!
+
+In other words, <code>url_for</code> and your named routes will *never* generate an invalid URL. This is one major benefit of the SubdomainRoutes gem: it offers a smart way of switching subdomains, requiring them to be specified manually only when absolutely necessary. (It gets even better with dynamic subdomains, which I will describe later.)
+
+h2. Mapping Multiple Subdomains
+
+Subdomain routes can be set on multiple subdomains too. Let's take another example. Say we have a review site, _reviews.com_, which has reviews of titles in several different media (say, DVDs, games, books and CDs). We want to key the media type to the URL subdomain, so the user knows by the URL what section of the site they're in. (I use this scheme on my "swapping site":http://things.toswap.com.au.) A subdomain route map for such a scheme could be as follows:
+
+<pre>
+ActionController::Routing::Routes.draw do |map|
+  map.subdomain :dvd, :game, :book, :cd, :name => :media do |media|
+    media.resources :reviews
+    ...
+  end
+end
+</pre>
+
+Notice that we've specified a generic name (_media_) for our subdomain, so that our namespace and named route prefix become <code>Media::</code> and <code>media_</code>, respectively. (We could also set the <code>:name</code> to nil, or override <code>:namespace</code> or <code>:name_prefix</code> individually.)
+
+Recognition of these routes will work in the same way as before. The URL _dvd.reviews.com/reviews_ will be recognised, as will _game.reviews.com/reviews_, and so on. No luck with _concert.reviews.com/reviews_, as that subdomain is not listed in the <code>subdomain</code> mapping.
+
+URL generation may behave differently however. If the URL is being generated with current host _www.reviews.com_, there is no way for Rails to know which of the subdomains to use, so you must specify it in the call to <code>url_for</code> or the named route. On the other hand, if the current host is _dvd.reviews.com_ the URL or path will just generate with the current host unless you explicitly override the subdomain. Check it:
+
+<pre>
+# when the current host is dvd.reviews.com:
+media_reviews_path
+=> "/reviews"
+
+# when the current host is www.reviews.com:
+media_reviews_path
+#  ActionController::RoutingError: Route failed to generate (expected
+#  subdomain in ["dvd", "game", "book", "cd"], instead got subdomain "www")
+
+media_reviews_path(:subdomain => :book)
+=> "http://book.reviews.com/reviews"
+</pre>
+
+Again, requesting a path may result in an URL or a path, depending on whether the subdomain of the current host needs to be changed. And again, the URL-writing system will not generate any URL that will not in turn be recognised by the app.
+
+h2. Mapping the Nil Subdomain
+
+SubdomainRoutes allows you to specify routes for the "nil subdomain" - for example, URLs using _example.com_ instead of _www.example.com_. To do this though, you'll need to configure the gem.
+
+By default, SubdomainRoutes just extracts the first part of the host as the subdomain, which is fine for most situations. But in the example above, _example.com_ would have a subdomain of _example_; obviously, not what you want. You can change this behaviour by setting a configuration option (you can put this in an initializer file in your Rails app):
+
+<pre>
+SubdomainRoutes::Config.domain_length = 2
+</pre>
+
+With this set, the subdomain for _example.com_ will be <code>""</code>, the empty string. (You can also use nil to specify this in your routes.)
+
+If you're on a country-code top-level domain (e.g. _toswap.com.au_), you'd set the domain length to three. You may even need to set it to four (e.g. for nested government and education domains such as _health.act.gov.au_).
+
+(Note that, in your controllers, your request will now have a <code>subdomain</code> method which returns the subdomain extracted in this way.)
+
+Here's an example of how you might want to use a nil subdomain:
+
+<pre>
+ActionController::Routing::Routes.draw do |map|
+  map.subdomain nil, :www do |www|
+    www.resource :home
+    ...
+  end
+end
+</pre>
+
+All the routes within the subdomain block will resolve under both _www.example.com_ and just _example.com_.
+
+(As an aside, this is not actually an approach I would recommend taking; you should probably not have the same content mirrored under two different URLs. Instead, set up your server to redirect to your preferred host, be it with the _www_ or without.)
+
+Finally, for the nil subdomain, there is some special behaviour. Specifically, the namespace and name prefix for the routes will default to the first non-nil subdomain (or to nothing if _only_ the nil subdomain is specified). You can override this behaviour by passing a <code>:name</code> option.
+
+h2. Nested Resources under a Subdomain
+
+REST is awesome. If you're not using "RESTful routes":http://api.rubyonrails.org/classes/ActionController/Resources.html in your Rails apps, you should be. It offers a disciplined way to design your routes, and this flows through to the design of the rest of your app, encouraging you to capture pretty much all your application logic in models and leaving your controllers as generic and "skinny":http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model as can be.
+
+Subdomain routes work transparently with RESTful routes - any routes nested under a resource will inherit the subdomain conditions of that resource:
+
+<pre>
+ActionController::Routing::Routes.draw do |map|
+  map.subdomain :admin do |admin|
+    admin.resources :roles, :has_many => :users
+    ...
+  end
+end
+</pre>
+
+Your <code>admin_role_users_path(@role)</code> will automatically generate with the correct _admin_ subdomain if required, and paths such as _/roles/1/users_ will only be recognised when under the _admin_ subdomain. Note that both the block form and the <code>:has_many</code> form of nested resources will work in this manner. (In fact, under the hood, the latter just falls through to the former.) Any other (non-resource) routes you nest under a resource will also inherit the subdomain conditions.
+
+h2. Setting Up Your Development Environment
+
+To develop your app using SudomainRoutes, you'll need to set up your machine to point some test domains to the server on your machine (i.e. to the local loopback address, 127.0.0.1). On a Mac, you can do this by editing <code>/etc/hosts</code>. Let's say you want to use the subdomains _www_, _dvd_, _game_, _book_ and _cd_, with a domain of _reviews.local_. Adding these lines to <code>/etc/hosts</code> will do the trick:
+
+<pre>
+127.0.0.1 reviews.local
+127.0.0.1 www.reviews.local
+127.0.0.1 dvd.reviews.local
+127.0.0.1 game.reviews.local
+127.0.0.1 book.reviews.local
+127.0.0.1 cd.reviews.local
+</pre>
+
+You'll need to flush your DNS cache for these changes to take effect:
+
+<pre>
+dscacheutil -flushcache
+</pre>
+
+Then fire up your <code>script/server</code>, point your browser to _www.reviews.local:3000_ and your app should be up and running. If you're using "Passenger":http://www.modrails.com to "serve your apps in development":http://www.google.com/search?q=rails+passenger+development (and I highly recommend that you do), you'll need to add a Virtual Host to your Apache .conf file. (Don't forget to alias all the subdomains and restart the server.)
+
+If you're using dynamic subdomain routes (covered in my next article), you may want to use a catch-all (wildcard) subdomain. Setting this up is not so easy, since wildcards (like _*.reviews.local_) won't work in your <code>/etc/hosts</code> file. There are a couple of work-around for this:
+
+# Use a "proxy.pac":http://en.wikipedia.org/wiki/Proxy.pac file in your browser so that it proxies _*.reviews.local_ to localhost. How to do this will depend on the browser you're using.
+# Set up a local DNS server with an A record for the domain. This may be a bit involved.
+
+h2. Dynamic Subdomain Recognition
+
+SubdomainRoutes also offers a full complement of features for recognizing subdomain URLS which are not known in advance. (I'll refer to these cases as _dynamic subdomains_.) For example, if you are keying each user of your website to their own subdomain, your routes will need to recognise new subdomains as new users sign up. Another example is if you want to key your URL subdomains to a set of categories (language, city, product type, etc.) which may expand as your site grows. In each case, your subdomains will depend on records in the database.
+
+Let's take a hypothetical example of a blogging site which lets users show and manage their blog under their own subdomains (think _blogspot.com_). Assume our <code>User</code> model has a <code>subdomain</code> attribute which contains the user's custom subdomain. In our routes we'll still use the <code>subdomain</code> mapper, but instead of specifying one or more subdomains, we just specify a <code>:proc</code> option:
+
+<pre>
+ActionController::Routing::Routes.draw do |map|
+  map.subdomain :proc => :blog do |blog|
+    blog.resources :articles, :has_many => :comments
+    ...
+  end
+end
+
+ActionController::Routing::Routes.recognize_subdomain :blog do |subdomain|
+  User.exists?(:username => subdomain)
+end
+</pre>
+
+Note the last few lines, which are crucial. Here we are defining a method for recognizing blog subdomains. This is done using a new method, <code>recognize_subdomain</code>, which the gem adds to <code>ActionController::Routing::Routes</code>.
+
+As arguments, the <code>recognize_subdomain</code> method takes a subdomain label, as used in the route (in this case, <code>:blog</code>), and a block. The block should take a single argument (the subdomain to be recognised), and should return true or false depending on whether the subdomain should be recognised for that route. In this case, we simply look up the subdomain in the <code>User</code> model to see if it's in use.
+
+That's all there is to it! Now our blog routes will recognize more subdomains as more users sign up.
+
+How does URL _generation_ work with these routes? Pretty much as you'd expect. Let's say our awesome new blogging site, _awesomeblogs.com_, has only two users, who've selected subdomains _mholling_ and _rails_. In controllers and views, our named routes will work as follows:
+
+<pre>
+# when the current host is mholling.awesomeblogs.com:
+blog_articles_path
+=> "/articles"
+
+blog_articles_path(:subdomain => "rails")
+=> "http://rails.awesomblogs.com/articles"
+
+blog_articles_path(:subdomain => "www")
+#  ActionController::RoutingError: Route failed to generate
+#  (subdomain "www" is invalid)
+
+# when the host is www.awesomeblogs.com:
+blog_articles_path(:subdomain => "rails")
+=> "http://rails.awesomblogs.com/articles"
+
+blog_articles_path
+#  ActionController::RoutingError: Route failed to generate
+#  (subdomain "www" is invalid)
+</pre>
+
+As you can see, the subdomain recognition method that we defined is being used to check for an invalid subdomain when the URL is being written. Nice!
+
+h3. Caching of Dynamic Subdomain Recognition
+
+Internally, the results of the subdomain recognition block are cached. If this weren't done, the block could be run many time per request (once for each route until one is recognised). That would be bad, since in most cases the database will be hit each time the block is called. (Sure, Rails will probably cache the database queries, but you may as well cache as high up the chain as you can.)
+
+The problem then becomes - when does the cache get flushed?  By default, this will occur once per request, which should be fine for many applications. If that's the case, you don't need to do anything.
+
+To optimise performance however, you can disable the per-request cache flush and do it manually. Set this option in your configuration:
+
+<pre>
+SubdomainRoutes::Config.manual_flush = true
+</pre>
+
+In the above example we might want to choose this route, so that we can flush the cache only when a user is created or destroyed (or changes the subdomain). We could do this easily using an observer:
+
+<pre>
+class UserObserver < ActiveRecord::Observer
+  observe :user
+
+  after_save(user)
+    if user.subdomain_changed?
+      ActionController::Routing::Routes.subdomain_procs.flush!
+    end
+  end
+
+  after_destroy(user)
+    ActionController::Routing::Routes.subdomain_procs.flush!
+  end
+end
+
+# and in config/environment.rb:
+config.active_record.observers = [ :user_observer ]
+</pre>
+
+Another way to reduce the number of calls to the subdomain recognition block is by defining the dynamic subdomain route as late in <code>routes.rb</code> as possible. That way, the block will only be called if none of the other routes have resolved.
+
+h3. ActiveRecord Validations
+
+SubdomainRoutes also gives you a utility validation, <code>validates_subdomain_format_of</code>, for your ActiveRecord models. If you're storing a subdomain in a model (as we have been with our <code>User</code> example), you can use this validation to make sure that a subdomain field uses only legal characters and is in an allowed format. (Undoubtedly, you'll want to throw in a <code>validates_uniqueness_of</code> as well.)
+
+<pre>
+class User < ActiveRecord::Base
+  ...
+  validates_subdomain_format_of :subdomain
+  validates_uniqueness_of :subdomain
+  ...
+end
+</pre>
+
+The library currently uses a simple regexp to limit subdomains to lowercase alphanumeric characters and dashes (except on either end). If you want to conform more precisely to the URI specs, you can override the <code>SubdomainRoutes.valid_subdomain?</code> method and implement your own.
+
+h2. Using Static and Dynamic Subdomain Routes Together
+
+Let's try using static and dynamic subdomain routes together. Say we want to reserve some subdomains (say _support_ and _admin_) for administrative functions, with the remainder keyed to user accounts. Our routes:
+
+<pre>
+ActionController::Routing::Routes.draw do |map|
+  map.subdomain :support do |support|
+    ...
+  end
+  map.subdomain :admin do |admin|
+    ...
+  end
+  map.subdomain :proc => :user do |user|
+    ...
+  end
+end
+
+ActionController::Routing::Routes.recognize_subdomain :blog do |subdomain|
+  User.exists?(:username => subdomain)
+end
+</pre>
+
+These routes will co-exist quite happily together. (We've made sure our static subdomain routes are listed first though.) In the User model we'll add an extra validation to prevent users from taking the reserved subdomains:
+
+<pre>
+validates_exclusion_of :subdomain, :in => %w{support admin www}
+</pre>
+
+(We could also validate for a minimum and maximum length.)
+
+
+Copyright (c) 2009 Matthew Hollingworth. See LICENSE for details.

data/Rakefile

@@ -0,0 +1,57 @@
+require 'rubygems'
+require 'rake'
+
+begin
+  require 'jeweler'
+  Jeweler::Tasks.new do |gem|
+    gem.name = "subdomain_routes"
+    gem.summary = %Q{A Rails library for incorporating subdomains into route generation and recognition.}
+    gem.description = <<-EOF
+      SubdomainRoutes add subdomain conditions to the Rails routing system. Routes may be restricted to
+      one or many specified subdomains. An URL will be recognised only if the host subdomain matches the
+      subdomain specified in the route. Route generation is also enhanced, so that the subdomain of a
+      generated URL (or path) will be changed if the requested route has a different subdomain to that of
+      the current request. Dynamic subdomain routes can also be defined.
+    EOF
+    gem.email = "mdholling@gmail.com"
+    gem.homepage = "http://github.com/mholling/subdomain_routes"
+    gem.authors = ["Matthew Hollingworth"]
+    gem.add_dependency 'actionpack', ">= 2.2.1" # requires ActiveSupport::Memoizable
+    gem.has_rdoc = false
+
+    # gem is a Gem::Specification... see http://www.rubygems.org/read/chapter/20 for additional settings
+  end
+rescue LoadError
+  puts "Jeweler not available. Install it with: sudo gem install technicalpickles-jeweler -s http://gems.github.com"
+end
+
+require 'spec/rake/spectask'
+Spec::Rake::SpecTask.new(:spec) do |spec|
+  spec.libs << 'lib' << 'spec'
+  spec.spec_files = FileList['spec/**/*_spec.rb']
+end
+
+Spec::Rake::SpecTask.new(:rcov) do |spec|
+  spec.libs << 'lib' << 'spec'
+  spec.pattern = 'spec/**/*_spec.rb'
+  spec.rcov = true
+end
+
+
+task :default => :spec
+
+require 'rake/rdoctask'
+Rake::RDocTask.new do |rdoc|
+  if File.exist?('VERSION.yml')
+    config = YAML.load(File.read('VERSION.yml'))
+    version = "#{config[:major]}.#{config[:minor]}.#{config[:patch]}"
+  else
+    version = ""
+  end
+
+  rdoc.rdoc_dir = 'rdoc'
+  rdoc.title = "subdomain_routes #{version}"
+  rdoc.rdoc_files.include('README*')
+  rdoc.rdoc_files.include('lib/**/*.rb')
+end
+

data/VERSION.yml

@@ -0,0 +1,4 @@
+--- 
+:patch: 0
+:major: 0
+:minor: 1

data/lib/subdomain_routes/config.rb

@@ -0,0 +1,6 @@
+module SubdomainRoutes
+  module Config
+    mattr_accessor :domain_length
+    mattr_accessor :manual_flush
+  end
+end

data/lib/subdomain_routes/mailer.rb

@@ -0,0 +1,17 @@
+module SubdomainRoutes
+  module MailerMethods
+    def self.included(base)
+      base.alias_method_chain :create!, :subdomains
+    end
+    
+    def create_with_subdomains!(*args)
+      ActionController::Routing::Routes.subdomain_procs.flush! unless SubdomainRoutes::Config.manual_flush
+      create_without_subdomains!(*args)
+    end
+  end
+end
+
+if defined? ActionMailer::Base
+  ActionMailer::Base.send :include, SubdomainRoutes::MailerMethods
+end
+

data/lib/subdomain_routes/mapper.rb

@@ -0,0 +1,40 @@
+module SubdomainRoutes
+  module Routing
+    module RouteSet
+      module Mapper
+        def subdomain(*subdomains, &block)
+          options = subdomains.extract_options!
+          name = nil
+          if subdomains.empty?
+            if subdomain = options.delete(:proc)
+              subdomain_options = { :subdomains => { :proc => subdomain } }
+              name = subdomain
+            else
+              raise ArgumentError, "Please specify at least one subdomain!"
+            end
+          else
+            subdomains.map!(&:to_s)
+            subdomains.map!(&:downcase)
+            subdomains.uniq!
+            subdomains.compact.each do |subdomain|
+              raise ArgumentError, "Illegal subdomain format: #{subdomain.inspect}" unless subdomain.blank? || SubdomainRoutes.valid_subdomain?(subdomain)
+            end
+            if subdomains.include? ""
+              raise ArgumentError, "Can't specify a nil subdomain unless you set Config.domain_length!" unless Config.domain_length
+            end
+            name = subdomains.reject(&:blank?).first
+            subdomain_options = { :subdomains => subdomains }
+          end
+          name = options.delete(:name) if options.has_key?(:name)
+          name = name.to_s.downcase.gsub(/[^(a-z0-9)]/, ' ').squeeze(' ').strip.gsub(' ', '_') unless name.blank?
+          subdomain_options.merge! :name_prefix => "#{name}_", :namespace => "#{name}/" unless name.blank?
+          with_options(subdomain_options.merge(options), &block)
+        end
+        alias_method :subdomains, :subdomain
+      end
+    end
+  end
+end
+
+ActionController::Routing::RouteSet::Mapper.send :include, SubdomainRoutes::Routing::RouteSet::Mapper
+

data/lib/subdomain_routes/proc_set.rb

@@ -0,0 +1,33 @@
+module SubdomainRoutes
+  class ProcSet
+    extend ActiveSupport::Memoizable
+    
+    def initialize
+      clear!
+    end
+    
+    def add_recognizer(name, &block)
+      @recognizers[name] = block
+    end
+
+    def recognizes?(name)
+      @recognizers.has_key?(name)
+    end
+
+    def recognize(name, subdomain)
+      @recognizers[name].call(subdomain) if recognizes?(name)
+    end
+    
+    memoize :recognize
+    private :flush_cache
+    
+    def flush!
+      flush_cache :recognize
+    end
+    
+    def clear!
+      @recognizers = {}
+      flush!
+    end
+  end
+end

data/lib/subdomain_routes/request.rb

@@ -0,0 +1,12 @@
+module SubdomainRoutes
+  module Request
+    include SplitHost
+    
+    def subdomain
+      subdomain_for_host(host)
+      # TODO: catch HostNotSupplied and TooManySubdomains and deal with them somehow!
+    end
+  end
+end
+
+ActionController::Request.send :include, SubdomainRoutes::Request

data/lib/subdomain_routes/resources.rb

@@ -0,0 +1,49 @@
+module SubdomainRoutes
+  module Resources
+    def self.included(base)
+      base.alias_method_chain :action_options_for, :subdomains
+      base::INHERITABLE_OPTIONS << :subdomains
+    end
+    
+    def action_options_for_with_subdomains(action, resource, *args)
+      action_options_for_without_subdomains(action, resource, *args).merge(:subdomains => resource.options[:subdomains])
+    end
+    private :action_options_for_with_subdomains
+  end
+end
+
+ActionController::Resources.send :include, SubdomainRoutes::Resources
+
+
+
+
+# # 
+# # This alternative also works. It duplicates code in add_route_with_subdomains (in routing.rb) so is not
+# # so good that way, but has the benefit of not modifying ActionController::Resources#action_options_for,
+# # which is a private method.
+# # 
+# module SubdomainRoutes
+#   module Resources
+#     module Resource
+#       def self.included(base)
+#         base.alias_method_chain :conditions, :subdomains
+#         base.alias_method_chain :requirements, :subdomains
+#       end
+#       
+#       def conditions_with_subdomains
+#         @options[:subdomains] ?
+#           conditions_without_subdomains.merge(:subdomains => @options[:subdomains]) :
+#           conditions_without_subdomains
+#       end
+#       
+#       def requirements_with_subdomains(with_id = false)
+#         @options[:subdomains] ?
+#           requirements_without_subdomains(with_id).merge(:subdomains => @options[:subdomains]) :
+#           requirements_without_subdomains(with_id)
+#       end
+#     end
+#   end
+# end
+# 
+# ActionController::Resources::INHERITABLE_OPTIONS << :subdomains
+# ActionController::Resources::Resource.send :include, SubdomainRoutes::Resources::Resource

data/lib/subdomain_routes/routes.rb

@@ -0,0 +1,66 @@
+module SubdomainRoutes
+  module Routing
+    module RouteSet
+      include SplitHost
+      
+      def self.included(base)
+        [ :extract_request_environment, :add_route, :clear!, :call ].each { |method| base.alias_method_chain method, :subdomains }
+      end
+      
+      def extract_request_environment_with_subdomains(request)
+        extract_request_environment_without_subdomains(request).merge(:subdomain => subdomain_for_host(request.host))
+      end
+    
+      def add_route_with_subdomains(*args)
+        options = args.extract_options!
+        if subdomains = options.delete(:subdomains)
+          options[:conditions] ||= {}
+          options[:conditions][:subdomains] = subdomains
+          options[:requirements] ||= {}
+          options[:requirements][:subdomains] = subdomains
+        end
+        with_options(options) { |routes| routes.add_route_without_subdomains(*args) }
+      end
+      
+      def subdomain_procs
+        @subdomain_procs ||= SubdomainRoutes::ProcSet.new
+      end
+
+      def recognize_subdomain(name, &block)
+        subdomain_procs.add_recognizer(name, &block)
+      end
+      
+      def clear_with_subdomains!
+        subdomain_procs.clear!
+        clear_without_subdomains!
+      end
+      
+      def call_with_subdomains(*args)
+        subdomain_procs.flush! unless SubdomainRoutes::Config.manual_flush
+        call_without_subdomains(*args)
+      end
+    end
+  
+    module Route
+      def self.included(base)
+        base.alias_method_chain :recognition_conditions, :subdomains
+      end
+      
+      def recognition_conditions_with_subdomains
+        result = recognition_conditions_without_subdomains
+        case conditions[:subdomains]
+        when Array
+          result << "conditions[:subdomains].include?(env[:subdomain])"
+        when Hash
+          if subdomain = conditions[:subdomains][:proc]
+            result << %Q{ActionController::Routing::Routes.subdomain_procs.recognize(#{subdomain.inspect}, env[:subdomain])}
+          end
+        end
+        result
+      end
+    end
+  end
+end
+
+ActionController::Routing::RouteSet.send :include, SubdomainRoutes::Routing::RouteSet
+ActionController::Routing::Route.send :include, SubdomainRoutes::Routing::Route