It's been a while since I posted. As you may imagine, July wasn't the most popular month to spend in the office (or in the Office Server). However, I'm back and packed with loads of new information so it's sharing time! The main topic of this post will be InfoPath Development. Recently, I've been dealing a lot with InfoPath's browser forms with one of our customers (Shlomy, Sveta and Tal from the IDC – this post is dedicated to you) and while working I got the notion that many times developers tend to dismiss the fact that InfoPath is actually a full development platform and should definitely be treated as one. This is even especially important once you decided to add managed code and combine it with Visual Studio 2005/2008. Given concepts and best practices that we use in every development process are totally overlooked when you use InfoPath – and we're talking about important and time saving things like naming convections, data access layers etc.
Well, I decided to try and provide the basic Best Practices that you need to use with InfoPath forms. I believe this will add some sense into the development process and help you make the most of your time (and for other developers to maintain and debug your InfoPath forms):
Coding Naming conventions for InfoPath:
- Controls are Controls even if you design them in InfoPath. I'd recommend following Brad Abrams' C# style guidelines here: http://blogs.msdn.com/brada/articles/361363.aspx
- FxCop 1.35 is always a great recommendation and especially in InfoPath. I'd suggest using this as early in your coding cycle as possible: http://code.msdn.microsoft.com/codeanalysis/Release/ProjectReleases.aspx?ReleaseId=553
Data Access Layer in InfoPath:
- If you want to query data from a SQL database in InfoPath Forms Services – this great resource is a must to design a good approach for your DAL: http://office.microsoft.com/en-us/infopath/HP100928231033.aspx?pid=CH100598301033
- Important Notion – If you design your form template based on the SQL database then InfoPath will generate queryFields whose values may be used to constrain the query. If you use a secondary data connection to the SQL database, then you'd have to use custom code to constrain the SQL query based on the form's current state.
- Complex Data Connections should also be managed somehow just like every other development project. You'll definitely need to look at the new Data Connection Library (DCL) support for InfoPath data connections. If you never heard of it or want to read more about it – see these superb articles for more details:
Digital Signatures for InfoPath:
- Support matrix (signing is only supported in IE, but all browsers can view previously created signatures). More data in here: http://office.microsoft.com/en-us/infopath/HA102040851033.aspx#5
- Signing is performed using an ActiveX control. In a Production environment, you should secure the connection via SSL in order to ensure the security of the signed data.
- Team blog: http://blogs.msdn.com/infopath
- Office Online help: http://office.microsoft.com/en-us/infopath/FX100647031033.aspx?CTT=96&Origin=CL100607051033
- MSDN InfoPath developer resource: http://msdn2.microsoft.com/en-us/office/aa905443.aspx
- My previous post about InfoPath that is loaded with awesome links for InfoPath: http://blogs.microsoft.co.il/blogs/adir_ron/archive/2007/05/22/Huge-list-of-InfoPath-2007-Resources_2C00_-Links_2C00_-HOL_1920_s-and-mo.aspx
Oh, and before we set off – another link you should be aware of. Check out this great post that compare InfoPath rich client to InfoPath Forms Services. It covers all of the main differences and should be used before you decide on a complex form's platform:
That's it for now. See you soon…