InfoPath Forms vs. ASPX Pages in SharePoint Designer

Marketing is such a wonderful thing; it makes you believe in something which doesn't exist.
Now, why am I taking about marketing on a SharePoint blog??? Well, lately, I have been asked by many of my customers on using InfoPath 2007 for all their form developments. Now that’s a great idea. InfoPath 2007 is designed for efficient forms management and very powerful tools if used properly. What is not clear to me is that somehow Microsoft have sold this idea that InfoPath is for non-geek, you need absolutely no coding or programming knowledge to design
InfoPath. Again this may be true for simple forms or handful of non-geeky folks who were born to be curious and dare to try new things but Majority of computer users are not geeky. I have yet to find a average computer user or a knowledge worker who can design following InfoPath form (with calculation and data lookup and posting back to SharePoint ) Or someone who can understand What "Data Connection" or "Repeater" means.

When it comes to SharePoint 2007, one always has to make a choice whether to use InfoPath 2007 or design ASPX page. Here is a comparison I came up with on when It make sense to use InfoPath vs. design an ASPX

SharePoint forms	InfoPath 2007 form	ASPX Page ( using SharePoint Designer)
Design tools	InfoPath 2007- a Desktop application, part of Office Suite. Since InfoPath forms are XML based, Programmers can theoretically design the InfoPath form in notepad	Can be designed in Microsoft© SharePoint Designer 2007 (aka Microsoft© FrontPage) For programmers: Dependingonthe choice of tools, ASPX pages can be designed in notepad to Microsoft Visual Studio,
No-code design	Drag and drop support for form controls, table layouts etc. This is by far the best feature I have seen in InfoPath	SharePoint designer does provide drag and drop, simple validation and business logic without writting a code. However as far as User experience is concern, SharePoint designer is subpar compare to InfoPath 2007
Integration	You can submit an InfoPath forms to variety of sources including web services and SharePoint. Lookup data can also be brought from simple xml file to any line of business application and databases.	The built-in integration components to pull data from other sources are not as rich as InfoPath 2007.
Advanced design	This is big differential point. InfoPath 2007 forms out of the box look very nice. However does not support advanced scenarios Tabs Custom AJAX/DHTML Show multiple/nested forms Hand	SharePoint designer allows you to design advanced ASPX Page by direct coding html and JavaScript
Master Page	Out of the box, InfoPath forms are hosted in a new page without a master page. If you need to put a master page around your form for consistency, this require some work 1) Design a InfoPath form 2) Design a ASPX Page with master page 3) Drop <XMLFormView> control in the ASPX page and point to InfoPath	Complete Master page support
Compatibility	By design, a InfoPath form can be opened in 1) Any browser (e.g. IE, Firefox, Safar etc.) 2) Desktop App You can optimize for Desktop, but you cannot optimize for a specific browser or an environment. This is a limitation with any form tools which support variety of tools. The choice of controls are limited to This	Unfortunately, an ASPX pages can only be designed for browsers. But you have lot of choices to optimize for a specific browser.
Publishing to SharePoint	In spite of Microsoft's best efforts, the publishing to SharePoint is not as smooth as you would have expected from a non-programmers tool. I love the "Blogging" feature of Word 2007; it's simple and intuitive for non-technical folks. I would have liked to see a similar approach in InfoPath 2007 Nonetheless with some training, I think InfoPath offers a great capability for publishing forms	In my personal opinion, designing an ASPX page and publishing to SharePoint is lot simpler in SharePoint designer than in InfoPath 2007
Error handling	Because InfoPath is designed for knowledge workers AKA non-programmers, the error handling is some what poor. Most exceptions only make sense to the technical folks. But if you get some cryptic exceptions such as "Unknown error" or "exception occurred" , you are really out of luck unless you find some clues in the /12 hive log or the Event log	Pretty friendly and intuitive, you can do better error handling. You have more control on the flow compare to InfoPath 2007.

SharePoint and Large files ( > 1GB) in a Document Library ?

I have been repetitively asked if SharePoint can be used as an alternative to FTP or Network Share. SharePoint does offer strong capabilities for document management but it by NO means is an alternative to FTP or Network Share

As you probably know, SharePoint stores all documents in database as a blob. Which, in itself is not an bad idea. I know you probably thinking I am smoking !. But the truth is that in SQL SERVER 2005 BLOB performance is vastly improved. Also SharePoint 2007 does smart caching on Web Front ends (WFEs) for most frequently used files ( e.g. JavaScript, CSS and images etc) .

However because its a web application and does not use special controls for most files ( except for Office documents, which are downloaded via FPRPC over HTTP - discussed later) it suffers with all following limitation if you try to upload or download

1) Your browser could timeout while uploading a large file

2) Your browser could run out of memory due to spooling

3) If lots of users are downloading or uploading large files, it could impact your web server performance

4) If your download fails for any of above reasons, Your download will not resume itself, You will need to start all over again...

So, what are your choices ?


1) Store File on a Network Share or SAN devices: One solution is to store the actual file on a fast network device and only keep the path in the document library (or create a simple list item and store the link) . You need to make sure that only the process account has direct access to network access and you may also need to write custom event to prevent unauthorised access.

This way you can take advantage of SharePoint UI, Security, Target Audience and Search feature and also optimise the user experience and performace

However, using this solution requires careful planning, coding and security testing.

2) Create custom download activeX control or Windows App : If you are building an application for a controlled environment, you could also write a custom ActiveX control or a Windows application and use WCF / MTOM with SharePoint Web services to download files asynchronously and chunk by chunk ( streaming) -

In case of an error, you can resume the download where you left before the error occured. You can also notify server on a successful download using custom hash.

Basically you have lot more choices in this approach then the first approach for download


3) Wait for SQL SERVER 2008 : Well, if you can wait, there is a rumor that SQL Server 2008 will have an alternative storage mechanism for BLOB. After all you might a get choice to store BLOB in a file. Does the name WinFS ring a bell?