I think going down the path of implementing customer specific layouts
and templates is going to cause you maintenance problems down the track.
I guess the method you use will depend on what the changes will be
between the customers.
The suggestion of using CSS is a good one. The skinning service can be
used to provide a different CSS file and associated resources (you need
to store the skin to use against your customer record).
You can also include options in your skin configuration and use these in
your layouts and templates to conditionally include blocks of content -
this can be used to cater for instances where it is more than just a
style change that CSS can handle.
You can also mix and match - in your skin file you could provide a
template qualifier thus:
- Skins:
- common_skin (customers get this one by default)
- screen_x_prefix = "base"
- screen_y_prefix = "base"
- cust_1_skin (a specific skin for a specific customer)
- screen_x_prefix = "cust_1"
- screen_y_prefix = "base" (screen_x is customised for this
customer, but not screen_y)
- variation_x_skin (a few customers might have this one)
- screen_x_prefix = "variation_1"
- screen_y_prefix = "base"
I also:
- define skin inclusions against my customers - e.g. on the customer
record I specify a logo url that can then be used in a skin so that it
is customised for each customer
- make user of localization within my skin files - thus requiring two
lookups to resolve a string for presentation to the user (the skin file
provides a localization key that I then resolve to get the string to
display)
- provide customer specific login urls that allow me to determine the
skin to use for the login page (i.e. before I am otherwise able to
determine the customer)
HTH,
Scott
David Demner wrote:
There's a site called CSS Zen Garden (http://www.csszengarden.com/) that
implies that you can do just about everything formatting- or layout-wise in
CSS. Then you skin a CSS per customer and bingo.
I've never done this but conceptually it's really cool ;)
David
-----Original Message-----
From: Alexander Zimmer [mailto:[EMAIL PROTECTED]
Sent: October-17-07 1:17 AM
To: [email protected]
Subject: separate template sets for different customers: how?
Hello list,
I am trying to modularize an existing turbine 2.3.2 app. The app should
be shipped to several customers, each with a distinct layout. But - how?
As far as I can see, the skin mechanism is not enough because I can only
"skin-ize" images, colors etc. Instead, what I want to do is to
implement completely different layout sets having customer specific
appearance beyond just replacing images: e.g. using a table layout for
one customer and using sophisticated <div> elements for the other.
My first idea was: put each customer layout set in different subdirs of
the templates/app/* directories, e.g:
templates
app
layouts
default
customer1
customer2
navigations
default
customer1
customer2
screens
default
customer1
customer2
Now each time I use a reference to a template file, I have to "qualify"
it using the customer directory prefix. E.g.:
customerDir = "customer1"; // this would be in fact a global setting
rundata.setScreenTemplate(customerDir + "," + "Orders.vm");
To be able to qualify template links in my .vm files, I would implement
a pull tool (here named $tpl):
<a href='$link.setPage($tpl.qualify("Orders.vm"))'>Orders</a>
Do you think this is the right, Turbine-friendly way to tackle the
problem? Or am I missing something and there is a better way?
TIA,
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
