App settings: profile doc vs. constants vs.?

HCL Domino Domino Forum
1

I want to get the sage battle-tested advice of the development community about where best to store application-wide settings. I know this has been discussed many times before, (such as here: http://www-10.lotus.com/ldd/bpmpblog.nsf/dx/upsndowns?opendocument ) but I’m having trouble choosing the best option for my particular environment.

The scenario: I’m reworking four Domino applications to handle a changed corporate AD/LDAP schema. At present, the applications have lots of hard-coded references to LDAP DNs, and also to Domino server names, file paths, URLs, support e-mail addresses. All the applications have separate instances for development, test and production, inheriting from the same template, but running on different Domino 5.0.12 Wintel servers. (Yes, I know this is the 6/7 forum, but there’s only tumbleweed in the Domino R5 forum.) All client access, apart from occasional admin work, is via IE browsers.

The applications use a wide variety of code, and these hard-coded settings appear (in decreasing frequency) in LotusScript, Formula Language, Java, and JavaScript contexts.

The plan so far: This seemed like a good place for a profile document. The settings change only occasionally, they’re not user-specific, and when the company next needs to change them it would be good if this didn’t require a Domino developer to spend two weeks scanning the code for references and dependencies.

Some settings are the same across the four applications. Many others are similar (such as database file names) but each application instance would have its own setting. And a few are truly unique to a particular app.

My doubts: Taking these settings out of the code and putting them into data has its downside. They don’t get transferred with design updates, so while all the instances of a particular application can inherit the same settings, I would still need to maintain separate profiles for dev, test, prodn, etc. Also, if the profile were corrupted or removed, much of the application code would stop working.

This started me thinking that database-wide constants might be a better route, because they’re part of the design. But then that would require Designer access (and developer know-how) to modify them, and would be specific to one development language.

And I guess I could take this further and place the constants in an .lss file, which would mean the applications could share common settings, but then this would be tied to particular servers and add a risk of losing the .lss file during server rebuilds, etc.

This was where I started thinking that someone else must have come up with best practise for this scenario already.

So, where’s the best place for my settings, and does anyone see pros and cons for the various approaches beyond what I’ve worked out already?

Rupert Clayton

Chicago

2

Subject: App settings: profile doc vs. constants vs. ???

An alternative you did not mention is to have a (single) separate database with all the definitions and references stored in it. This means that every application needs only to refer to that single database to get the common values. In this database you could define lists of keywords too.

I know of systems where you can populate the referenced applications with this data from the central db. So you only enter the central info at a single place and when changed all the databases that need this info will be pushed with it.

3

Subject: RE: App settings: profile doc vs. constants vs. ???

Yes, a central settings database would make good sense in a lot of circumstances. I can particularly see the attraction of building this in early in the development process, and this has been used in other environments I’ve previously worked in.

I think that in my current environment the benefits of a central database are outweighed by the drawbacks. Configuring the LDAP directory server or base DN centrally would limit the flexibility to update applications individually, which means changes have global impact and higher risk. And many settings are similar, but not exactly the same, across databases.

I guess a couple of days of thinking about it has let me answer my own question: The best trade-off of development time for eventual benefit is to place the profile in each application instance, and accept the small future overhead of making multiple changes. It’s still a lot easier than finding every hard-coded server or URL reference and working out the knock-on effects each time round.

Thanks,

Rupert Clayton