How would you attack this programming strategy?

[laredotornado@zipmail.com]

Hi,

I'm using PHP 4.4.4 with Apache 2.2 on LInux. I have been building a
web site, and now a client wants that same site, only he wants all the
graphics substituted with his own. There could potentially be more
clients who want the same site but with custom graphics. What makes
more sense?

1. Maintain a single code base, only have "if/else" blocks when it
comes to "<img src ...>" tags?
2. Maintain two separate code bases except the images directory would
be different for each client (not sure how updating my code would
work, if I'd have to copy the same PHP files to multiple sites).
3. Some other strategy?

Curious how you would approach this or what you have done if in a
similar situation.

- Dave

[BJMurphy]

Re: How would you attack this programming strategy?

On May 24, 4:09 pm, "laredotorn...@ zipmail.com"
<laredotorn...@ zipmail.comwrot e:

Hi,
>
I'm using PHP 4.4.4 with Apache 2.2 on LInux. I have been building a
web site, and now a client wants that same site, only he wants all the
graphics substituted with his own. There could potentially be more
clients who want the same site but with custom graphics. What makes
more sense?
>
1. Maintain a single code base, only have "if/else" blocks when it
comes to "<img src ...>" tags?
2. Maintain two separate code bases except the images directory would
be different for each client (not sure how updating my code would
work, if I'd have to copy the same PHP files to multiple sites).
3. Some other strategy?
>
Curious how you would approach this or what you have done if in a
similar situation.
>
- Dave

Personally, I would keep one code base if at all possible. I would set
a variable at some point for the images directory, and maintain
parallel sets of images for each client. Then every <imgtag would
just have the variable as part of the src path.

[apaezp]

Re: How would you attack this programming strategy?

An option which will generate some overhead but which opens up
countless possibilites is to use PHP as an image pre-processor (using
GD library routines).
In this way, the src could always be the same. Something like
src='getImage.p hp?id=header'. The getImage.php script would know which
image to serve.
There are many advantages to this pre-processing: you can resize
images before sending, type on top of images using specific fonts,
make the image content dynamic, etc.
To avoid processing time, I usually save pre-generated images to a
cache folder to served them quickly later on.

[ZeldorBlat]

Re: How would you attack this programming strategy?

On May 24, 4:22 pm, BJMurphy <murphy....@gma il.comwrote:

On May 24, 4:09 pm, "laredotorn...@ zipmail.com"
>
>
>
<laredotorn...@ zipmail.comwrot e:

Hi,

>

I'm using PHP 4.4.4 with Apache 2.2 on LInux. I have been building a
web site, and now a client wants that same site, only he wants all the
graphics substituted with his own. There could potentially be more
clients who want the same site but with custom graphics. What makes
more sense?

>

1. Maintain a single code base, only have "if/else" blocks when it
comes to "<img src ...>" tags?
2. Maintain two separate code bases except the images directory would
be different for each client (not sure how updating my code would
work, if I'd have to copy the same PHP files to multiple sites).
3. Some other strategy?

>

Curious how you would approach this or what you have done if in a
similar situation.

>

- Dave

>
Personally, I would keep one code base if at all possible. I would set
a variable at some point for the images directory, and maintain
parallel sets of images for each client. Then every <imgtag would
just have the variable as part of the src path.

I would definitely just have a different directory for each customer's
images. You can even leave your code unchanged and use the "Alias"
directive in Apache's configuration to choose a different directory
for each virtual host (assuming each client had a different vhost).

For example. suppose all your <imgtags looked something like this:

<img src="/images/foo.gif">

Then, in httpd.conf under the vhost for client1, you might have:

Alias /images /path_to_web_fil es/client1_images

And under the vhost for client2, you would have:

Alias /images /path_to_web_fil es/client2_images

So, depending on which vhost is being used /images would point to a
different physical directory.

[=?ISO-8859-1?Q?Oliver_Gr=E4tz?=]

Re: How would you attack this programming strategy?

laredotornado@z ipmail.com schrieb:

I'm using PHP 4.4.4 with Apache 2.2 on LInux. I have been building a
web site, and now a client wants that same site, only he wants all the
graphics substituted with his own. There could potentially be more
clients who want the same site but with custom graphics. What makes
more sense?
>
1. Maintain a single code base, only have "if/else" blocks when it
comes to "<img src ...>" tags?
2. Maintain two separate code bases except the images directory would
be different for each client (not sure how updating my code would
work, if I'd have to copy the same PHP files to multiple sites).
3. Some other strategy?

If you have full control over the server: 3. !
I'd use Subversion for the codebase: Use the trunk for your development
and branches for the deployed sites. The branches remain stable and if
you feel that a particular site needs some of the improvements you can
merge the changes onto that branch.

And I'd keep the graphics out of version control.

OLLi

--
"I can't talk to you right now, OK. I'm having sex with a white woman."
[L.A. Crash]

[Joe Scylla]

Re: How would you attack this programming strategy?

Oliver Grätz wrote:

laredotornado@z ipmail.com schrieb:

>I'm using PHP 4.4.4 with Apache 2.2 on LInux. I have been building a
>web site, and now a client wants that same site, only he wants all the
>graphics substituted with his own. There could potentially be more
>clients who want the same site but with custom graphics. What makes
>more sense?
>>
>1. Maintain a single code base, only have "if/else" blocks when it
>comes to "<img src ...>" tags?
>2. Maintain two separate code bases except the images directory would
>be different for each client (not sure how updating my code would
>work, if I'd have to copy the same PHP files to multiple sites).
>3. Some other strategy?

>
If you have full control over the server: 3. !
I'd use Subversion for the codebase: Use the trunk for your development
and branches for the deployed sites. The branches remain stable and if
you feel that a particular site needs some of the improvements you can
merge the changes onto that branch.
>
And I'd keep the graphics out of version control.
>
OLLi
>

I'm using the same strategy. Using subversion as version control and
creating branches from the mainline i develop. Also because every
customer have some special wishes so the codebase differs every time.