Fog Creek Software
Discussion Board




Source of different versions of a web application

  I am working on the development and support of a web based application which consists of the following:
    - HTML and a lot of JavaScript.
    - ASP pages.
    - Some components in VB 6 and VC++.
    - MS SQL Server database containing functions and stored procedures.
    - Lots of metadata stored in multiple tables.

  This application has to be modified for each customer, which in most cases constitutes different HTML, JavaScript and metadata. However, for some clients certain changes might have to be done to table structure, stored procedures, functions and ASP pages. I am trying to keep a common core of pages and SPs which do not change, but there are already some differences in pretty basic functionality and it will be this way for a while.
  Differences might depend on each other. For instance a certain version of an ASP page might require a certain version of a stored procedure and is incompatible with other versions.
  Also, new functionality is being added to the application, certain parts are rewritten. There are going to be several versions of the application. Let's say that there are three versions: 2.1, 2.2 and 3.
  Client A might be working on 2.1, B on 2.2 and C on 3.
  At some point client A might have to be upgraded from version 2.1 to 2.2 or straight to 3.
  I would like to have some kind of source control which would allow me to:

    - Quickly extract all the files a certain version for a certain client.
    - Extract all the files changed between two versions (in order to upgrade from one version to another).
    - Have some mechanism like the C preprocessor with #ifdef which would allow me to store the slightly different version of a certain stored procedure in one file and then get the exact code for each specific client.

  I have considered VSS for as while but it does not seem to do a lot of this. Are there any source control systems which would help me automate most of the above? My platform is Windows but I can install cygwin if necessary.

http://www.alexlechuck.com

Alexander Chalucov
Friday, September 12, 2003

be quicker to throttle yourself with no 8 fencing wire now (a new zealand favorite) than try and maintain that site :)

FullNameRequired
Friday, September 12, 2003

Take the app out into the backyard. Shoot with pump action shotgun. Feed to the pigs, and then shoot the pigs just for good measure.

Once you start messing about with table structure, especially where you have metadata in those tables, I am not aware of any version control software that can help.

I would suggest that you should refactor your app. It might take a bit of work, but will make things easier in the future.

Look at the versions you have done. Keep a central core, which is cast in stone, and then build the customizations as modules around that.

For example, stuff like database abstraction, permissions engine, workflow engine, templates, version control etc can be part of the core. Everything else is an addon.

Client one might have news, with 3 defined areas, 1 text, 1 picture, 1 audio. Client two might have news, with unlimited areas which are defined on creation (more complicated table design). You might then call one news-lite and the other super-news.

As you iterate through the versions, you can tell a client news-lite 1.0 will only work with CoreApp 2.1.x ... If they want news-lite 2.0, they will need to upgrade to CoreApp3.x

Except they can't do that yet because they use chat2.0 which does not work with CoreApp3.x. Wait another month till chat2.1 is available, as this will work with CoreApp3.x

Every time you then create a custom version that involves changing the datastructure, or significant bits of the code, you are in essence creating a new app. You might end up with 4 or 5 discussion boards, or news modules, but given the differences it does not make sense at all to try and pretend that they are 1 app, and to try and maintain them as such.

Again, if you are smart about how you handle stuff like  permissions, workflow and version control within the core, and how you design the addons, you will find that changes for most clients will be cosmetic, once you have a few addons built.

Good luck, and do let me know if you still want to borrow that shotgun.

btw. look at openACS, they are trying to achieve something like this... http://openacs.org . Not doing too badly. Check out .LRN and .WRK specifically.

You might also want to take a look at phpwebsite http://phpwebsite.appstate.edu/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=5&MMN_position=17:13 .Unlike the *nukes, this one does not assume that you want to build a slashdot lookalike, and so everything that the user sees is a module.

I am not sure whether there is anyone doing somthing similar with ASP, but I hope you get the idea.

Tapiwa
Friday, September 12, 2003

I did. My approach was:

1) Create objects to do presentation (no embedded HTML)
2) Create a common "document model" for the site in XML, use XSLT to display (this can be very tedious, specially if you make changes to your core document model)
3) Create different "profiles" to instantiate at runtime the different elements of the "document" to show. Do this once per session, then cache it.

At the beginning of a design like this, things go very slow. You have to schedule ahead lots of time for design. Then you start implementing the core modules, which consumes a fair amount of time too; but once you have everything in-place, creating new stuff is quick and easy.

Leonardo Herrera
Friday, September 12, 2003

"Create a common "document model" for the site in XML, use XSLT to display (this can be very tedious, specially if you make changes to your core document model)"

I've never understood the advantage of using XSLT to display website content -- it's seems like a horribly complex extra step.

If you've already separated presentation from the business logic in your app then you've got a pretty light presentation layer.  What's the advantage of having that layer produce XML which is converted to HTML via XSLT over just having the presentation layer product HTML? 

Almost Anonymous
Friday, September 12, 2003

"If you've already separated presentation from the business logic in your app then you've got a pretty light presentation layer.  What's the advantage of having that layer produce XML which is converted to HTML via XSLT over just having the presentation layer product HTML? "

You can still do extra tweaking to the "final" document, thanks to the DOM. Plus, you can use XSLT to create different views from the same document: html, xhtml, different "skins", spreadsheets, PDFs, even XML documents for data exchange. Of course, you should ask yourself if you need any of this functionality; if not the case, then I agree it's quite overkill.

Leonardo Herrera
Friday, September 12, 2003

Is XML/XSLT is really that useful for generating "html, xhtml, different "skins", spreadsheets, PDFs, even XML documents for data exchange". 

I mean, if you're already generating XML from your presentation layer why not also generate everything else from there.  You have much better control over the output and you don't have to deal with yet another layer / language / tool.

Almost Anonymous
Friday, September 12, 2003

Visual SourceSafe is crap. Don't touch it with a ten-foot pole.

I can wholeheartedly recommend Subversion ( http://subversion.tigris.org/ ) for all your source control needs. It's very flexible, and should be able to accomodate for what you wish to do. It has a surrounding community and culture around it, and runs perfectly nicely on Windows.

Shlomi Fish
Sunday, September 14, 2003

"I mean, if you're already generating XML from your presentation layer why not also generate everything else from there.  You have much better control over the output and you don't have to deal with yet another layer / language / tool."

Because of the DOM. There aren't many technologies as flexible as the Document Object Model for manipulate tree-like structures (trees are a very intuitive representation of a document, once you "see" the tree) and you have a lot of tools to fool around, including storing and retrieving data. You can create your own way to represent the DOM, of course, but why bother?

Alas, I'm not defending using XML over any other method -in fact, in my current project I decided against it- but it can be a good choice in some scenarios.

Leonardo Herrera
Monday, September 15, 2003

When are you manipulating the document so much that you need the DOM? 

I our organization, the designers build all the HTML/graphics/etc and then it's just a matter of fill-in-blanks.  (The fill-in-blanks is easy enough with any server-side programming language: JSP, ASP, PHP).

(Now admittedly, it's more complicated than that but that's the general idea)

Almost Anonymous
Monday, September 15, 2003

*  Recent Topics

*  Fog Creek Home