Re: Branding/Skinning approaches
Re: Branding/Skinning approaches
- Subject: Re: Branding/Skinning approaches
- From: Paul Lynch <email@hidden>
- Date: Wed, 20 Sep 2006 17:02:55 +0100
On 20 Sep 2006, at 14:50, Kieran Kelleher wrote:
Just trying to decide how to best approach "skinning" on an app for
wholesale resellers of our services. Our primary caveat that needs
to be taken into account is that we use SSL https pages primarily
throughout the app.
I am thinking that the fastest approach is to create a direct
action with a reseller param for the main entry point of the app
and push the associated skin object into the Session. Basically I
would be abandoning any hope of using sessionless pages then of
which I only have a few for the prevention of sessions for non-
logged in users. Then I can just use "cloaking" (frame the whole
page) on the reseller's domain name to hide my URL.
The probably better longer term approach is to get an SSL
certificate that is tied to my IP address instead of my domain name
so that all the reseller domain names point to my IP and I just use
the incoming request host name to determine which skin (basically
CSS and page brand banner) to use.
No real gotchas that I can think of.
I have done this several times, a couple of different ways.
Number one was to take in the reseller code in a direct action, and
set a session variable based on this, then have a component my page
wrapper that included html from the reseller site that topped and
tailed the page. Nowadays, this could more reasonably be done with a
CSS include, but the general principle applies. If I wanted to be
sessionless, I don't see why you couldn't pass a parameter in links,
or set a cookie (the latter would be simpler if you have an existing
code base).
Second way was to override Application.pageWithName, check a
Property, and translate to the appropriate page component
accordingly. This system uses a separate app in JavaMonitor for each
client, but could be adapted to be dynamic (and sessionless).
Paul
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden