RFC: SharePoint From A Domino Perspective
As a Domino developer, when you start to learn SharePoint, the first things that strikes you is how similar the two are. Well, they're quite different, but there are undeniable parallels.
As I work my way through this book I am compiling a table of the elements that make up SharePoint and trying to match them to Domino design elements I'm familiar with. There's no real point to it other than try and understand SharePoint from a perspective I'm used to.
Here's the table as it stands (very much a draft):
| Domino Element | SharePoint Element | Comments |
| Domino Directory | Active Directory | Other way to store users? Dynamics? |
| Web Application | ||
| Site Collection | ||
| Database | Site? | Although there can be multiple Sites per SQL "content database" so maybe a Site Collection is more akin to a databases? |
| ACL | Site Permissions | |
| User | AD User | |
| Form | Content Type? | A Content Type combines a group of Site Columns and defines the pages used to edit/view them. |
| Subform | Web Part? | |
| View | List | |
| Agent (WQO and WQS) | WorkFlow / Event Receiver? | |
| Agent (via Action menu) | Custom Action (Ribbon-based) | There are options in SharePoint to get a handle on selected documents too. |
| Scheduled Agent | Timer Job | More on Timer Jobs |
| Field | Column | |
| Shared Field | Site Column | |
| Computed Field | Computed Column | Hidden/Read Only Site Column perhaps? Accessed via object model |
| Readers Field | FGP? | FGP=Fine-Grained Permissions (link) |
| Authors Field | FGP? | |
| Document | List Item | |
| Profile Document | Property Bag | Somewhere to keep "settings" and configuration. Various Options |
| Action Bar | Ribbon | Not as cut and dry but a simple comparison to make. Ribbon is way much more than a |
| Page | Content Page | Or maybe an Application Page? |
| Script Library | *.cs files | In Visual Studio you can create your own assemblies using as many and as complex a set of C# source files as you like. |
| File Resources/Images etc | Module | |
| Feature | Can contain lots of combined objects such as ContentType, CustomAction, WebTemplate, Field etc | |
| Package | ||
| Solution | Combines lots of Features? | |
| Mail-In Database | List | You can specify a mail-in email address for any List |
If you have any input or comments please add them below and I'll amend the table accordingly.
There are some gaps where, as far as I'm aware, there's no equivalent in the other system. If I'm wrong please say! Any SharePoint element with a question mark next to it are those I'm not confident about.
Skip to the 
You can subscribe to an individual
IMHO it's hard to do a comparison since Lotus and Sharepoint are very different products, both in logical structure and purpose.
Reply
Really? They're not that different in principle.
The structure may be different but the purpose of the two is very similar as I see it.
Reply
I second Jake's opinion. Name one concept that Sharepoint hasn't copied from Notes! The implementation is vastly different (e.g. define a list vs. a form) and Sharepoint has no historic protocols (like offline or RPC) but a lot of "interesting behaviors" (like poorly documented web service APIs) and a "document model" hammered into an RDBMS backend. etc. etc.
Reply
Show the rest of this thread
WorkFlows can definitely be thought of being equivalent to agents. Also, any list or library can be configured to accept items via email so its not just announcements. Calculated columns match with computed fields.
Reply
Thanks Chris. Is a Workflow more like an Agent that an Event Receiver is then? I've not got to either of those chapters yet and had made an assumption in the above table that an "event receiver" sounded like an Agent. Doh.
Reply
Show the rest of this thread
Profile Document - > propertybag in SharePoint
Scheduled Agent -> are timerjobs in SharePoint
WQO and WQS - > Eventreceivers in SharePoint
Workflows -> proces that are triggert by timerjobs
Reply
'Workflows -> proces that are triggert by timerjobs'
Or indeed sp0
Reply
'Workflows -> proces that are triggert by timerjobs'
Workflows map to more than just this. They map to SharePoint workflows (designed by SharePoint Designer) or Windows Workflow Foundation workflows - as well as code executed by timer jobs.
Reply
Isn't a SharePoint list more like a Notes database?
Reply
In what sense?
Reply
Show the rest of this thread
I like to use the masterpage on SharePoint to add my own navigation menu, and I hide the quick launch bar.
Also, after lists and other elements are defined, I build everything with pages, and more recently, with wiki pages, because they tend to behave better than normal pages (no extra html is inserted by the editor).
This makes SharePoint application sites very usable.
I also use InfoPath for forms. InfoPath allows you to build a lot of business logic into the forms and also improve the layout.
I have worked with Notes for over 15 years, and I am developing now the same types of solutions with SharePoint.
Reply
Just a heads-up: your comment on Ribbon got chopped off mid-sentence. An interesting comparison, however. I'm moving into a bit of Sharepoint development on the side myself. From your experience with it thus far, would you recommend the referenced book as a learning tool?
Reply
Thanks Joel. Didn't spot that. Not sure what the ending was going to be. Make your own up I guess.
Yes, I'd definitely recommend the book.
Reply
I would say that a Lotus "View" is an analogous to a SharePoint List View. In that they both define which "columns" to display and sort/grouping/filtering etc.
I would add SharePoint "List" as a feature that Lotus is sorely missing. I would describe a SharePoint List as an "in-site database". They are actually very simple in concept, very simple to create and manage and so ultimately very powerful for the business. You could argue that a SP List is like a Lotus Form - and it's difficult to argue against that, however the main difference being that you create your list in the browser and all the ease of use that goes with them.
Another feature worth mentioning are the Web Services. SP is built on services and they are all pretty much available to developers - and excitingly available for "in client" development.
Reply
The Forms --> Content Type analogy is probably not accurate.
Content Types are more about the metadata surrounding the form than the form itself. You could create dozens of forms without content types, and likewise might have a content type applied to a variety of forms.
Mail-in DB to Announcement list... I don't see that connection. Also, SP 2010 now does allow mail-in functions to lists/libraries. It is a new feature I have not tried, and does not work on custom lists, but it is there...
Also, the whole idea of modules/feature/package/solution is hard to match up. I tend to think of features as being somewhat like Notes templates... but really, contrasting the change/deployment process of Notes vs. SharePoint shows exactly how different they really are.
One other thing to keep in mind is that in Notes, while there is an API available, most devs I know do not routinely fall to that level of coding. Whereas in SharePoint, people think very little of falling to Visual Studio and using the APIs.
Overall, your match-ups look pretty good, though.
Reply
Interesting post Jake and the responses all make sense to me, we are in the mid of using Sharepoint Foundation for both Intranets and replacement of current Lotus Notes databases which are still used in the business.
Mail-in database = Sharepoint List with e-mail address applied for mailing-in articles, we mention the Library email contact similar like mailin-mylibrary@company.com
Reply
I'd also add:
ACL -> Site *Collection* Permissions
Subform -> Web part (or Visual Webpart, which to all intents is an ASP.NET user control)
View -> View (of a List)
Reply
@Dave, all,
Yes it takes a lot of effort to stump Visual Studio projects and develop added value (small or big projects), in Lotus Notes the powerfull @Formula language was for me the tool I used for more than 15 years. Lotus Script solutions were easy to implement if I consider the current deployment process in SP, it was for sure easier in LN.
Just thoughts ;-)
Reply