After some reading and R&D, I have came to conclusion that ?
Forms in lotus notes = List in sharepoint.
And Fields in Lotus Forms = Column in Sharepoint List.
But in some articals I found Lotus View is List in Sharepoint.so I am confused ,
So need experts advice
Thanks in advance.
Forms in Lotus Notes are a GUI-based way to edit and get data into the back-end documents. Lotus Notes stores data in document objects, which are essentially unstructured records (meaning they have no schema or requirements on what fields exist within). Through forms, developers can set required fields and maintain control over how data gets into each document, but technically Notes agents and scripts could alter those documents without adhering to any rules about the data contained within.
Notes views are visualizations of the Notes documents, allowing you to filter the documents and display columns of data they contain.
SharePoint Lists are structured and you must create a schema defining what data is allowed in each field of the list record. The views used to display the list data are similar to Notes views in some ways, but nothing is really exactly the same between the two systems.
To tie the two into common database concepts of Table > Record > Column, here's how the two systems work in those terms:
Lotus Notes:
Table = Notes Form. You can think of a Notes Form as the table since typically it has the most influence over the schema for your data, although as I said Notes documents (i.e. records) are unstructured and can hold any data.
Record = Notes Document. The document is the data container behind the scenes. When you click on an email in Lotus Notes, you're selecting a back-end document. When you open that email, you're displaying that document in a Notes Form, the Mail form.
Column = Notes Item. A Notes document is made up of many items. Not to be confused with the concept of a column in Lotus Notes Views, which is for display purposes only.
SharePoint:
Table = List. The list settings define what data is stored in the list.
Record = List item. The list is made up of individual items, just like records in a database table.
Column = Column. For the purposes of this explanation, these are the same.
Related
I'm creating a compliance mailing for my organization, the mailing will include merge fields that identify the office location, physician, and SiteId. The mailing will also include a table of information that is dependent upon the particular SiteId.
I'd like to use the import table function of MS word and set up a query that references a merged field (SiteId) so that the inserted tables populate the appropriate data for the particular site. I'm unable to do this.
How can I set up this document so that I can import only records from my source (an ms access query) that match the SiteId merge field?
Word's mail merge does not support one-to-many relationships. There are ways to coerce it, but only one of them can yield a table as a result and over the years it has become less and less reliable as Microsoft has not regarded it as important enough to maintain...
What you need to do is set up a query that provides ONLY the information you want displayed in the table, plus the key (SiteId). It's best to sort it so that all the SiteId entries list together, and are in the order the data will come through in the mail merge data source.
On the Insert tab go to Text/Quick Parts/Insert Field and select the Database field from the list in the dialog box. Click "Insert Database" and follow the instructions in the dialog box to link in the data. Be sure to set the Query Options to filter on the first SiteId from the data source. When you "Insert Data" make sure to choose the option to "Insert as a field".
This inserts a DATABASE field in the document which you can see by toggling field codes (Alt+F9). The field code can be edited and what you need to do is substitute the literal SiteId value you entered for the query with its corresponding MergeField.
When you execute the merge to a new document that should generate a table for each data record corresponding to the SiteId for the record. But, as I said, Microsoft hasn't done a great job of maintaining this, so it may require quite a bit of tweaking and experimenting.
If the results are not satisfactory then you should give up the idea of mail merge and use automation code to generate and populate the documents.
You can find more (albeit somewhat out-dated) information on this topic at http://homepage.swissonline.ch/cindymeister/mergfaq1.htm
I would like to make a selection criterion in Lotus notes Views base on the role the user belongs to, using the below code
SELECT FORM ="User" & Retired = "0" |
(#IsMember("[Admin]";#UserRoles))
but whenever I check for the roles it return #UserRoles return an empty string "".
any idea how to go about criterion
You can't use #UserRoles in a view selection. From Domino Designer help:
This function does not work in column, selection, mail agent, or scheduled agent formulas.
You need to use readers fields. In your case, a document must have a readers field with [Admin] as a value.
Read more about readers and authors fields at Using and understanding Reader Names fields in IBM Lotus Notes and Domino or Reader and Author Field Troubleshooting.
I am a bit confused about terminology. In SharePoint we have a List and it consists of List columns but I have read in one of the site that this can be meta data too.
Taking an example if we have a SharePoint list and if we have a List Columns with name, Job description, age and Income, will this be termed as column, field or metadata?
If this is metadata then how can you define fields/columns/site column?
You may know that Meta Data is nothing but data about data.
In share point context Meta Data can be used as list column also. Consider any excel documents which are classified using Phase , Category, Document Type etc. So when ever you see these columns you can identify what kind of document it is.
As per my knowledge key words are nothing but taxonomy. By using these keywords you can classify the items.
Site Column is different. Site Column can be used as list column in any list. For eg. Consider the Age. In your site you are using Age column repeatedly in your lists/libraries. So instead of creating Age column in each list you can create only one site column and you can add to required list. In simple words reusable purpose.
Fields are nothing but a columns/site columns. These are related to list.
As Mihir states, the word "metadata" means "data about data". So to have metadata you need to have data. In SharePoint the most relevant example would be documents. Documents are data and you can have data (metadata) about these documents. Mihirs Excel example is an example of this.
Say, you want a document library in SharePoint and these documents have a document type chosen from a list of choices.
To achieve this you need to be able to put a document type on the documents. Since Document libraries in SharePoint is a special kind of list, you can create columns=fields on the list - and the data in these columns becomes metadata for your document.
So on the library you create a field, DocumentType, e.g. as a choice field. The field is setup with possible choices for the document type. So the list fields/columns are used to define metadata on the document(s).
When it comes to pure SP lists it becomes more difficult to talk about metadata. For what is it data about? In case of an employee I don't think you can define it as metadata, expect if you treat the physical person as "the data". However, I don't think it technical make a difference. You have your datamodel of the employees and implement it using SP lists - that's what they are there for!
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.
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.