Seemed obvious, so I did it. I am now posting updates about this blog on Twitter. You can follow the tweets @LearnLotusNotes.
The Form design object is likely one of the most used, and I believe most misunderstood objects. That's my opinion though, nothing more. The biggest confusion I see is that people have difficulty differentiating between a DOCUMENT and a FORM. There is a big difference. A Form does NOT contain any data whatsoever, nor is it solely in control of what data goes into a Document developed using the Form. A Document ONLY contains data and really has no User Interface that is apart of it. You can apply data to a Document in many, many ways - non of which has to have anything to do with a Form.
Confused? I will try to sum it up using illustrations - 1 will be technical, the other no technical.
If you are old enough, you might remember taking tests that used a single answer sheet separate from the questions where you fill-in a circle representing your answer. For example there might be choices A, B, C, and D. The answer sheet has rows and rows of 4 circles, each representing a letter. You read the question and then fill-in the answer on the answer sheet by coloring in the circle with the right letter.
I had to write all that to get to the actual illustration. When the teacher would go to grade your answer sheet, he/she would generally have a laminated copy of the answer sheet with the correct answer for each row cut out so they could see through it. They would just lay their answer copy over your answer sheet. If the answer you filled in did NOT show thru their cut out answer, then they just mark it wrong by pushing a red marker through the whole on their laminated copy.
A Form object in Lotus Notes/Domino is similar to the laminated version the teacher used, except, not for marking something right or wrong. You see, if you put a field on a Form, and the document has a value for a field with that name, then it will show through. But that Form has nothing to do with the Data on the document. The reality is, the FORM is a User Interface component ONLY. It is built a certain way by a designer to represent and collect data on associated Documents only. A document does not even have to be created using the Form, thus, it may not always have data that matches up to fields that are on the Form.
Lets try a Technical illustration, just in cast that helps. I hope this illustration is clear to others, it was the best one I had heard, but it may not work for everyone.
Anyone familiar with Web 2.0 technologies has heard of XML and XSLT. Put simply, this is the same relationship of a DOCUMENT and a FORM in Lotus Notes/Domino. As with XML and XSLT, the XML document contains data. The XSLT style sheet contains the look and feel of the data contains in the XML document when applied to that data.
It is a perfect example, and thus should emphasize the power of the Form and Document model of Lotus Notes/Domino. Guess what, this has been the model of Notes/Domino since its inception (or at least since I started with version 3.35). We have had the power of this concept at our disposal for 15+ years now - when did everyone else catch on?
How it Stores Data
If you have read this entire post, you already know the answer to this question. But, just in case, the answer is simple. A FORM does NOT store data - ever. Some might argue that it does store data related to its design, and that is true. But in the since of storing data related to the purpose of a database, it does not. That is the Document's job.
What is it used for - when started
I'll answer "when started" first. It has always been a part of the database and thus has been around as long as the actual database object.
What is it used for is a more difficult question to answer. The straight forward answer is, the User Interface for data stored in a database. The reality is, I have seen many clever uses of the Form object to gather, manipulate, display, and control data contained in documents. For example, and this is a simple example, you can use a form to be a dialog box, to gather information that would not normally be gathered for a document, and thus is not apart of the basic Form used for creating that document. Another example you can see for yourself, is something Lotus does natively. Set your client to be remote so it uses a local replica of mail and the local mail.box. Open your mail database and send an email somewhere. Then go to your local mail.box and open the message sitting in queue.
Each database has different forms for displaying a message. In your mail file you created the message using the Memo form and it had all the basic fields you are used to seeing on a message. In this case, the Memo Form was the User Interface for creating a message Document that you emailed and is now sitting in the mail.box waiting to be routed. If you open the message sitting in the mail.box, it contains the exact same data that the document contained in your mail database, but when you open it in the mail.box it looks nothing like the one you sent. That is because the Memo Form in the mail.box has a different design than the one in your mail database. Thus, it displays that data (which has not changed between databases) differently. This is all because of the differences between FORMS - nothing else.
Next lesson we will discuss the VIEW object. Some may wonder, when will we discuss the Document object? We won't for now, as we are discussing design elements, and the document is not a design element, it is a data element.
I went back and forth about what I would first write about, and decided that programming seems to be the area that most needs attention. That being the case, my first few blog entries will be related to development.
With this first entry, I think an explanation of the overall programming items is ideal. I will discuss the objects available, what version they became available in (if I know), and what they are used for (whether by design or creative use).
This fact is clearly "brought to light" by the fact that there is a new function in Notes databases (since Notes/Domino 6 I believe) called DXL which is essentially a way to represent everything in a database in XML.
How it Stores Data
For example, an email message is a document in your mail database. All of them contain some basic fields, like the sendto, copyto, subject, and body fields. However, as you manage your inbox you might add flags to a messsage for a reminder, or it might have come with a mood stamp on the message. Though all of these documents represent data created with Memo form, Reply form, or Reply to Reply form (which are very similar), they will not contain all the same fields. When you flag a message for say a follow up, it adds a field to indicate your choice, but other messages you have not done this for do not. Thus the <FIELD> list of values for the marked document would be different than the ones unmarked. This is a basic functionality of documents - there is no real limit to how you can leverage this. Some (mostly with a relational database background) would argue this is a bad thing, and it can be as it means data is not "normalized", but it can also be a beneficial thing - and it is often a very powerful feature of Notes/Domino databases.
So a Notes/Domino database is a collection of Documents that store data. That is it.
You may be saying to your self right now, well what about design elements like views and outlines? Guess what, they are documents, special kind of documents of course, but documents nonetheless that contain data which represents the structure and configuration of said design elements. The Notes/Domino database just knows how to use those special documents to function as functionality. And guess what, if you wanted to (though I can only think of a few rare cases where you would) you can add or manipulate the fields of a design element just like you can of a data document.
What is it used for - when started
Next lesson we will discuss the FORM object.
Until then, let me know what you think of this article as it will be a template going forward.
I hear it all the time, there have been blogs and lengthy discussions about it. Just defining exactly what Lotus Notes/Domino is can be difficult and is part of the reason I think some organizations and technical professionals have difficulty adopting it. It doesn't have to be difficult. I am going to try to explain it here, from my perspective anyway, but remember I already said it is difficult to do.
First - it is NOT an email system, in the sense that, that is all it does. Environments using it for just email are missing out on so much!
I like to think of Lotus Notes/Domino as a Collaboration Toolbox. Unlike Lotus' competitors, who seem good at releasing individual collaboration "tools", the Lotus Notes/Domino product has evolved into a complete collection of collaboration tools in one package.
Anyone would be foolish to say they have the only tool anyone will ever need - and the Lotus Notes/Domino environment proves that IBM Lotus would not try to do that (but no one in their right mind would). They have, instead focused on making the Lotus Notes/Domino environment adhere as close to open standards as possible making Lotus Notes/Domino a tool that can be better leveraged as your specific needs require.
For example, you might compare most competitors in the collaboration space to a toolbox that has a hammer, a couple of screw drivers, a razor knife, and a small wrench set. True, you could get a fair amount done, and you will have the tool you need in most cases, and there is an ability to improvise/modify the tools if necessary. But you can only do any of this in the tool shed - you can't use them anywhere else.
The Lotus Notes/Domino collaboration toolbox has a number of hammers, screw drivers, cutting implements, full wrench set (metric and US), plus a socket wrench set, drill, sander, and so on. Also, you have multiple tools that can be used to improve the provided tools to adjust for your needs. Also, you can use this toolbox almost anywhere.
To clarify the illustration of the two toolboxes above, lets compare Microsoft's collaboration toolbox with Lotus Notes/Domino's.
In the Microsoft world you have disparate systems that make up their collaborative environment. For example, Exchange for email and C&S, Sharepoint for collaboration/document management, Communication server for IM/Chat, SQL for data storage, IIS for web presentation (which Sharepoint and Exchange both rely on), and then the underlying OS (the tool shed) MS Windows server. For the most part all of these require their own licenses as well and are tied tightly into an Active Directory structure for security. If you want to modify any of these, you can, using MS Development tools like .NET, or by consuming Webservices.
To sum up, collaboration products are suppose to make interactions of people and business groups easier. There is no way any one company can provide a perfect solution for everyone, so have a product that enables your team with the most flexibility to meet the needs of your users/environment is critical. So which toolbox would you rather have?
It is rare in life to get to do something you truly want to do. After 14+ years as a Lotus Notes/Domino professional, I continue to hear people say they wish there was a good place to go to learn the basics of Lotus Notes/Domino. I still hear people make uninformed derogatory remarks about the Lotus Notes/Domino environment. For these two main reasons, I hope this blog will help stop both, by informing the uniformed - and assisting anyone who has decided to make a career in the Lotus Notes/Domino environment. So finally, I get to do something I have wanted - help a community I love being a part of by sharing knowledge about it.
The focus will be both Admin and Development, and I will try to mix it up as much as possible. Since we have to start from the ground up, some articles will be too basic for anyone with experience in the Lotus Notes/Domino environment - but sometimes reminders are nice as well.
For those of you in the community who have experience, please participate to help those just learning how to learn more.