Max Tomlinson wrote:We have clients who do not use a document directory on a web sever. All files, including client unique files such as logo, css, help pages etc, require a separate build. Obviously not good.
Perhaps I am misunderstanding the situation, but I disagree. This is not not good.
Changes to a web application should trigger a new build cycle -- it should also trigger a new QA cycle as well. It sounds as if you think it's ok to just make changes to a running web application without a build or test cycle. To me, that's what is obviously not good.
The files in question are files we typically load for each client but which use a common web app build: e.g. css, client logo, other images - and is some cases simple html files (which are called via help links). These are static content as far as the app is concerned and for most clients we keep them in the htdocs directory so they can loaded\modified them as needed. As far as the app is concerned they are all the same. This is a pretty common approach, I think.
We are now running into the situation where certain clients do not expose or do not have an external htdocs directory for this kind of static content. The short term solution has been to generate a separate build for these clients to pick up separate content. What would be better is to have, for example, a logo.gif file stored in the db and pick this up at startup, store the byte array into the application context, render it via a servlet call (we do this for dynamic files e.g. charts generated on the fly where we cannot get to a working directory on the server). Now I'm wondering if this approach can be applied to all static files (css etc) and render them in a similar way. In terms of applying css etc. it could get tricky and I wondered if there is an approach/framework someone has used for this.