I've talked before about the profile as being a linchpin feature in Notes, and everyone uses either profiles or configuration docs. These start applications on the road to being configurable. For ease of use let me talk about both as "profiles", even though they're not named the same in Notes.
Profiles allow admins -- not just developers -- to enter information about the application's setup and surroundings. The application is told "how to work" and "what it's working with". As a result, the profile classically includes checkbox / radio / dialog lists of features you can turn on & off, Web service information, other Notes application file paths and server names, and views to retrieve information the application deems relevant. It'll also contain static selection lists, email addresses the app will communicate with, maybe even some constants and limits.
There're ways to organize this data though, to make it even more flexible.
Take views, for instance. If you're working with a view, and searching that view, you've implicitly decided that view has to be sorted a certain way, containing a certain organization.
What if it wasn't quite what you expected? Maybe the customer wants to refine this a bit. They forgot something they wanted to search with.
The search key for the view is really important to get profiled. And you can do it: with a formula. Again, this is not a formula *field* in Notes. It's a text field that holds a formula.
It takes more tooling to make sure the formula is right: @CheckFormulaSyntax factors prominently in saving the key formula field.
What if a view won't find the proper data? You may need to expand some agents so they can perform @DbSearch when no view would do. That is, when the profile has no view specified.
So what've we got profiled for each view?
Profiles allow admins -- not just developers -- to enter information about the application's setup and surroundings. The application is told "how to work" and "what it's working with". As a result, the profile classically includes checkbox / radio / dialog lists of features you can turn on & off, Web service information, other Notes application file paths and server names, and views to retrieve information the application deems relevant. It'll also contain static selection lists, email addresses the app will communicate with, maybe even some constants and limits.
There're ways to organize this data though, to make it even more flexible.
Take views, for instance. If you're working with a view, and searching that view, you've implicitly decided that view has to be sorted a certain way, containing a certain organization.
What if it wasn't quite what you expected? Maybe the customer wants to refine this a bit. They forgot something they wanted to search with.
The search key for the view is really important to get profiled. And you can do it: with a formula. Again, this is not a formula *field* in Notes. It's a text field that holds a formula.
It takes more tooling to make sure the formula is right: @CheckFormulaSyntax factors prominently in saving the key formula field.
What if a view won't find the proper data? You may need to expand some agents so they can perform @DbSearch when no view would do. That is, when the profile has no view specified.
So what've we got profiled for each view?
- Server & database, if the view isn't contained in the current app.
- View name.
- Key formula.
- If a selection list for a dialog box, field names or column numbers.