On Tuesday 26 March 2002 09:40 am, dennis@... wrote:
> On Wed, 20 Mar 2002, Love, Jay wrote:
> > PSP can do it, but I'd probably need to tweak some things. There
> > is a command line interface to PSP already. We'd just need to set
> > it up so it could be used as a module.
> How much work would this be? I seem to be banging my head against a
> problem that this approach would solve.
> I need to have different html for each domain and I want to avoid
> hard coding html into python code. As the designer creates new sets
> of html files, I need to incorporate them into my app for the new
> So I want to be able to make as few changes to his html as possible.
> As it stands now I am copying his html files to .psp files and adding
> tags in. I don't want to have any logic in the psp files because I
> would be duplicating the logic in each set of psp files.
> Currently I have an index.psp file that contains some of the logic. I
> make decisions based on form input, etc and then do a:
> self.application().includeURL(self.transaction(), page)
In your situation, your HTML/text varies, but your logic is the same. I
don't know that templating languages like PSP and Cheetah are well
suited for that. Here's an approach that could work for you:
- Write Python servlets (*.py) for all your pages.
- Invoke self.writeFragment() to get the correct HTML peices.
def self.writeFragment(self, name):
def fragment(self, name):
path = self.pathToFragments()
filename = os.path.join(path, name)+'.htmlf'
- pathToFragments() figures out via self.request().fields() and/or
self.request().environ() and/or self.request().cookies() what the path
for HTML fragments is.
- Do some type of caching in fragment() to reduce the number of open()s
and increase performance.
- Implement "fragment inheritance" where if the fragment can't be found
in "/web/fragments/brandX/frag.htmlf" then it is taken from
"/web/fragements/default/frag.htmlf". That way you only override the
parts you need.
- Use a similar technique for the stylesheet and graphics as well.
- A more ambitious fragment inheritance approach would read a "parents"
file in a fragment directory to determine who the parents of the theme
were. (Save that for version 3.)
Once you set this up, you have very little to do to create new brands:
make a new brand directory, override those parts that must change and
tweak your config to "enable" the brand on the site.
I already use the fragment() approach myself, I just never set up
multiple directories for it, but that wouldn't be hard.