none
Advantage of Using InfoPath in SharePoint RRS feed

  • Question

  • hello ,

      I have seen a viedo about how to create infoPath in SharePoint ?

      but my Questions are  :

      - What the Advantage of InfoPath ?

      -  When I say I use InfoPath ?

     - What  is the Diffrence Between using InfoBath and  (  webParts  or custmization any webpart in SharePoint ) ?


    ASk
    • Moved by Mike Walsh FIN Sunday, July 5, 2009 9:36 AM InfoPath (From:SharePoint - Development and Programming)
    Sunday, July 5, 2009 9:18 AM

Answers

  •  
      
     
    - What the Advantage of InfoPath ?

    There is not one advantage, but many.  It is a form building tool that also acts as the GUI for filling out forms.  InfoPath allows you to create powerful, rich forms that do not require you to write any code, which is great, because it allows non-developers to create them or maintain them.  You can also write code to enhance them beyond what they can do out of the box, but they can do A LOT without code.  InfoPath 2007 forms can either be used these ways:
    - In rich client mode, which requires every user to have InfoPath 2007
    - In restricted rich client mode with 2003-compaitibility, which requires every user to have InfoPath 2003 or 2007 but has limited functionality
    - In browser mode, which requires either MOSS Standard + Forms Server or MOSS Enterprise (includes Forms Services).  In this case, users don't even need to have Office, because Forms Server or Forms Services writes the ASP.NET code when converting your form to be viewed in the browser.

    -  When I say I use InfoPath ?

    What?

    - What  is the Diffrence Between using InfoBath and  (  webParts  or custmization any webpart in SharePoint ) ?

    I don't know what you mean.  InfoPath is a form building tool.  Web parts are not forms but rather windows into data residing in libraries and lists.  You can use custom web parts to display or interact with InfoPath forms.
    SharePoint Architect || My Blog
    • Marked as answer by Lu Zou-MSFT Friday, July 10, 2009 9:37 AM
    Sunday, July 5, 2009 3:51 PM

All replies

  • Moving to the InfoPath forum.


    WSS FAQ sites: http://wssv2faq.mindsharp.com and http://wssv3faq.mindsharp.com
    Total list of WSS 3.0 / MOSS 2007 Books (including foreign language) http://wssv3faq.mindsharp.com/Lists/v3%20WSS%20FAQ/V%20Books.aspx
    Sunday, July 5, 2009 9:36 AM
  •  
      
     
    - What the Advantage of InfoPath ?

    There is not one advantage, but many.  It is a form building tool that also acts as the GUI for filling out forms.  InfoPath allows you to create powerful, rich forms that do not require you to write any code, which is great, because it allows non-developers to create them or maintain them.  You can also write code to enhance them beyond what they can do out of the box, but they can do A LOT without code.  InfoPath 2007 forms can either be used these ways:
    - In rich client mode, which requires every user to have InfoPath 2007
    - In restricted rich client mode with 2003-compaitibility, which requires every user to have InfoPath 2003 or 2007 but has limited functionality
    - In browser mode, which requires either MOSS Standard + Forms Server or MOSS Enterprise (includes Forms Services).  In this case, users don't even need to have Office, because Forms Server or Forms Services writes the ASP.NET code when converting your form to be viewed in the browser.

    -  When I say I use InfoPath ?

    What?

    - What  is the Diffrence Between using InfoBath and  (  webParts  or custmization any webpart in SharePoint ) ?

    I don't know what you mean.  InfoPath is a form building tool.  Web parts are not forms but rather windows into data residing in libraries and lists.  You can use custom web parts to display or interact with InfoPath forms.
    SharePoint Architect || My Blog
    • Marked as answer by Lu Zou-MSFT Friday, July 10, 2009 9:37 AM
    Sunday, July 5, 2009 3:51 PM
  • I agree with what Clayton said,

    you also need to know that you can display (web browser compatible) Infopath forms in a web part and that Infopath forms are often used in workflows.

    You should also be aware of some inconvenient of Infopath forms; to name a few :

    • they cannot be debugged
    • they cannot be localized



    Serge Luca; blog: http://www.redwood.be
    Monday, July 6, 2009 7:42 AM
  • The actual question he is asking is that what is he specific reason why do we go for infopath for designing the forms as we are having he same thing in the sharepoint portal.... 
    Thursday, November 18, 2010 1:10 PM
  • Actually, Clayton did provide the answer; to be more specific : "InfoPath allows you to create powerful, rich forms that do not require you to write any code, which is great, because it allows non-developers to create them or maintain them.  You can also write code to enhance them beyond what they can do out of the box,"

    You can create forms with complex validation rules, lookups to external or sharepoint data, master details, signed forms...You don't have that with default Sharepoint list forms.


    Serge Luca; MVP blog: http://sergeluca.spaces.live.com Devoteam Belgium. http://twitter.com/sergeluca
    Thursday, November 18, 2010 3:05 PM
  • I agree with both Clayton and Serge. From the developer's perspective Infopath is a solid foundation for the complex forms in SharePoint. When it comes to the business requirement changes frequently, it becomes a nightmare. Furthermore i'm not too sure how easy to generate a report or create different views (like SharePoint list standard views) with the Infopath data - no easy way. 

    Go for InfoPath - if you have $$$ and time to spend - because it requires lot of time (not talking about the simple one - but usually i have seen many developers when it comes to create a form they think of InfoPath and timeline they will give from weeks to months)

    Go for SharePoint custom list - if you have less $$$ to spend and the time is short - and its very Agile.

     


    Cheers, Shafie
    Wednesday, June 29, 2011 6:05 AM
  • No, SharePoint custom list forms are not agile at all, and InfoPath is very much a rapid development tool.  SharePoint list forms cannot do even a fraction of what InfoPath does, and InfoPath does it all without writing code.
    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    Wednesday, June 29, 2011 6:25 AM
  • Hello, this is a pretty old post i think, but its addressing some of the questions i'm having about InfoPath as well and my main concern is how to handle complex parent child repeating tables in Sharepoint and i'm wondering if i would be able to create a system with a parent and child tables in Sharepoint using Infopath for LOB type apps like status reporting and issue tracking ect?

    And i'm asking this question after just finishing a project where i had to generate a record in a child table from a parent list using the workflow function "create list item" and that worked fine, but i had to implant the key from the parent in the child and vice versa, but in that project i realized the limitations of using lists, so before i go out on a limb and tell my team that i can handle regular database type apps on Sharepoint, i first need to be sure i will be able to handle a fairly complex app with may involve alot of back and forth between the parent and child/s tables.

    And i would prefer to use C# and Visual Studio but we have SP2007 and from what i understand, you have to have SP2007 loaded on your development machine and that is probably going to be out of the question mainly because noone in our group knows how to set that up or would have the authority to do so, but if we could i would be alot more comfortable knowing  i could create any needed apps using a traditional development approach, but its not looking that way.

    So basically, i really lucked out on this last project because i was able to do everything in Sharepoint Designer and use the standard SP list forms and that actually worked superbly and i really enjoyed the efffort and the workflow flexibility, but after that success, i'm now seeing that members are planning on throwing more my way, but i now know  my limitations and am trying to head them off at the pass instead of taking on a project that would require a complex revamp in development approach, ie using Visual Studio and C#

    So i guess my bottom line question is, could i use the Infopath approach and lets say create an issue tracking system with a Issue parent table with many Resolution Child tables and maybe another child table hanging off the Issue parent table or a Parent with 2 child tables? and not have to do any clugy manipulations ect? and if so, what you recommend then for handling "complex custsom solutions" for SP2007 please?

    Thanks very much for any insights because i don't want to bite off more than i can chew as they say!

    • Proposed as answer by bobk544 Friday, July 1, 2011 12:45 AM
    • Unproposed as answer by bobk544 Friday, July 1, 2011 4:27 PM
    Thursday, June 30, 2011 12:00 AM
  • Choosing between InfoPath forms and ASPX pages, depends totally on the nature of the problems we are solving on one side and level of skill set we are investing in solving that problem on the other side. Usually, in most cases, any manager or developer would want to use InfoPath Forms part of Office 2007 because it’s quick and easy. But, as the requirements get more complex and requires more and more customization, one might feel its better to go with ASPX pages and Visual Studio 2005 and SharePoint designer. Technically, InfoPath Forms by itself is incomplete; It needs a container which is again an ASPX web form using the XmlViewer web part. If we go with custom ASPX form, then it has to be designed either using SharePoint designer or Visual Studio leveraging web parts to show the required forms. So for this, developing web parts and its complexity needs to be taken into consideration.

    So, to decide on one, we may have to take the decision step by step.

    1. If the requirement is for a single form and showing data from an external data store or from within SharePoint, then going with InfoPath Forms is recommended.
    2. If it’s a single form and needs complex actions, to and fro between the form and the data store, then choosing custom aspx pages is recommended.
    3. If the requirement needs wizard kind of feature i.e. which requires user to go through multiple screens, then custom aspx is the solution.
    4. If the data submitted through the form has to be saved to multiple locations (database, SharePoint, file storage) then InfoPath Forms is a good solution.
    5. If the requirement is for designing numerous forms which are simple enough and well documented, then InfoPath Forms should be considered. InfoPath can help deliver the solution in a short time period.
    6. InfoPath browser based forms has few limitations on the repository of controls one can use. For example: combo box, master/detail view control and many advanced controls are not supported in browser based InfoPath Forms. Depending on these limitations we have to decide on InfoPath or ASPX. ASPX has no such limitations.
    7. InfoPath forms is based on XML. The form is rendered using XSLT stylesheets and the data submitted through the form is available in XML format. The data is well structured to retrieve later on and dump the data/forms in some external system. This in combination with BizTalk server is a perfect architecture for document transition through multiple levels.
    8. InfoPath forms certainly have an edge over ASPX forms as a quick and neat solution. It has some complex out of the box controls, like date picker, file attachment control, repeating sections. InfoPath forms can also have code-behind if needed to manipulate the data on the form or behind the form.
    9. ASPX can have and do everything InfoPath Forms does, with an exception of additional development effort. Apart from it, the deployment process of aspx forms is much better and easier than InfoPath Forms.

    Below are some of the excerpts from few blogs I follow which provides some valuable input comparing InfoPath and ASPX forms. Below are the Pros and Cons in using InfoPath Forms:

    Pros:

    • Ideal for simple forms
    • Easy to build a form – no coding involved
    • InfoPath form itself is an xml document.
    • Support versioning
    • Works very nicely with SharePoint custom workflows as a workflow association tool.
    • Fully integrated in Microsoft Office 2007 suites like Outlook e-mail messages that can be deployed as Outlook e-mail messages, so colleagues can complete forms without leaving the familiar Outlook environment.
    • Firewall friendly. InfoPath Forms Services make it easy to extend forms solutions beyond firewall because of using many different Web browsers and mobile devices.
    • InfoPath can easily convert Word documents and Excel spreadsheets to forms and build templates to work with.
    • InfoPath provides data integrity and version control for document management purposes, and add structure to information gathering by converting legacy documents to rich InfoPath form templates.
    • Design of a form is much easier in InfoPath forms with a simple drag-and-drop interface and provides support for prebuilt template parts and shared data connections.
    • Creates PDF or XPS and other important document formats and is extensible by addition of a free plug-in to install third party tools and components for document, archival and records management
    • Fully integrated with MOSS 2007 and capable of using integrated workflow management tools in Office 2007
    • Fully Web browsed technology, includes a design checker to help ensure consistency for forms.
    • Support for information rights management to help manage permission control and building a powerful document management team site.
    • Fully centralized for entire organization and enables organizations to centrally

    Cons:

    • A web browser-enabled InfoPath form does not support all features of InfoPath client.
    • Inflexible — Difficult or impossible to customize (well, you can argue that you can hack the xsl file of InfoPath)
    • No support for image buttons
    • No support for html
    • No support for tree control
    • Difficult to support Forms Based Authentication
    • By default, InfoPath cannot support SharePoint web services data connections in FBA.
    • Forms Services does not support username() function in FBA. This means that InfoPath form does not recognize the current user.
    • Difficult to perform automated web test against Forms Services.
    • Difficult to support automated deployment. Basically, you have to unzip the xsn file and programmatically modify the manifest.xsf file, and zip back to the xsn file for automated publishing.
    • The way that Forms Services supports deployment of InfoPath forms is quirky – It creates SharePoint solution packages with GUID and creates features with meaningless names on the SharePoint Features folder.
    • When you want to re-edit the template and publish it again, it'll double the columns twice in the SP library and its a painfull process to clean it up.


    Credit: http://sharenotes.wordpress.com/2008/06/02/how-to-choose-between-infopath-forms-and-custom-aspx-forms/


    Cheers, Shafie
    Thursday, October 20, 2011 5:27 AM
  • Thank you Shafie! this is very helpful! have a great year Shafie!
    Saturday, October 29, 2011 12:35 AM
  • Very well explained Shafie!

    Thanks,

    Nikhil

    Thursday, May 17, 2012 12:33 AM