This week is an awesome week for me. First of all, I am in Athens (Greece). Spending a lot of time in Cyprus every year, coming to Greece and experiencing the Greek culture is always a very pleasant experience for me. The Acropolis is just a couple of hundred of meters from my hotel. Nice to take a taxi every morning and just looking at that impressive ancient monument. Second reason is that I am delivering a very dev-focused workshop for Microsoft internals here. Not your ordinary course I must say, we very often end up in excellent discussions on how to tackle the different MOSS projects they are involved in and solve the many issues. Conclusion from the guys here is that the story about WSS and MOSS delivering a great out-of-the-box experience is true but for almost all of the real-world projects, there is a good amount of customization, configuration and development needed. Many people are surprised about this. Don't forget! For me WSS and MOSS are 'platforms' for you to build solutions on. So, this week has so far been a good opportunity for me to try out a lot of stuff that has already ended up in the book or will end up in it. Yes, I am almost half-way - four chapters almost done (Intro, WCM, BDC and Policies and Records Repository), four chapters (Portals and People Management, Search, Office Forms Server and Excel Services) to go.
Back to the title of the posting. A couple of months I posted about encapsulating an InfoPath form within your own custom Web Part. A couple of other bloggers have also excellent postings on the subject. But I remember that one of my students (not this week, many months ago) made the remark that the XmlForm ASP.NET control that is part of the Microsoft.Office.InfoPath.Server.dll (located in the C:\Program Files\Microsoft Office Servers\12.0\Bin folder) is actually a Web Part itself.
So here is the scenario, you have an InfoPath template for meeting agendas (one of the samples) and you publish this to a SharePoint site, creating a document library and leveraging the Office Forms Server to deliver a browser-based experience. You can now have the XmlForm Web Part on the home page showing one of these meeting agendas.
1. Start by publishing the meeting agenda template from InfoPath 2007 to a document library in one of your sites. Create one sample meeting, for example like this
2. Open the web.config of the folder that is in the physical folder associated with your IIS Web application hosting the site and add the following element in the SafeControls section:
<SafeControl Assembly="Microsoft.Office.InfoPath.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.Office.InfoPath.Server.Controls" TypeName="*" Safe="True" />
3. Go to the top-level site of your site collection and open the Site Settings page. Open the Web Parts gallery and click the New button in the toolbar to populate the gallery with the new entry.
4. Go to the home page of your site and Edit the Page. Click the Add Web Parts button and find the new XmlFormView Web Part entry.
5. Don't worry about the error you get. Just close it.
6. Now, open the properties pane of the Web Part and all the way at the bottom found some interesting properties to set. Set the EditingStatus to Editing and provide the URL to one of the stored InfoPath forms as the value of the XmlLocation.
7. And there you go, you have the meeting nicely displayed in the Web Part.
One minor point is that it is not connectable so if you want to dynamically fill it up with other Web Parts, you need to host it in your own Web Part and add some extra logic. See my posting and the posting of JOPX.
Again, thanks to the student who made this remark. Whoever you were! Let yourself known!