I am trying to simplify an existing Notes Form in an application that I am converting to XPages. The Notes Form has over 240 fields on it and a bunch of logic that I want to clean up. Plus the form has all kinds of display formatting that makes viewing it complex. So what I have been trying to write an agent that will get FormA and cycle through all the fields and copy them to FormB. I will then use FormB to bind my XPage to and trying to track down data issues will be much simpler. If the FormA didn't have so many fields I would just recreate it manually, but I'm sure with over 240 fields I would introduce some new typo errors.
You don't need to do anything with your form in order to create a XPage layout for it.
XPAges don't need a form at all, although it makes development easier, as after creating the data binding all fields from the form are available and can be dragged and dropped to the Xpage. Fields that are not on the form have to be created manually in the source code of the xpage (e.g. copy and paste an existing one and change the binding/name)
If you want to clean up your documents, an agent can do this without even touching the form.
For this task please consider the difference between a "Form" and a "Document".
A form is a design element that defines the look and feel of a document.
Forms contain fields that define what type of data you can put in your documents.
A document is a stupid "container" for items (not fields). It contains items for any field on the form that existed in the form when the document was created / last saved. PLUS items that are created any other way (e.g. Using formula or lotusscript agents) or that have been on the form in an earlier stage of development.
If you remove a field from a form, it will NOT be removed from the corresponding documents, not even by saving them. But If you add a field to a form, the document will have an item for that field after saving (forever, if you don't remove it manually using an agent).
With this knowledge you can simply create a new, "cleaner" form with the same name as the old one and rename the old one. From this time on, document will be displayed with the new Form and you can develop your XPage using it as your data source.
If you need to accumulate the data in the documents, this can be done with an agent without using a form: just manipulate the document DIRECTLY.
Here is an example in formula to put two fields together:
FIELD NewFieldName := OldField_1 : OldField_2;
FIELD OldField_1 := #DeleteField;
FIELD OldField_2 := #DeleteField;
I think, in most cases it's not a good idea to have a form with 240 fields. It looks for me like a form from old Notes 3 or 4 times when no embedded views were available and one to many relations were put into fields with index e.g. 1 to 20.
Maybe, a redesign is a better way to go.
Also, you don't need to create and maintain a form with all 240 fields for developing your XPage. Actually, you don't need the form at all. With a data source definition based on "Domino Document" you define a form name and which way you want to create a new document or find an existing document. That's it. Then you can create your fields in your XPage. Give them a name and a type. You can do this in Designer UI. Just write the new fieldname into "Bind to" for selected "Data source". Select in "Display type" a field type (String, Number, Date/Time). That is not only valid for display but will save the field as selected type to document too. In this example it will create a new field "YourNewField" and will save it as a integer number.
When you submit the page all fields will be created or set in document. You can check the fields and their types in Notes client using the document property box.
A good way though is to create the form with the most important fields. Then you can open the document in Notes client and check the fields set by XPage.
Related
My view is one application and a required form along with few fields are in different application.
Point one: A View's selection formula does not "select a form". It selects documents. These documents are (usually) created with a Form, and they (usually) contain an item called "Form" which contains the name of the Form that they were created with. So a selection formula SELECT Form = "Foo" means that the view will show all documents with an item named Form that contains the value "Foo".
Point two: A View can only select documents that are in the same database that contains the View. It cannot select documents that exist in another database.
Ergo, there is no possible forumla that selects documents in another database that were created with a given Form.
I'm assuming you probably have some keyword documents in a different database, and you'd like to use a key in the main document to pull some matching information from the keyword database. In other words, you'd like to do a "join" in your Notes view.
You can't do this, never mind whether the documents are in the same database. This is not a relational database.
There are options, however.
You could create a "user definable" column and automatically update the column formula in a profile document so that the formula can calculate the keyword correspondences. You would have a periodic agent look at the keyword database and construct an updated formula such as, #Select("a"; "b"; "c";...; ChoiceNo) to convert the number field ChoiceNo to the value "a" (for 1), "b" (for 2), etc. If you can write a formula to display the correct values for the current keywords, this is workable provided the list never gets too long.
Domino servers are capable of accessing a DB2 relational database to construct a view index, using a feature called DB2NSF. So you can actually do a join -- but your NSF data has to be stored in DB2 as its back-end, rather than beinf stored in the NSF, for this to work. This is probably going to be more work than it's worth to you for this application.
If it is an XPages application, you can create your own data set however you like for feeding to a repeat control.
Is there a way to force a documents computed fields to recalculate from within an Xpage, without saving the document?
I have a subform on a Notes database with many computed fields, these contain some complex calculations involving time range calculations. The database is used as both a web and client application. For the custom control containing the fields I don't want to have to recreate all the calculations, so have a computed text value bound to the computed form on the document.
On the subform as you tab through entering the information the computed fields are recalculated. On the custom control I have a refresh button which saves the datasource and does a partial refresh of the data entry section, but this can cause some errors or document save conflicts.
I will recreate the calculations if need be, but I just wondered if there is a slicker way of achieving this before I start that process?
DominoDocumentData object has computeDocument() and doComputeDocument() methods. I'm not sure what they do. If you look at the class for your XPage / Custom Control under Local\xsp you can see them. Using the variable name for your datasource, e.g. document1, you will be able to get a hold of the DominoDocumentData object and case it to that class.
There is no such thing as "computed fields on a document". A document is completely unaware how its items got their values.
Computed fields live on forms. You have 2 options (you can use one or both).
when defining a documentDatasource you can specify that the formulas are executed on load and/or save.
use the document.computeWithForm method of the NotesDocument
I making a form which represents project. I'd like to make a field with autocomplete option, for example when I make new project and entering the name of the project lotus will look in existing projects (specified column in view) and suggests name. I need it to prevent creating two projects with same or similar name in user friendly form.
Thank you.
You can do that by adding field with type: Dialog List (with option Allow values not in llist) and as a possible values put
#DbColumn(""; ""; view_name; column_number)
If you want to avoid duplicate names, #dmytro's solution will actually suggest to enter existing names, what may be confusing to users.
What I would do is to lookup similar project names (anyone remembering #Soundex?) and show in computed for display field under the editable field. Only caveat: it will not refresh as user types in, and you need to refresh form to trigger the lookup.
You should also validate your form and do not allow to save it with existing project name (unless it is the same document - compare looked up UNIDS).
We have designed Lotus Notes forms, where we are displaying the data from the external system in a tabular format. In the tabular display we have editable fields, where user enters amount in these editable fields. Now we need to add the data from these editable fields and display in the totals field at the bottom dynamically.
Could some one please help me in this regard with code.
The current code:
The current editable fields are with name:
PE_TOBEPOSTED, PE_TOBEPOSTED1, PE_TOBEPOSTED3 and the total field is TOT_AMT. So in the field value of TOT_AMT the following code is written
w_postd := #Left(PE_TOBEPOSTED;15);
w_postd := #ProperCase(#Name([CN];#Left(w_postd;15)));
w_postd1 := #Left(PE_TOBEPOSTED1;15); w_postd1 := #ProperCase(#Name([CN];#Left(w_postd1;15)));
TOT_AMT = w_postd + w_postd1 + w_postd2
PS: I am just two weeks old in Lotus Notes development
Thanks.
Regards,
Kishore
To sum values, there is an #SUM formula that works like this:
#SUM(PE_TOBEPOSTED : PE_TOBEPOSTED1 : PE_TOBEPOSTED3);
Here, the values listed within the parenthesis, and separated by colons, are the names of the fields you want to sum. So this assumes there is a number in the PE_TOBEPOSTED, PE_TOBEPOSTED1, and PE_TOBEPOSTED3 fields.
You can add a refresh button to cause the page to recalculate. The code for the button is:
#Command( [ViewRefreshFields] )
Ok as you are totally new at this, there is a number of things you need to take into account.
First if you want the changes to happen while the user is interacting with the document in the Notes Client then you should use the NotesUIDocument object in LotusScript.
If you want the changes to happen when no UI is being interacted with you would use the NotesDocument Object.
I strongly recommend reviewing the Infocenter for the related documentation. Every LS Object reference has matching sample code.
For example here is the one for the NotesUIDocument on how to get a field from the document.
http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/topic/com.ibm.designer.domino.main.doc/H_EXAMPLES_FIELDGETTEXT_METHOD.html
You would get the text from the related fields, then use CINT method to change the strings to Integer numbers, add them and send them back to the document.
We have a requirement for a site wide document library that contains simple word letter templates.
From within a customer item on a list we need to be able to select one of these templates and then have the template populate with customer data such as name & address etc.
What’s the easiest way to achieve this? Ideally without using workflows.
Then you shall assign a document template to a content type.
See this blog post, http://sharepointchick.com/archive/2011/01/07/using-content-types-with-document-templates-when-using-quotnew-documentrdquo.aspx
Create fields in your template that display the document properties to "Autofill" them. This is done in the Insert tab of the ribbon, then by clicking QuickParts, then Document Properties.
The end result is that in addition to the File > Info or the properties bar, each property will also appear in the body of the document wherever you have inserted the field for it. These can then auto-update themselves based on the metadata stored with the document in the library (how often they update is a Word setting).
Xpertdoc Letter Management for SharePoint let's user pick a template from the context of a customer record, then generates a new document with customer data automatically merged inside the document.
CGU, an insurance company, estimate they save 0.5 million dollars per year by the efficiency gains introduced by Xpertdoc. http://www.youtube.com/watch?v=xbqWiFt5dUA&feature=channel&list=UL.
First of all, you should use the technique mentioned before for the document creation based on content type.
As for auto-filling the property fields, I suggest you check out this post that explains how to auto-fill properties when document is added.
You can also opt for a commercial solution such as Harmon.ie for SharePoint to retrieve your templates. They have a free version, if I'm not mistaken.