views:

856

answers:

3

I have Lotus Notes application, deployed only as modifications (new forms, views, and adding a button to one of the "standard" views) in the main mail template (R7).

All these "new" forms and views are inherited in turn from my main application template.

Now, for one of these forms to function properly, it have to have a field, which is different from customer (not end user, but organization) to customer.

I do not want to break the inheritance from our template, so we can update the application easily by just sending a new template. So, I can't ask the client admin just to break the inheritance for this particular form, as it will stop all updates (or they have to be done manually).

So, let's say I have MainAppForm, which has a calculated field ClientCustomData. I'd like to have another form, which only has only one "default" field ClientCustomData. I can break the inheritance for this second form, as it has no really design elements which may change, and then the client can modify this default value to whatever they need w/o fearing that it'll be overwritten.

The question is - how from MainAppForm I can read the value from the other form?

Or - is there a way to store 2 data elements only in a mail template (I dunno, shared file, or something), so it becomes available to each user, and MainAppForm can get them, w/o a need to remove the inheritance dependency of MainAppForm from our template.

I can envision even a class library with just to functions to return this (I don't know why this approach smells to me).

Any best practices or advices?

+1  A: 

First a clarification: In Lotus Notes, you don't have forms reading from other forms. Forms are just UI objects. However, you do have back-end and front-end documents that get created with the help of Forms.

When you create a new document based on a form (for instance, a new email), you are creating a front-end document that hasn't been saved yet. That document can access other parts of itself or it can access any back-end document that has been saved.

If I'm following you correctly, you need some bit of data that is different per client/customer to be brought into documents based on MainAppForm. There are a few ways to do that. My suggestion is to use Database Profiles, which are special documents that can easily be accessed from anywhere in your database via Notes Formula language or LotusScript. Granted, you can't push data within those documents out via a template, but if you use a database profile to store your database settings your client admin can set options once and they won't get altered when the template changes.

Have a look at the @SetProfileField and @GetProfileField functions.

Ken Pespisa
I'm new to Lotus, and still getting used to its terminology, so maybe I did not make myself clear. Can you elaborate a little bit more about the profile docs - looks like they are per database. All the changes I push are trough the mail template (R7), thus ending in the user's mail database. How is it possible for the admin to push that data to all users? The data is needed before any client document exists in their database, actually, my form will be responsible to create/modify it based on that data.
Sunny
I wasn't clear on the scope, but I see your point. I see the concern isn't one database per client, but one template per client, and any number of databases based on those templates. Yes, for that profile documents would not be a good option
Ken Pespisa
+1  A: 

To answer my own question (still I do not know if I'm right in terms of Notes way of thinking, but looks promising):

I found the "Shared fields". So, I create 2 such a fields with a computed values (the ones I want to pass on), and make my MainAppForm use them. Upon installation, the admin will change the values and mark them to not refresh with the template.

I'd respect any pros and cons, provided from a Notes expert.

Thanks

Sunny
Shared Fields are a good way to go. You could also use a subform and put that subform within the MainAppForm. You could also use a LotusScript script library, but that's a bit more involved.
Ken Pespisa
+2  A: 

I'm not sure if I have understood your querstion correctly, but it sounds like you want to have a small part of a larger form configurable per client. If this is the case, I think computed subforms could do the trick.

Consider the following scenario: Your application ships with the subform ClientCustomData that contains just sensible defaults for the client settings. The form MainAppForm includes this as a computed subform. It is then possible for the local admin to disable inheritance on the subform and changing the custom data without affecting inheritance on MainAppForm.

The obvious drawback is that you cannot update the ClientCustomData subform automatically once inheritance is disabled; Keep this subform as small as possible. If you find that you need more client-custom values, you can always add another subform in the same manner.

Anders Lindahl
I went with the Shared Fields approach for now, but looks like the subform solution is more "compact", so I'll keep this in mind for the next release. Thanks.
Sunny