Customisations per client

[Dmytrii Nagirniak]

Hi,

I was wondering ones do customisations per client in a Rails app?

Clients (businesses) do not want to bother with it and usually send their own "layout" and stuff. So we incorporate that into the app.

More information:

• every client obtains a subdomain;
• subdomain might get some of the pages customised;
• when a client is on the main (www) subdomain, no customisation applies, but same functionality is available;

I was thinking about overriding the lookup mechanism for the views to have structure like:

views/dashboards

index.html.erb

views/subdomain1/index,html.erb

But don't like it much as it is not very flexible (especially for assets per client) and will get harder and harder to maintain and test.

Have you done it before?
Any recommendations?

Cheers,

Dmytrii Nagirniak

http://ApproachE.com

[Chris Berkhout]

Could you do the customisation entirely in CSS?

If necessary, you could have the HTML contain a superset of what's
needed for individual versions of pages, then use CSS to show/hide
things appropriately.

That would greatly simplify it.

Cheers,
Chris

> --
> You received this message because you are subscribed to the Google Groups
> "Ruby or Rails Oceania" group.
> To post to this group, send email to rails-...@googlegroups.com.
> To unsubscribe from this group, send email to
> rails-oceani...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rails-oceania?hl=en.
>

[Adam Boas]

Hi Dmytrii,

It is not difficult to extract the subdomain from the request (say at the application controller level or in a before filter) and then apply a different layout based on the subdomain. That would give you a fair bit of flexibility for customisation.

Cheers

Adam

[Nicholas Faiz]

Are you just trying to allow a tenant to customize the look and feel?

In that case, you can store the layout in the database, and look it up in the controller via the user's account. 

Cheers,

Nicholas

[Dmytrii Nagirniak]

On 6 September 2011 16:01, Chris Berkhout <chrisb...@gmail.com> wrote:

Could you do the customisation entirely in CSS?

Sometimes, but not always. Some of the clients do have very specific presentation.

I can imagine doing CSS Garden on that, but it will probably be pretty tough.

 

If necessary, you could have the HTML contain a superset of what's
needed for individual versions of pages, then use CSS to show/hide
things appropriately.

That would greatly simplify it.

Yeah. That's another option. But I don't think I can predict what that superset be in the future.

[Dmytrii Nagirniak]

It is not difficult to extract the subdomain from the request (say at the application controller level or in a before filter) and then apply a different layout based on the subdomain. That would give you a fair bit of flexibility for customisation.

That's basically what I originally was proposing. But it feels dirty to me and wondering is there are better options.

[Dmytrii Nagirniak]

On 6 September 2011 16:09, Nicholas Faiz <nichol...@gmail.com> wrote:

Are you just trying to allow a tenant to customize the look and feel?

Maybe in the future, but not now. The client just tells/gives us what they want.

[Warren Seen]

It may or may not be the right approach for you, but we're beginning to use liquid templates for custom views per-subdomain in a multi-tenanted app. Maintaining a separate set of views for each subdomain doesn't scale well.

Check it out here: http://www.liquidmarkup.org/

[Eric Harrison]

You can prepend the view paths in the application controller based on the domain name.  This will give you the ability to have a "custom" folder for views on a per domain basis

-Eric

--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rails-oceania/-/rQwQ_U2OkcIJ.

[Dmytrii Nagirniak]

On 6 September 2011 16:17, Warren Seen <warre...@gmail.com> wrote:

It may or may not be the right approach for you, but we're beginning to use liquid templates for custom views per-subdomain in a multi-tenanted app. Maintaining a separate set of views for each subdomain doesn't scale well.

Check it out here: http://www.liquidmarkup.org/

That's another option. Never tried liquid before. How do you deal with assets?

[Warren Seen]

The simplest way IMO to set up a directory for each subdomain/account (under public/) to which the client can upload any css/image assets their template requires - or buckets on S3 if you're using heroku. If you start this way then it clears the way for you to allow clients to manage their own template assets later on down the track. 

As I said, we're really just beginning, and I'm sure there's more sophisticated ways we can manage this, but right now it's a case of doing the simplest thing that works - it helps that the templates are all for different identities for the same client, so they're not overly concerned with being able to share stylesheets/assets between templates, etc.

[Steve Hodgkiss]

Hi Dmytrii

I did something similar recently, but based on domain rather than
subdomain. Either way it's easy to add a load path that's based on the
domain, so views can be overridden on a per site basis.

# In application_controller.rb

# before_filter :set_theme on controllers that need customizing based
on domain
def set_theme
theme_path = "#{Rails.root}/app/views/themes/#{current_site.name}"
self.prepend_view_path(theme_path)
end

def current_site
@current_site ||= Site.find_by_domain(current_host) ||
Site.find_by_name("main") # Site is just a wrapper class around site
settings yaml
end

def current_host
request.env["HTTP_HOST"] || request.env["SERVER_NAME"] # Fall back
on the hostname/default site
end

To override a view, for example, create a view in themes/site_name/
home/show.html.erb

Include a stylesheet based on current_site.name for custom css.

Thanks
Steve

On Sep 6, 6:14 am, Dmytrii Nagirniak <dna...@gmail.com> wrote:
> Hi,
>
> I was wondering ones do customisations per client in a Rails app?
> Clients (businesses) do not want to bother with it and usually send their
> own "layout" and stuff. So we incorporate that into the app.
>
> More information:
>

>    - every client obtains a subdomain;
>    - subdomain might get some of the pages customised;
>    - when a client is on the main (www) subdomain, no customisation applies,

>    but same functionality is available;
>
> I was thinking about overriding the lookup mechanism for the views to have
> structure like:
> views/dashboards
> index.html.erb
> views/subdomain1/index,html.erb
>
> But don't like it much as it is not very flexible (especially for assets per
> client) and will get harder and harder to maintain and test.
>
> Have you done it before?
> Any recommendations?
>
> Cheers,

> Dmytrii Nagirniakhttp://ApproachE.com<http://www.ApproachE.com>

[Dmytrii Nagirniak]

On 6 September 2011 17:30, Warren Seen <warre...@gmail.com> wrote:

The simplest way IMO to set up a directory for each subdomain/account (under public/) to which the client can upload any css/image assets their template requires - or buckets on S3 if you're using heroku. If you start this way then it clears the way for you to allow clients to manage their own template assets later on down the track. 

That's the thing - the clients usually don't know anything about assets or similar. It should probably be hidden from them.

But in any case we can probably start thinking in that direction. Thanks for the pointers.

[Dmytrii Nagirniak]

I did something similar recently, but based on domain rather than
subdomain. Either way it's easy to add a load path that's based on the
domain, so views can be overridden on a per site basis.

Thanks. Useful piece of code :)

I think about similar approach but it feels a bit dirty as each clients look and feel is going to be under our source control.

Did you find it hard to manage many domains? Or you just had a fixed number of those?

Cheers.

[Steve Hodgkiss]

I have about 25 different domains on it. Not had any issues with the
number of domains, but they are part of the app and I don't expect
many more to be added, so it makes sense to store everything in
version control together.

Other options I can think of would be to manage the templates and
assets from an interface using liquid. Or if you want to have a deploy
per client you could engine the app and reference it with bundler from
a fresh rails app for each client.

[Warren Seen]

If you're spinning up a new instance for each client, it's not really multi-tenanted and this is the approach I'd suggest, but from the way Dmytrii described it (ie using subdomains), it doesn't sound like this is the way he's doing it?

[Steve Hodgkiss]

No it doesn't sound like Dmytrii want's a single instance per client,
but it was just a suggestion if he wanted to go that route for better
isolation/separation per client site. Obviously it's going to cost a
lot more for the amount of servers/RAM you're going to need for all
the Rails instances but it's an option. If there is going to be a
large number of clients I would think a multi-tenant approach would be
better.

Just my two-penneth.

[Dmytrii Nagirniak]

Deploy per client might also work, but each clients would have to share a lot of data.

Every client can interact with others.

It is just the branding that applies on client's subdomain.

So deploy per client would be possible as long as I can share the same data (DB and maybe FS) and at the same time isolate other (CMS kind of thing, brand some of the application pages).

I will summarise the options for now:

• separate views per client; customised by us; stored in source control;
• CSS based customisation; customised by us or client; stored in source control;
• Liquid templates driven; customised by clients; not in source control;
• deploy per client; customised by clients or us; (not?) in source control;

Thanks a lot everybody for the suggestions. I will see what I'll come up with.