InfoPath forms advantages & disadvantages

Info path advantages

InfoPath is a better XML standard, but the true benefits depend on the situation. I'll try to list some pros for InfoPath + SharePoint:
1) You can connect to many back-end data sources to get data, whether it be SharePoint itself, SQL DBs, Access, or any web service that interfaces with a non-MS DB.
2) The forms can be directly integrated with SharePoint through form libraries, which allows your people to stay within the primary collaboration interface (SharePoint) when doing all your work, including filling out electronic forms.
3) When the form is submitted to the form library, the data is then discoverable in the search index across all of SharePoint (depending on how your enterprise search is configured)
4) If using MOSS 2007 Enterprise, then you have the option of browser-enabled forms where people can interact with the forms from different non-MS platforms and non-MS browsers without the users needing the InfoPath client.
5) Submitting forms to SharePoint allows you to then trigger workflows that can do just about anything you want for routing, notification, updating data in other lists/libraries, etc.
6) InfoPath is part of the Office Suite and has already been improved greatly in 2010. It is built to interface and integrate with other Office products, including Word and Outlook.

InfoPath offers the following advantages as a form technology for
AgilePoint-based, process-driven applications:

• Created using a GUI. No code is required.
• Easy to use and business user friendly.
• Rapid form creation.
• Close integration with SharePoint.
• Dynamic lookups from most any external data source, including SharePoint.
• Simple integration with SharePoint, web services, and databases.
• Multiple views for single form.
• Repeating tables.
• Dynamic validation.
• Conditional formatting.
• Multiple attachments.
• Multi-lingual form capabilities.
• Custom branding.
• Web-based or client-based data entry mode.

Info Path Disadvatages

InfoPath includes the following disadvantages as a form technology for AgilePoint-based, process-driven applications:

• Difficult to integrate with process-driven applications outside of SharePoint
• Difficult to secure sensitive data.
• Both web-based and client-based forms require the InfoPath client license.
• InfoPath Forms Server license is required for web-based forms.
• Limited standard controls.
• No support for custom controls.
• No support for AJAX.
• No multilingual support.
• Performance reduction on large or complex forms. Post back to form is slow, and performance is not good.
• Custom, managed code is difficult to maintain.

SharePoint: Writing a Custom Event Receiver

nice article on how to write a custom event receivers
SharePoint: Writing a Custom Event Receiver

Sample Event Handler to set Permissions

Please note that it is a sample code and should not be used in production environment without some major changes. For example - getting the user name and password of a user with elevated permissions on the list should be from an encrypted config file. Another example for a change is changing the logging to use a trace log.
All that aside, this is still a good working example that shows some interesting things:

• How to get a list item in the event handler


• How to impersonate another user totaly (not using RunWithElevatedPrivilages)


• How to change an item's permissions


• How to create a new permission role in a web site


• How to check if a role exists or not (nice trick there - can you spot it?)


http://www.sharepoint-tips.com/2007/03/sample-event-handler-to-set-permissions.html

Sharepoint activate and deactivate the features

How to un-register an Event Handler on a List, sharepoint 2007, MOSS


Best way to deploy your event handlers in Production environment is thru Solutions/Features. All you need to use is Feature Assembly and basically use Feature Activated and Feature Deactivating events.

Following is the code that you might want to refer on Feature Activated:

{

SPWeb web = SPContext.Current.Web;
SPList spListName = web.Lists["Project Time Entry List"];

string assemblyName = "AssemblyName, Version=1.0.0.0, Culture=neutral, PublicKeyToken=36f7c742d410fd5b";
string className = "AssemblyName.TotalCheck_ItmEvntHdlr";
SPEventReceiverDefinition evntRcvr = spListName.EventReceivers.Add();
evntRcvr.Name = "TotalCheck_ItemAdding";
evntRcvr.Type = SPEventReceiverType.ItemAdding;
evntRcvr.SequenceNumber = 200;
evntRcvr.Assembly = assemblyName;
evntRcvr.Class = className;
evntRcvr.Update();

SPEventReceiverDefinition evntRcvr_updt = spListName.EventReceivers.Add();
evntRcvr_updt.Name = "TotalCheck_ItemUpdating";
evntRcvr_updt.Type = SPEventReceiverType.ItemUpdating;
evntRcvr_updt.SequenceNumber = 201;
evntRcvr_updt.Assembly = assemblyName;
evntRcvr_updt.Class = className;
evntRcvr_updt.Update();
}

Following is the code that you can use in the Feature Deactivating code

{
SPWeb web = SPContext.Current.Web;
SPList spListName = web.Lists["Project Time Entry List"];

for(int i=0; i {

if (spListName.EventReceivers[i].Name != null)
{
if (spListName.EventReceivers[i].Name == "TotalCheck_ItemAdding" || spListName.EventReceivers[i].Name == "TotalCheck_ItemUpdating")
{
spListName.EventReceivers[i].Delete();

i = -1;
}
}
}
}

Sairam