Mapping current account to subdomain

[Alexander Hoth]

Hi there,

Is there any way with rc to accomplish something like the /account pattern
for the currently logged in user with subdomains instead?

Normally we would map everything under a specific account like that:

map_enclosing_resource :account, :singleton => true, :find =>
:current_account

This works fine with

http://www.example.com/account/items

But what would I need to do for the same funktionality with an url like
that?

http://foo.example.com/items

Regards,

Alex

--

Alexander Hoth
Web Application Developer

mailto:m...@alexanderhoth.com

[Jason Lee]

Hi Alex

On Dec 22, 2:50 am, Alexander Hoth <m...@alexanderhoth.com> wrote:
> Is there any way with rc to accomplish something like the /account pattern
> for the currently logged in user with subdomains instead?
>
> Normally we would map everything under a specific account like that:
>
> map_enclosing_resource :account, :singleton => true, :find =>
> :current_account
>
> This works fine with
> http://www.example.com/account/items
> But what would I need to do for the same funktionality with an url like
> that?
> http://foo.example.com/items

To get http://foo.examples.com/items to work I think (i've not tried
it) you'll need to override the RC resource_service (which in turn is
used by find_resource, find_resources, and new_resource) in a before
filter in your items_controller.

before_filter :set_resource_service

def set_resource_service
@account = ....... # set @account based on subdomain
resource_service = @account.items
end

(This code uses this method:
http://plugins.ardes.com/doc/resources_controller/classes/Ardes/ResourcesController/InstanceMethods.html#M000025
)

While this works for your /items controller you'll also need to set up
a map_enclosing_resource :item for any nested controllers (e.g.
foo.example.com/items/4/picture , foo.example.com/items/4/comments/3 )
to correctly find @item (e.g. @account.items.find(4) ) otherwise RC
won't scope correctly (e.g. Item.find(4) ).

You'll need to repeat all of this for any other top level and nested
resources under foo.example.com.


My thoughts are that if your users need to be logged in do you really
care what segments appear in the url? Also if you're scoping to to
the logged in user I prefer to use a top level singleton resource
called /user , that way RC sets automatically sets the instance
variable @user correctly. If you're using /account you end up with
@account instance variable being set to your current User
( Alternatively, using /account does makes sense if you have an
Account model instance to match up to the current_user or
subdomain ). If foo.example.com is a public site it's easier to use
RC with normal /account pattern but you can make the leading singular-
resource/routing-segment to be something more preferable such as /
bookshelf , /catalogue , /portfolio , /our, /my etc. or you can even
use multiple differently named /account(s) (that behave identically)
if you need them for usability or SEO purposes.

Jason.

[tsdbrown]

Hey

I'm just wondering whether anybody else has been looking/using this as
a solution? Jason I think you need

def set_resource_service
self.resource_service = @account.items
end

for your suggestion to work.

We would like to start use subdomains to filter the data loaded in our
app based on the @account, but as of yet those resources aren't nested
in the account as it doesn't yet exist, there was only one until now.
I'm just wondering whether this is the correct way to do things with
lots of nested resources using RC.

Luke.

On Dec 22 2008, 11:07 am, Jason Lee <jls...@gmail.com> wrote:
> Hi Alex
>
> On Dec 22, 2:50 am, Alexander Hoth <m...@alexanderhoth.com> wrote:
>
> > Is there any way with rc to accomplish something like the /account pattern
> > for the currently logged in user withsubdomainsinstead?
>
> > Normally we would map everything under a specific account like that:
>
> > map_enclosing_resource :account, :singleton => true, :find =>
> > :current_account
>
> > This works fine with
> >http://www.example.com/account/items
> > But what would I need to do for the same funktionality with an url like
> > that?
> >http://foo.example.com/items
>

> To gethttp://foo.examples.com/itemsto work I think (i've not tried

> it) you'll need to override the RC resource_service (which in turn is
> used by find_resource, find_resources, and new_resource) in a before
> filter in your items_controller.
>
> before_filter :set_resource_service
>
> def set_resource_service
>   @account = .......  # set @account based on subdomain
>   resource_service = @account.items
> end
>

> (This code uses this method:http://plugins.ardes.com/doc/resources_controller/classes/Ardes/Resou...

[Ian White]

Hi Luke,

I'm doing something like what you;re after. The domain (as in URI)
sets the Site model, and many things are relationships of that.

Basically, the pattern is

1. set @site early by looking it up somehow (I use the uri to look it
up from my Site class)
2. have a helper method in controllers that returns @site

(I coalesce the above steps into a lazy loading site method)

3. map all of the 'top level resources' to an association on site,
rather than the default (which will be their class)

This involves either setting the resource_service as Jason suggests,
or, for enclosing resources, you can just do something like this:

# posts controller, handles /forums/:id/posts
class PostsController < ApplicationController
resources_controller_for :posts

map_enclosing_resource :forum do
site.forum
end
end

If you use this controller to service a route such as: /users/:id/posts
then you also might want to make sure you're getting your users from
site.users, instead of User

Hope that helps,

Ian

[tsdbrown]

Hey Ian

Yeah that helps cheers, you've confirmed my suspicion about needing to
map all the top level resources to an association on the site/account
etc.

After getting my simplest top level resource working like this just
looks like I'll need to finish the branch by re-organisation the rest
to use the same method. I'm just glad I don't need to loose RC to
handle it as it's heavily used in the app :)

Have you seen this?

http://gist.github.com/44410

Guess that's one variation to step 1 and 2.

Luke.

> >> To gethttp://foo.examples.com/itemstowork I think (i've not tried

[Ian White]

> Yeah that helps cheers,
Cool, let us know if you discover any neat tricks along the way. Or
if you have to repeat yourself in certain painful way over and over,
maybe we can sort something easier out with RC + account subdomain
pattern

> Have you seen this?
>
> http://gist.github.com/44410

I do something like this: (using that example)

def account
@account ||= Account.find_by_subdomain(request.subdomains.first)
end

# later...

def set_resource_service
self.resource_service = account.forums
end

map_enclosing_resource(:forum) { account.forums.find(:forum_id) }

So, the diff being - no before filter, and lazy load the account.
This is good if you've got some fragment caching stuff, or if not all
controllers need the account - the acocunt appears just in time when
it's needed.

Cheers,
Ian