The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

How to update an app without breaking customizations

My company has a web app which is partially written in ASP. Now, because the user interface is in ASP, it can be customized to exactly match the customer's web site. A lot of our customers have done that, and it's become one of our major selling points.

The problem now is that we sometimes have to change the ASP code when we release an update (for example, to add a new feature to the user interface). When we do that, all of the customers who made changes have to manually update their customized pages. They don't like doing that. (-:

We already have header/footer includes and central stylesheets, but most of our customers want more control than just changing the color scheme or header. So, they want to edit the "core" pages.

Has anyone come up with a good way to solve this?
Friday, December 16, 2005
Yes.  Separate code from presentation.  For a PHP approach, take a look at Smarty.
Chris in Edmonton Send private email
Friday, December 16, 2005
Hmmm... many products claim to separate code from presentation but I have yet to see any that really do. The initial response to your question would be that ASP.NET helps "solve" this problem using code behind files that separate business logic from presentation. It all sounds great in theory but there are definitely cases where you will not be able to make changes that won't require your customers to modify their files. Here are some common examples using the ASP.NET model.

1) Change a business calculation (tax rate calculation change for example) - this is done in the code behind file so the customer does not need to modify their version of the page. No presentation elements have been changed.

2) Add a new textbox field to the page with associated business rules -  The customer will have to modify their version of the page to get the textbox. There is no other way around it. If they don't actually want the textbox to show then they may be able to use their existing page with your new codebehind file but there could be problems depending on how you coded it.

There is simply no "cure all" for this problem. However, technologies ASP.NET and architectures that are similar to a code behind model help quite a bit.
Turtle Rustler
Friday, December 16, 2005
First of all, are you talking about classic ASP or ASP.NET?

I'm going to assume you mean classic ASP.  One approach is to create an area of each page, marked off by comments, that the client can use to add their own stuff and that your updates will never affect.  It's good also to give the client a naming convention for variables and functions such that yours will never conflict -- say, they have to start all variable and function names with "xx_" or some such.

Now you need a smart update tool that will parse their current files and add all of their customizations to your new pages.
Jacob Send private email
Friday, December 16, 2005
You can do "codebehind" with classic ASP too.  I did it for years and loved it (in some ways it is actually more flexible than ASP.NET)

Anyway, get the VBSTemplate class from here:

And see what shakes loose.
Sassy Send private email
Friday, December 16, 2005
Yeah, it's classic ASP. I think Turtle Rustler is right, using codebehinds would help, but it wouldn't solve the problem.

I like the idea of a "smart update tool". I'll have to do some research on that. Thanks, Jacob!
Friday, December 16, 2005
My first piece of advice would be not to allow per-customer changes.  Been there, done that, got the arrows in the back.

But, should the sales department drink too much Absinthe and decide to do it anyway, you do as the others suggest and remove anything remotely resembling business logic from the ASP pages and put it in their own DLLs.  You then treat that set of DLLs as an API, and promise not to change it for the current major release (1.x, 2.x, etc).  When you do go to a new major release, you need to give the customer developers time to migrate their custom pages to the new API, so you need an extended beta period where they can get used to the new way of doing things.

In order to prevent unpleasant surprises, you need a company policy that explains this, and everyone needs to know it.  Communications in advance is key.

Sure, the customers will complain about having to change their code, but if they want the new features, it'll cause some pain, and there's no getting around it.
example Send private email
Friday, December 16, 2005
This is somewhat dependant on the nature of the application and the changes the customer makes, but is there any possibility of making the application data dictionary driven? The idea is you have a set of meta-info in the database that describes what data the application needs and how it should be rendered. If you add a new column to a database table and want it to appear in the UI you simply add the appropriate meta-info.

This approach isn't suited for all applications and certainly won't handle all customizations done by customers but it could potentially reduce it to a manageable amount. I've seen applications that require a high degree of customization use this approach and it works surprisingly well in the right context.
Gerald Send private email
Friday, December 23, 2005
Also consider a smart use of CSS in the html layout. The vast mayority of customization can be archieve changing a single css file, like font size, colors, effects, included logos.

Is not necesary go for a absolute CSS desing but is very easy to get something good in short time..
Mario Alejandro M. Send private email
Monday, December 26, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz