Actually, you can take this one step further. I hate having to change code and
your idea of a centralized database is great. What I have done is created two
databases. One contains documents for CSS, Javascript, etc. where the key is
the name of the file (ie: common.js, mystyle.css, etc). You can setup a view
to pull in the unique key from anywhere in Domino. The second database is used
for any dynamic data thus instead of a Replica ID, you could have a document
that contains the name of the global db (testarea/global.nsf). Profiles are
great except they are stored in each database thus is something changes, you
have to update all of them. There is also the chance that if you allow editing
of the profile on the web, the changes will not be reflected for the current
user (cache issue). I have used this technique for every Domino project and it
has worked out well. I store all the databases in the system in the second
database along with a host of other things that could be altered (error
messages, form titles, and the list goes on). This allows a central place for
all data that could change. You could merge both of these databases into one
but I did not for various reasons (too long to discuss here) but there is no
technical reason unless it could become a bottleneck. I am glad to see this
type of article/tip posted here. Separating any pieces of data that could
possibly changed from the code is a wonderful thing as it removes the
requirement of a programming change just for a simple message or CSS change.
Actually, you can take this one step further. I hate having to change code and your idea of a centralized database is great. What I have done is created two databases. One contains documents for CSS, Javascript, etc. where the key is the name of the file (ie: common.js, mystyle.css, etc). You can setup a view to pull in the unique key from anywhere in Domino. The second database is used for any dynamic data thus instead of a Replica ID, you could have a document that contains the name of the global db (testarea/global.nsf). Profiles are great except they are stored in each database thus is something changes, you have to update all of them. There is also the chance that if you allow editing of the profile on the web, the changes will not be reflected for the current user (cache issue). I have used this technique for every Domino project and it has worked out well. I store all the databases in the system in the second database along with a host of other things that could be altered (error messages, form titles, and the list goes on). This allows a central place for all data that could change. You could merge both of these databases into one but I did not for various reasons (too long to discuss here) but there is no technical reason unless it could become a bottleneck. I am glad to see this type of article/tip posted here. Separating any pieces of data that could possibly changed from the code is a wonderful thing as it removes the requirement of a programming change just for a simple message or CSS change.