I implemented this in Catalyst by modifying the View:TT path based on the contents of $c->request->uri->host(). I'm sure this isn't revolutionary, but for the sake of completeness and peer review ....
Here is a trimmed down version of my MyApp::Controller::Root::auto() sub auto : Private { my ($self, $c) = @_; my $hostMap = { 'foo.example.com' => [ 'foo/lib', 'foo/src' ] 'bar.example.com' => [ 'bar/lib', 'bar/src' ] }; my $server = $c->request->uri->host(); if (defined($hostMap->{$server})) { my $path = []; foreach my $elem (@{$hostMap->{$server}}) { push(@{$path}, $c->config->{root} . '/' . $elem); } $c->stash->{additional_template_paths} = $path; } ... } In addition I have a default set off assets. I set this up in MyApp::View:TT __PACKAGE__->config({ CATALYST_VAR => 'Catalyst', INCLUDE_PATH => [ QuickView->path_to('root', 'default/src'), QuickView->path_to('root', 'default/lib') ], PRE_PROCESS => 'config/main', WRAPPER => 'site/wrapper', ERROR => 'error.tt2', TIMER => 0 }); My resulting 'root' directory looks like: default/ foo/ bar/ static/ Where I did my main template development in 'default' and then each time I need to rebrand the site I copy a subset of 'default' into the a new directory, and make the changes to those. The one area I still struggle with is 'static' Being that the static data is being served via the main web server, I have to have 'virtual servers' setup for each site and a superset of the static content in each. If anyone has figured out a more gracefully way of handling static content I would be interested in hearing how. On Thu, Jan 24, 2008 at 09:46:57AM -0000, Carl Johnstone wrote: > > >Interesting term, 'white labelling'; where do you get it from. > > It's a fairly standard term for the process. One origin I've come across is > it comes from manufacturers selling products with plain white labels to > supermarkets, who would then brand them as own-brand products. However > these days it applies in all industries where such practices are common, > for example white-label credit cards are common. > > Good web examples would be LOVEFiLM ( www.lovefilm.com ) providing a DVD > rental service under several other brands :- > > http://www.tescodvdrental.com/ > http://dvd.easycinema.com/ > http://www.odeondirect.com/ > > > >A client wants something similar so I am interested in the issue. The > >sites > >will have some differences such as CSS but access the same application. > > If you can get it just down to CSS changes, you could probably just put a > conditional in where you load the CSS files (testing the hostname used to > access the site). > > It's likely that sooner or later though you're going to need actual > template changes, in which case you could just use an alternate view in > Catalyst pointing to a separate set of templates. You probably want to > experiment a little as it depends where you want the balance between > separate and common stuff. Too much common stuff and it gets harder to > customise the look and feel for a client to what they'd like. Too much > separation means more maintenance work when improving your application. > > Carl > > > _______________________________________________ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ -- James R. Leu [EMAIL PROTECTED]
pgpQ9ZLPBNm9t.pgp
Description: PGP signature
_______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/